» Windows 98 SE (оптимизация и улучшение) — четвертая часть

Спасибо!

Seymour

Цитата:

Так я не понял, памяти то реально сколько кэш после этой настройки/патча занимает? Те же 800 Мб или меньше? А если меньше тогда зачем нужен параметр MaxPhysPage? И без него по идее все должно работать.

Под кеш ВЫДЕЛЯЕТСЯ память, равная по обьему количеству оперативки в машине, но не более 800 Мб (эта цифра, 800Мб, как раз и сидит в драйвере VCACHE.VXD, она и патчится). MaxPhysPage - ограничивает объем ВИДИМОЙ ОПЕРАТИВКИ (правда криво) следовательно и оъем ВЫДЕЛЯЕМЫЙ под кеш. MaxFileCache - ограничивает ИСПОЛЬЗУЕМЫЙ под кеш объем. Т.е. было ВЫДЕЛЕНО все равно 800, а ИСПОЛЬЗУЕТСЯ меньше, в отличии от патча VCACHE.VXD, или ограничения доступной оперативы, когда память не только не используется но и не резервируется. Хотя глюков именно от того, что была ВЫДЕЛЕНА (но не использовалась) лишняя память (при условии, что VMM.VXD - пропатчен, и все остальное правильно), лично я не видел.
Для борьбы с VCACHE.VXD - деуствительно вполне хватает MaxFileCache. А MaxPhysPage - мелкомягкие рекомендуют использовать для борьбы с ошибкой VMM.VXD, причем если память ограничивается до соотв величины, то MaxFileCache - может и не понадобится, ибо кеш ограничивается автоматом, хотя пользоваться только MaxPhysPage - глупо т.к. вместе с кешем обрезается и вообще вся память (чего можно было бы избежать посредством MaxFileCache).
например на системе с 1Гб и занятой зоной 0xD0000000-0xDFFFFFFF можно ограничить : MaxPhysPage=20000 (512Мб) и MaxFileCache=262143 (256Мб), если пользоваться только MaxPhysPage - придется ограничивать всю память до 256Мб, а одним только MaxFileCache - обойтись нельзя, ибо с гигобайтом может не загрузится вообще из-за глюка VMM.VXD. Теперь понятно объяснил ?

Цитата:

Куда смотреть, я что-то не догоняю. У меня в этом окне адреса 0xC0000000 нету, есть другие И как по ним вычислить размер кэша?

Адреса 0xC0000000 - быть и не должно (если он есть - это полный облом). В этом окне показаны ЗАНЯТЫЕ адреса. А вам надо найти сколько СВОБОДНО от 0xC0000000 - до первого занятого. Теперь по поводу ваших данных - это какойто "косяк" из приведенного следует, что свободно все аж до 0xEC800000 (целых 712мб в диаппазоне 0xC0000000-0xEC800000). Косяк потому, что не вижу области занятой видеокартой (окно доступа к видеопамяти, и аппертура AGP), а они там должны быть, даже если вы вынули всю "лишнюю" переферию. Причем "DOS-овскую часть" видеокарты - вижу:

Цитата:

000A0000 - 000AFFFF All-in-Wonder 9000
000B0000 - 000BFFFF All-in-Wonder 9000
000C0000 - 000CCFFF All-in-Wonder 9000

А вот "верхнюю" - нет 8-).
Кроме того, насколько я понимаю, All-in-Wonder - это с видеозахватом, значит должен еще кусок под видеозахват занимать.
1) Точно опишите откуда вы эти цифры взяли.
2) Укажите полную конфигурацию оборудования.
3) Посмотрите еще отдельно, в свойствах устройства "видеоадаптер" какие ресурсы он занимает.
4) Если установлена еще и XP (или какая нибудь NT), гляньте теже цифры и в ней.


Цитата:

Можно и System.ini перед установкой в папку Windows подкинуть попробовать, хотя при больших объемах оперативки это рискованно.

Можно, но при больших обьемах - это не метод, к тому-же , он конфликтует с RAM LIMITATION PATCH (обязательно убрать, а то повиснет), кроме того, MaxPhysPage - таким образом поставить можно, а MaxFileCache - инсталлятор затирает при установке. Вобщем это имеет смысл, только тогда, когда вы и в дальнейшем планируете этим MaxPhysPage - обойтись, в остальных случаях - глупо, burnmem - работает лучше, и гемороя меньше.

IFkO

Цитата:

Для тех, кто пользует 98IF сборки 2008-12-31: можете протестировать предложенный mercury127 способ присвоения названий и задания режимов DMA дискам IDE: Вот пакет, который кладется в дистрибутив указанной сборки. При установке системы программа запускается после последней перезагрузки автоматически, затем все ее элементы (уже ненужные) стираются, а чтобы повторить процедуру, лезем в меню установки компонентов системы в раздел "служебные". Главное, что меня интересует - не будет ли от этого вреда?

Нужно быть осторожным, т.к. данный способ не только легко ставит режим DMA-UDMA для IDE устройств, но и делает это "принудительно", что может вызвать проблемы со старыми винтами (бывает из-за каких-то внутренних проблем винты, даже с заявленной поддержкой DMA, безбожно глючат в DMA-UDMA режимах и нормально работают в PIO режиме), для системы на таком винте могут быть фатальные последствия.
Так что применение данного метода оправдано только для "надежного" железа (т.е. другими словами "не все йогурты одиноково полезны" и ставить в автоматику весьма и весьма осторожно) и с оглядкой для тех, кто часто подключает чужие винты к своей системе.

Kirill666

Цитата:

Теперь понятно объяснил ?

Да в общем-то я и так это понимал, но меня другое интересует:

Цитата:

Хотя глюков именно от того, что была ВЫДЕЛЕНА (но не использовалась) лишняя память (при условии, что VMM.VXD - пропатчен, и все остальное правильно), лично я не видел.

Меня интересует как раз случай, когда VMM не пропатчен и используется параметр MaxFileCache. Будет ли доступен в этом случае НЕИСПОЛЬЗУЕМЫЙ, но ВЫДЕЛЯЕМЫЙ для кэша участок памяти другим программам? Видеокартам понятно, что будет, т.к. им другого выхода не остается из-за аппаратной привязки к этим адресам, а вот программам возможно будет сообщаться, что этот неиспользуемый кэшем участок памяти зарезервирован и они его использовать не смогут. Я прав или нет?

Цитата:

MaxPhysPage - ограничивает объем ВИДИМОЙ ОПЕРАТИВКИ (правда криво) следовательно и оъем ВЫДЕЛЯЕМЫЙ под кеш.

Это все хорошо, но зачем тогда на системах с памятью больше 1.5 Гб этот параметр устанавливается в значение больше 1 Гб (1164 Мб максимум). Это же противоречит самой сути этого ограничения? Для примера (взято отсюда):

Цитата:

OS: Windows 98SE
Memory: 1.5 GiB RAM (Legend and Nanya)
Motherboard: ASUS P3V4X Slot-1 (with Asus slot1 to socket370 converter and Lin-Lin coppermine to tualatin adapter)
CPU: Pentium III 1.4Ghz Tualatin
Video card: Sparkle nVidia Fanless GeForce 6200 (256 MiB; AGP 4x/8x @ 4x)
AGP aperture: 128 MiB
config.sys and autoexec.bat: no relevant entries
system.ini:
MaxPhysPage=3E6FF ; (this value is the result of setting "Limit memory to 999 MB" in MSCONFIG's Advanced tab)
MaxFileCache=128000; 128 Mb
vmm32.vxd: plain vanilla (with 4.10.0.2222 vcache.vxd and vmm.vxd inside)

Каким образом здесь ограничивается ВЫДЕЛЯЕМЫЙ объем для кэша? По-моему никаким и человек имеет те же самые ВЫДЕЛЕННЫЕ 800 Мб со всеми вытекающими последствиями (а есть ли они будет понятно из ответа на первый вопрос)

Цитата:

например на системе с 1Гб и занятой зоной 0xD0000000-0xDFFFFFFF можно ограничить : MaxPhysPage=20000 (512Мб) и MaxFileCache=262143 (256Мб)

Вот нестандартных конфигураций сейчас приводить пожалуйста не надо. Это уже чисто практический вопрос, а нам (во всяком случае мне) сейчас нужно выяснить основы.

Цитата:

Теперь по поводу ваших данных - это какойто "косяк" из приведенного следует, что свободно все аж до 0xEC800000 (целых 712мб в диаппазоне 0xC0000000-0xEC800000)

Так у меня и винда без MaxFileCache грузится c 768 оперативки. Правда при запуске более или менее серьезных программ сразу заканчивается память. MaxPhysPage установлен в 768 Мб (2FFFF) чисто символически, подстраивать буду позже.

Цитата:

1) Точно опишите откуда вы эти цифры взяли.
2) Укажите полную конфигурацию оборудования.
3) Посмотрите еще отдельно, в свойствах устройства "видеоадаптер" какие ресурсы он занимает.
4) Если установлена еще и XP (или какая нибудь NT), гляньте теже цифры и в ней.

1. Взял оттуда откуда вы сказали (Просмотр ресурсов - Память). Если хотите могу привести [more=полный список]x00000000 - x0009FFFF Расширение системной платы для ACPI BIOS
x000A0000 - x000AFFFF ALL-IN-WONDER 9000
x000B0000 - x000BFFFF ALL-IN-WONDER 9000
x000C0000 - x000CCFFF ALL-IN-WONDER 9000
x000F0000 - x000FFFFF Расширение системной платы для ACPI BIOS
x00100000 - x2FFFFFFF Расширение системной платы для ACPI BIOS
xEC800000 - xEC80FFFF PCI Modem Enumerator
xED000000 - xED0000FF VIA PCI to USB Enhanced Host Controller
xEE000000 - xEE003FFF Хост-контроллер PCI OHCI совместимый с IEEE 1394
xEE800000 - xEE8007FF Хост-контроллер PCI OHCI совместимый с IEEE 1394
xEF000000 - xEF00FFFF ALL-IN-WONDER 9000 - Secondary
xEF000000 - xEFFFFFFF VIA CPU to AGP Controller
xEF020000 - xEF03FFFF ALL-IN-WONDER 9000
xEF800000 - xEF80FFFF ALL-IN-WONDER 9000
xF0000000 - xF3FFFFFF ALL-IN-WONDER 9000 - Secondary
xF0000000 - xFBFFFFFF VIA CPU to AGP Controller
xF8000000 - xFBFFFFFF ALL-IN-WONDER 9000
xFC000000 - xFDFFFFFF VIA Standard CPU to PCI Bridge
xFEE00000 - xFEE00FFF Расширение системной платы для ACPI BIOS
xFFF80000 - xFFFFFFFF Расширение системной платы для ACPI BIOS[/more] (экспортировал из программы "Сведения о системе")
2. Ой, да надо ли? Памяти 768 Мб (512 + 256)
3. EF020000 - EF03FFFF
EF800000 - EF80FFFF
F8000000 - FBFFFFFF
4. В NT смотреть не буду (перезагружаться надо), приведенных данных мне кажется будет достаточно.

Добавлено:

Опять про матчасть забыл, там же все инструкции есть в конце. В общем вычислил размер кэша, у меня получилось 729088. Дальше уже дело техники.

Добавлено:

А еще не могли бы вы выслать мне файлы VMM.VXD обеих версий, патченные с помощью RLP 3.2, а то у меня они не патчатся ("Unknown VCACHE file") И хотелось бы также заиметь отвязанную версию 2222, раз вы говорите, что Simplestas ее когда то выкладывал, если есть конечно.

SweetLow

Цитата:

Почему это мой драйвер только до 256 Мб ограничивает? От 16 (если правильно помню) до 4095.

ОК, сейчас исправлю.

BarHan

Цитата:

данный способ не только легко ставит режим DMA-UDMA для IDE устройств, но и делает это "принудительно", что может вызвать проблемы со старыми винтами

видимо из-за этого MS и не включала этот режим по умолчанию. Однако в XP уже включает, и никто не жалуется. Впрочем, можно ведь и ручками снять галочку, если знаешь, что винт глючит. А тем, кто не знает, что есть DMA - это вообще единственный способ получить быстрый обмен... В общем, мнения принимаются, пока новая сборка еще в обкатке!

IFkO

Цитата:

Однако в XP уже включает, и никто не жалуется.

В том-то и дело, что XP это делает "интелектуально", то бишь предварительно потестировав "реальную" возможность безглючности в данных режимах (причем при каждой загрузке).

Цитата:

Впрочем, можно ведь и ручками снять галочку, если знаешь, что винт глючит.

В том-то и дело, что при "автоматике" можешь не успеть, заглючивший винт не даст грузиться системе, а то и вообще что-нить важное порушит... навеки...
ЗЫ. Это я к тому, что нужно какое-нить предупреждение повесить с вопросом, ну шо, типа уверены в железе? Ставить в автозагрузку?

Цитата:

ЗЫ. Это я к тому, что нужно какое-нить предупреждение повесить с вопросом, ну шо, типа уверены в железе? Ставить в автозагрузку?

А много таких винтов? В смысле, я хотел в свой ЕСДИ такой же патч сделать... Теперь выходит - лучше не надо?

BarHan

Цитата:

XP это делает "интелектуально", то бишь предварительно потестировав

Откуда дровишки?

MERCURY127
Цитата:

А много таких винтов? В смысле, я хотел в свой ЕСДИ такой же патч сделать... Теперь выходит - лучше не надо?

Винтов и раньше было таких немного, сейчас нада постараться, чтобы найти, но учитывать нужно, поэтому ставить можно, но с предупреждением и опцией на автоматику...

IFkO
Цитата:

Откуда дровишки?

Отсюдова.

Поясните, чем отличаются 80-жильные кабели от 40-жильных? Ну, кроме упомянутых чисел?

MERCURY127
См. первое сообщение на странице http://forum.ru-board.com/topic.cgi?forum=62&topic=5745&start=60 , там все подробно описано.

MERCURY127

Цитата:

Поясните, чем отличаются 80-жильные кабели от 40-жильных? Ну, кроме упомянутых чисел?

Прежде всего, разрядностью шины данных (и пропускной способностью соответственно) - вдвое больше. В 80-жильных - те провода, которые ранее были "землями" идущими "через 1 провод" с шиной данных - стали дополнительными линиями данных, а "земли" - дополнительные провода между ними (почему и шаг стал вдвое меньше) которые в разъеме прокалываются специальным третьим рядом "ножей".
Seymour

Цитата:

Меня интересует как раз случай, когда VMM не пропатчен и используется параметр MaxFileCache.

Вы хотели сказать "VCACHE.VXD не пропатчен" ? VMM - к MaxFileCache - не имеет никакого отношения.

Цитата:

Будет ли доступен в этом случае НЕИСПОЛЬЗУЕМЫЙ, но ВЫДЕЛЯЕМЫЙ для кэша участок памяти другим программам?

Прошу прощенья, я немного запутал ситуацию: Выделяется не ПАМЯТЬ, а АДРЕСА в 4-м гигабайте. Память, если она там и есть (установлено 4Гб и более) - использоваться не может, почему и ограничивается объем 3Гб - максимум, со всеми патчами. Речь идет о том, расперделить под адреса кеш-а (потом туда динамчески мапится память, из "младших" 3Гб, выделенная под кеш), либо оставить для аппаратуры (не только видеокарты, вся аппаратура - равноценна, просто видяха - самый "большой кусок" ). Потому ваш вопрос - некорректен.

Цитата:

Это все хорошо, но зачем тогда на системах с памятью больше 1.5 Гб этот параметр устанавливается в значение больше 1 Гб (1164 Мб максимум). Это же противоречит самой сути этого ограничения? Для примера (взято отсюда):

Это попытка "найти логику в глюках" (причем такие попытки иногда бываеют удачными ) . Это ничему не противоречит, это попытка (причем АРХИКРИВАЯ) лечить глюк VMM, а не VCACHE, следуя идиотским рекомендациям микрософта. Ограничение ВЫДЕЛЯЕМЫХ под кеш адресов - тут "побочный эффект". Кеш ограничивается "отдельно",
параметром MaxFileCache, на меньшем значении.
На некоторых машинах я "проходил" параметром MaxPhysPage все значения от 1Гб, до 16Мб, с мелким шагом, и система так и не загрузилась.
В приведенном вами примере, человеку просто "повезло" что все это заработало (я так и не смог понять "от чего оно зависит" - системы тут не просматривается), но кстати еще вопрос, сколь стабильна при этом у него система, возможно просто тот набор софта, который он пользует, какимто образом "счастливо минует" все глюки, до поры до времени, например пока не попытается использовать весь гагабайт (что под 98 не очень часто бывает). Косвенно говорит о глючности то, что MaxFileCache у него выставлен в 128Мб : Я конечно не видел распределения адресов, но судя по всему на этом железе, свободны как минимум 256мб, а возможно и 512 (меньше 256 - только навороченные машины, с несколькими видяхами). Вполне вероятно, что у него просто возникает какойто "левый" глюк при больших значениях, хотя "наезда на аппаратуру" и не происходит.

Цитата:

По-моему никаким и человек имеет те же самые ВЫДЕЛЕННЫЕ 800 Мб со всеми вытекающими последствиями (а есть ли они будет понятно из ответа на первый вопрос)

Да, никаким, резервируется 800Мб. Последствий, по моим наблюдениям - никаких.


Цитата:

Если хотите могу привести полный список (экспортировал из программы "Сведения о системе")

Так, вот теперь все встало на свои места, вижу два куска по 64Мб, от видеокарты. Не очень прнятно, только почему в прошлый раз, у вас список кончался на "xEC800000 - xEC80FFFF PCI Modem Enumerator" ? может не заметили ползунок прокрутки сбоку от этого окошка ?
Как я и говорил, вам повезло (вернее просто железо старое) и у вас не заняты 712 мб адресов, до xEC800000 , можете ставить MaxFileCache=729087 и С КЕШЕМ у вас проблемм не будет. Когда кеш был 768 мб (и выделено и используется) - увас (видимо при полном его использовании) - происходил конфликт :

Цитата:

Правда при запуске более или менее серьезных программ сразу заканчивается память.

Надо ли вам делать что либо с VMM.VXD - дистанционно сказать не могу, возможно, что ничего и не надо, смотрите по глючности системы, после установки MaxFileCache=729087. Если глюки всеже останутся, тогда на выбор:
1) попробовать обрезать память параметром MaxPhysPage.
2) Сделать тоже самое посредством burnmem и иже с ним.
3) Поставить патченный VMM.VXD - просто скопировать его в папку system/vmm32 и перезагрузится. (Патченный VCACHE.VXD - вам не нужен, он там аж до 256мб "задушен").
Хотя я бы сразу поступил по 3-ему варианту , и наслаждался бы 768Мб, без глюков .

Цитата:

Так у меня и винда без MaxFileCache грузится c 768 оперативки

Ну это, что называется "нашел чем удивить", тем более на таком железе .
Вобщем это скорее правило, чем исключение.


Цитата:

И хотелось бы также заиметь отвязанную версию 2222, раз вы говорите, что Simplestas ее когда то выкладывал, если есть конечно.

я не сохранил. Выже сами задавали вопрос про размер файла, скорее всего у вас и есть этот самый файл v2222.
Только зачем ?

Цитата:

А еще не могли бы вы выслать мне файлы VMM.VXD обеих версий, патченные с помощью RLP 3.2, а то у меня они не патчатся ("Unknown VCACHE file")

А-а-а Не только у вас . Чтобы заставить эту пакость работать, надо хорошо постараться, там слишком много проверок, что это "именно тот файл", и вообще довольно сложный "исскуственный интелект", для "вытаскивания" из VMM32.VXD, проверки не лежит ли обновленный файл отдельно и т.д. , причем если хоть где-нибудь, что-то "не так" - он сразу вылетает и не патчит ВООБЩЕ НИЧЕГО. R.Loew тут перехитрил сам себя. Мне тоже сейчас воссоздавать ему "идеальную среду" - в лом, тем более, что тестовая машина сейчас не "на ходу", а рабочую - жалко.

maxud
Kirill666
Всем большое спасибо, вопрос о кобелях прояснился, но появился еще один: чтоб пользовать 80ЖК, винт должен иметь ТРИ ряда штырьков?

MERCURY127


Цитата:

чтоб пользовать 80ЖК, винт должен иметь ТРИ ряда штырьков?

НЕ-Е-ЕТ !!! Господь с вами . Третий ряд "ножей" - это отдельная деталь - такая металлическая "гребеночка" внутри разема: все "земляные" "ножи" - представляют из себя одну железку соединенную с несколькими (немного) контактами "земли" в "основных" 2 рядах. Кстати по этому у 80ЖК нельзя путать концы который к мамке, и к винту, даже если там нет Cable Select, кабель все равно ассиметричный.

Цитата:

у 80ЖК нельзя путать концы который к мамке, и к винту, даже если там нет Cable Select, кабель все равно ассиметричный.

Внешне 80ЖК и 40ЖК как то можно различить?

Kirill666

Цитата:

Прежде всего, разрядностью шины данных (и пропускной способностью соответственно) - вдвое больше. В 80-жильных - те провода, которые ранее были "землями" идущими "через 1 провод" с шиной данных - стали дополнительными линиями данных, а "земли" - дополнительные провода между ними (почему и шаг стал вдвое меньше) которые в разъеме прокалываются специальным третьим рядом "ножей".

Это уже злобный офтопик. НО! При всем моем уважении, НЕ ВВОДИТЕ ЛЮДЕЙ В ЗАБЛУЖДЕНИЕ!!!! В 80 жильном кабеле нет никаких дополнительных линий данных!!! Дело в том что при разработке стандарта UDMA66 возникла проблема ошибок обмена при работе на такой скорости, связанная со взаимными помехами между проводами. Поначалу пытались решить ее укорачиванем длины шлейфа. Это работало, но было неудобно. Поэтому был разработан новый шлейф в котором дополнительные земляные жилы шли между информационными и выполняли роль экрана, чем и достигалось уменьшение уровня взаимных наводок.

Добавлено:
MERCURY127

Цитата:

Внешне 80ЖК и 40ЖК как то можно различить?

Ну как Вам сказать Они отличаются колисеством жил!!! Посчитайте и будет счастье! А если серьезно то ширина шлейфа у них одинакова, а вот жила в два раза тоньше и это очень заметно на глаз. А проще всего посмотреть на цвет разъемов. У 40-ка жильного кабеля он одинаковый. У 80-ти жильного почти всегда разный, он же Cabel Select и функции разъемов разные. Иногда разъемы подписаны.

Kirill666

Цитата:

Прошу прощенья, я немного запутал ситуацию

Этим ответом вы запутали ее еще сильнее. Я может быть был не очень точен в терминологии, но суть вопроса изложил по-моему достаточно прозрачно. В общем повторяю вопрос.

Цитата:

MaxFileCache - ограничивает ИСПОЛЬЗУЕМЫЙ под кеш объем. Т.е. было ВЫДЕЛЕНО все равно 800, а ИСПОЛЬЗУЕТСЯ меньше

Будет ли доступен в этом случае НЕИСПОЛЬЗУЕМЫЙ, но ВЫДЕЛЯЕМЫЙ для кэша участок (?) памяти адресов другим программам? Видеокартам понятно, что будет, т.к. им другого выхода не остается из-за аппаратной привязки к этим адресам, а вот программам возможно будет сообщаться, что этот неиспользуемый кэшем участок памяти адресов зарезервирован и они его использовать не смогут. Я прав или нет?

Цитата:

Это попытка "найти логику в глюках" (причем такие попытки иногда бываеют удачными ) . Это ничему не противоречит, это попытка (причем АРХИКРИВАЯ) лечить глюк VMM

Все, понял, так и запишем.

Цитата:

В приведенном вами примере, человеку просто "повезло" что все это заработало

Счастливчик, причем он один такой в этом списке. Может он просто так прикалывается?

Цитата:

Не очень прнятно, только почему в прошлый раз, у вас список кончался на "xEC800000 - xEC80FFFF PCI Modem Enumerator"

Ну так вы же сказали до первого устройства, а модем это разве не устройство? Вопрос риторический.

Цитата:

можете ставить MaxFileCache=729087

А один килобайт куда делся?

Цитата:

Хотя я бы сразу поступил по 3-ему варианту , и наслаждался бы 768Мб, без глюков

Ну может так и сделаю, спасибо за помощь.

Цитата:

Выже сами задавали вопрос про размер файла, скорее всего у вас и есть этот самый файл v2222.

Тот что был обрезанный это VCACHE.VXD, а VMM там версии 2226 был.

Цитата:

Только зачем ?

"Нада." (c)

Цитата:

Мне тоже сейчас воссоздавать ему "идеальную среду" - в лом, тем более, что тестовая машина сейчас не "на ходу", а рабочую - жалко.

А, ну и бог с ними тогда, обойдусь.

Kirill666

Цитата:

Кстати по этому у 80ЖК нельзя путать концы который к мамке, и к винту, даже если там нет Cable Select, кабель все равно ассиметричный.

Путать их можно и часто все будет нормально работать. Различие функциональности разъемов сделано только для реализации функции Cabel Select.

MERCURY127

Цитата:

Внешне 80ЖК и 40ЖК как то можно различить?

Раземы - нет, если не считать того, что они обычно разноцветные (цветовая маркировка, какой куда втыкать) , а не черные.
Сам кабель - видно, что вдвое более мелкий шаг проводов.
maxud
Прошу прощенья, сейчас прояснил вопрос: Действительно переход на 16бит, произошел независимо от перехода на 80жил, но в 8битном IDE - контакты 4,6,8,10,12,14,16,18 - были заземлены. Потом их отдали под данные, а потом уже ввели доп. земли. (80жил.) Эти события не связаны, я был не прав.

Kirill666

И еще, давайте все-таки определимся, что вы подразумеваете под глюком VMM? Т.к. воочию мне этот глюк наблюдать не приходилось хотелось бы знать в чем он выражается и в чем его особенности на машинах с большим кол-вом оперативки (больше 2 Гб).

Цитата:

Будет ли доступен в этом случае НЕИСПОЛЬЗУЕМЫЙ, но ВЫДЕЛЯЕМЫЙ для кэша участок (?) памяти адресов другим программам?

Нет, на деле, как кеш этот участок использоваться не будет (никем), ибо любая попытка - тутже приведет к конфликту с видяхой. Этот учаток будет использоваться для доступа к видяхе (всеми программами, кому надо), и только к ней (ну или другому железу если оно там есть).

Цитата:

Счастливчик, причем он один такой в этом списке. Может он просто так прикалывается?

Скорее это до первой попытки попробовать, запустить что нибудь "тяжелое".

Цитата:

А один килобайт куда делся?

А перестраховка, возможно излишняя, но килобайта - не жалко. Просто я не где не встречал, точно как там сделана проверка: на "не больше" на "менише", а рекомендации видел и так и так. Отлавливать пересечение на 1 кб - очень трудно (проявлятся будет очень редко) , вот я и прерстраховываюсь. Возможно это и параноя

Цитата:

"Нада." (c)

Ну тады ищите ссылку там, где выкладывали V2226, только на страничку по раньше, оно было.





Добавлено:

Цитата:

И еще, давайте все-таки определимся, что вы подразумеваете под глюком VMM? Т.к. воочию мне этот глюк наблюдать не приходилось хотелось бы знать в чем он выражается и в чем его особенности на машинах с большим кол-вом оперативки (больше 2 Гб).

В невозможности загрузится, даже если и ограничен кеш. Иногда (редко) загрузится всеже удается но глючит нипадеццки.

Kirill666

Цитата:

Нет, на деле, как кеш этот участок использоваться не будет (никем), ибо любая попытка - тутже приведет к конфликту с видяхой. Этот учаток будет использоваться для доступа к видяхе (всеми программами, кому надо), и только к ней (ну или другому железу если оно там есть).

Ааа, то есть программы туда ломиться не будут (не к видяхе, а по своим нуждам) я так понял и этот участок можно считать "свободным"? То есть мое утверждение, что:

Цитата:

Кэш ограничивается для того, чтобы исключить возможные конфликты с аппаратурой. Памяти при этом он будет занимать столько же, сколько и раньше, поскольку VMM драйвер не учитывает при резервировании памяти для кэша параметр MaxFileCache

Неверно?

Seymour
Тут уже начинается казуистика. Что такое резервировано но не используется ? Это значит, что где то в какой-то переменной стоит граница этого пространства "вот столько", но в эту область никогда не будет записано(cчитано) ни одного байта.

Цитата:

Ааа, то есть программы туда ломиться не будут

нет, похоже что не будут, длительные наблюдения при использовании большого количества софта показывают что это так.
Прикладной софт, минуя драйвер, в кеш не лазает вообще (вернее лазает но исключительно по полученным от драйвера указателям), а драйвер похоже "честно" соблюдает установленную границу , и здесь мелкомягкие вроде ничего не напортачили (что удивительно).
Не возникнет ли где еще багов, из-за того, что кто-нибудь из софта, использует границу резервированной области вместо границы используемой, и таки запишет что нибудь туда куда не надо, я конечно на 100% гарантировать не могу, но наблюдения показывают, что похоже это так. Да и плохо я себе представляю столь нестандартную софтину, которая сама будет работать с кешем, разве что какой-нибудь особо ехидный сторонний системный драйвер (нафига бы он был нужен ? ).

Цитата:

То есть мое утверждение, что:
............
Неверно?

Да, неверно.

BarHan
из статьи следует, что ничего XP предварительно не тестирует: она имеет список устройств, о которых уже известно, что они глючат при использовании DMA. Для прочих же "звоночком" будет 6 ошибок при передаче данных. Это конечно лучше, чем ничего, но считать это предварительной проверкой, исключающей последующую потерю данных, никак нельзя.

Kirill666

Цитата:

но в эту область никогда не будет записано(cчитано) ни одного байта.

Кэшем.. Но я то спрашиваю про программы. Почему при налезании трехсот лишних мегабайт кэша на аппаратную область перестают запускаться DOS программы, ведь по вашему получается, что они к этой области не имеют никакого отношения и памяти им должно хватать в любом случае. Значит все-таки какие-то адреса из этого трехсотмегабайтного участка ими используются? Вот я и спрашиваю, если ограничить кэш параметром MaxFileCache смогут ли эти программы обращаться к этим адресам или система будет им в этом отказывать, ссылаясь на то, что этот участок зарезервирован под кэш?

Цитата:

область перестают запускаться DOS программы, ведь по вашему получается, что они к этой области не имеют никакого отношения и памяти им должно хватать в любом случае.

Для виртуальных машин DOS - адреса отводятся в кеше (причем как раз, от "вехней границы" - вниз, как я читал). Поэтому DOS - это как раз первое, что разваливается при конфликтах кеша с аппаратурой. Еще тамже живут программы 0-го уровня привелегий (ядро системы, некоторые драйверы) не знаю точно какой там механизм распределения памяти, через кеш, или "в обход" (возможно просто максимальный адрес берется из драйвера кеша), но вроде тоже в неиспользуемую часть они не лезут.
Хотя возможно, что именно тут гдето чтото и разваливается, при непропатченном VMM.VXD, (но тогда должно бы ограничение MaxPhysPage помогать, а это не так).
Это все просто уже нигде не документировано, потому точно ответить на ваш вопрос:

Цитата:

Вот я и спрашиваю, если ограничить кэш параметром MaxFileCache смогут ли эти программы обращаться к этим адресам или система будет им в этом отказывать, ссылаясь на то, что этот участок зарезервирован под кэш?

я не могу, но с большой долей вероятности ответ все-таки "не смогут". Вообще-то скорее всего, "система будет им в этом отказывать, ссылаясь на то, что этот участок зарезервирован под" аппаратуру. (это на попытку сотворить в этой области что-либо, к кешу не относящееся).
Если так уж волнует данный вопрос, ну сделайте себе "'эксклюзивный" VCACHE.VXD, с ограничением в 712 мб и сравните.

MERCURY127

Цитата:

я хотел в свой ЕСДИ такой же патч сделать..

вот тут как раз может быть облом: если он будет включать DMA каждый раз при загрузке, то для кривого железа отключить DMA будет непросто... если только запоминать, что однажды на этом устройстве DMA уже включали, и не повторять для него впредь.

Чем больше я копаюсь в недрах Win98, тем глубже убеждаюсь: ее творцы сделали все, чтоб урезать ее функциональность, еще на этапе создания!!! ЕСДИ читает модель винта САМ (без всяких патчей !!!), он знает как ее взять, он меня в нее носом тычет (!!!), в ВинАйсе, конечно! Он ее читает, а затем перебирает по своему внутр. списку (!). Зачем, я так и не понял. Но помилуйте, ежели вы, б...., знаете где модель лежит, ежели вы САМИ пишете ее в реестр (!!!), в другое место, так что ж вы, б...., выдаете "Generic bububu..." там, где ее надо !?!?!?
Извините за некультурность, просто за душу взяло ... Прошу не судить строго...

Добавлено:
IFkO

Цитата:

если только запоминать, что однажды на этом устройстве DMA уже включали, и не повторять для него впредь.

Ну это уже вам будет проще сделать, чтоб ключ "IDEDMADRIVE" в реестре устанавливался не в 0, как в дефолте, а в не-0... Тогда и патч не нужон будет, и если ключ все же будет сброшен (неважно, юзверем или дровами), ДМА больше не будет включаться... Просто и надежно .

PS: Класс, сколько смайлов ... СУПЕР !!!

MERCURY127

Цитата:

чтоб ключ "IDEDMADRIVE" в реестре устанавливался

Щаз! А проверять, поддерживается ли вообще DMA, кто будет???

2BarHan, IFkO, MERCURY127: Проблема с принудительным включением DMA не только со старыми винтами (это ж насколько старым он должен быть?! 200Мбайт, что ли? :-D ). Для невозможности работать в DMA-режимах достаточно вдавить/обломать ножку в IDE-разъёме. Что нередко и проделывают те, кто носят-переключают винты: если перевернуть шлейф вверх ногами, то ключевой - отсутствующий - контакт как раз вдавливает эту ногу. Винт (ессно, после переворачивания шлейфа в обычное положение) работает... но только в PIO :-)
Ессно, на разъёмах есть ключи - но народ у нас могучий, даже Molex'ы ухитряется в перевёрнутом положинии вбивать :-)
Кстати, такой - однажды отказавшийся работать по DMA - винт система (XP - точно) запомнит и будет выставлять ему PIO и после ремонта ноги. Выше писАли про ключ реестра, который надо грохнуть, чтоб ОС наново "познакомилась" с этим хардом.