Ru-Board.club
← Вернуться в раздел «Microsoft Windows»

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

Автор: MERCURY127
Дата сообщения: 05.04.2009 17:58

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

Ну, как хотите !!! Ведь мы же не боимся один разок включить галку в диалоге, чтоб после перезагрузки понять
Цитата:
поддерживается ли вообще DMA
??? Эффект будет тот же... т.е. если ДМА не поддерживается, флаг и ключ будут сброшены, и больше система даже не попытается его включить (как по умолчанию). Понятно?
Автор: Seymour
Дата сообщения: 05.04.2009 22:06
Kirill666

Цитата:
Если так уж волнует данный вопрос, ну сделайте себе "'эксклюзивный" VCACHE.VXD, с ограничением в 712 мб и сравните.

VCACHE делать не стал, ограничился параметром MaxFileCache и получилось, что при рекомендованном вами значении в 729087 Кб память для DOS программ у меня закончилась быстрее, чем при меньших значениях этого параметра. К примеру вообще без этого параметра мне удалось запустить только 7 копий FAR менеджера, при значении 729087 - 16, а при значении 524288 - аж 55. А это означает, что та самая ВЫДЕЛЕННАЯ, но НЕИСПОЛЬЗУЕМАЯ часть адресов о которой я вас спрашивал все-таки используется DOS программами, причем никаких конфликтов при этом не происходит, то есть мое утверждение, что "памяти при этом кэш будет занимать столько же, сколько и раньше" действительно неверно, но и ваша рекомендация ставить значение MaxFileCache "впритык" к аппаратуре тоже. Вернее его действительно нужно ставить "впритык", но не более 512-ти мегабайт, потому как последующие адреса используются не только аппаратурой, но и подсистемой DOS.

Цитата:
Т.е. было ВЫДЕЛЕНО все равно 800, а ИСПОЛЬЗУЕТСЯ меньше, в отличии от патча VCACHE.VXD, или ограничения доступной оперативы, когда память не только не используется но и не резервируется.

А почему вы считаете, что при использовании патченного VCACHE.VXD память "не резервируется"? По-моему точно также резервируется, как и в случае с параметром MaxFileCache, ведь резервирует память драйвер VMM, а VCACHE.VXD только использует выделенный ему участок памяти и на количество выделяемых ему адресов влиять не может. Цитата из матчасти:

Цитата:
Дело в том, что распределение памяти выполняет диспетчер виртуальных машин и «заглядывает» при этом только в свой раздел файла system.ini, [386Enh]. А ограничение размера кэша задается в другом разделе и влияет лишь на работу самого кэша, в частности, на использование выделенного ему адресного пространства.

Так что патченный VCACHE перед параметром MaxFileCache имхо не имеет никаких преимуществ за исключением того, что он может использоваться в SafeMode.

Цитата:
А MaxPhysPage - мелкомягкие рекомендуют использовать для борьбы с ошибкой VMM.VXD, причем если память ограничивается до соотв величины, то MaxFileCache - может и не понадобится

MaxFileCache - параметр обязательный, без применения патчей он должен использоваться всегда, ибо как вы сами ранее отмечали MaxPhysPage не эквивалентен ограничению памяти до загрузки Windows и размер кэша при его использовании вычисляется неправильно. Сам в этом убедился выставив этот параметр в 512 Мб и удалив параметр MaxFileCache - после перезагрузки у меня запустилось только 13 копий FAR'а, а значит размер кэша драйвером VMM был выставлен в ~720 Мб вместо ожидаемых 512-ти. Так что MaxFileCache без MaxPhysPage использовать можно (и то только с памятью меньше 1 Гб), но никак не наоборот.

P.S. Довел до ума инструкцию, просьба ознакомиться и внести необходимые поправки.
Автор: MERCURY127
Дата сообщения: 06.04.2009 10:00

Цитата:
P.S. Довел до ума инструкцию, просьба ознакомиться и внести необходимые поправки

По моему, MsConfig не позволяет выставлять значения MaxPhysPage > 999 MiB ?
Автор: SweetLow
Дата сообщения: 06.04.2009 10:42
MERCURY127

Цитата:
А если быть совсем точным, он грузится до HIMEM.SYS и подменяет некоторые вызовы BIOS... Правильно?

Правильно, только у меня <<патчит>> закавычено
Автор: and23
Дата сообщения: 06.04.2009 14:32
2Seymour: А с каких пор Far стал DOS-программой? Вернее, даже так скажу: "Хочу Far под DOS!" :-)

Опять путаем "DOS/Windows" с "консольным/гуёвым"? ;-)
Автор: MERCURY127
Дата сообщения: 06.04.2009 16:40
and23

Цитата:
Опять путаем "DOS/Windows" с "консольным/гуёвым"?

Консольный ли, досовый ли - но это было мое первое знакомство с описываемой проблемой... "С горя начал он кудесить, и гонца хотел ... " .
Автор: CBB
Дата сообщения: 06.04.2009 18:43
and23

Цитата:
"Хочу Far под DOS!"

Да пожалуйста
Автор: IFkO
Дата сообщения: 06.04.2009 20:53
Так....
Обновил тестовый DrWeb 5.0 (не только базы данных, но и прочее)
Выложил драйвер принтера Xerox WorkCentre M15
Выложил тестовую сборку обновленных кодеков: обновлены ffdshow до упора (rev.2322) и Windows Media до 10
Прошу отзывов, ибо все это сырье уже нацелилось на новую сборку системы! Я ведь поверю, что все работает, если вы будете отмалчиваться!!!
Особенно интересуют кодеки, поскольку у меня и прежние поигрывали все мои тестовые файлы. То есть я до сих пор не знаю, стало ли лучше от их обновления?
Автор: arnyc
Дата сообщения: 06.04.2009 23:09
На лаптопе стоит Win98SE с UnSP2.1a и Paragon NTFS for Win98 драйвер. Два вопроса:

- нельзя отсоединить USB2.0 PC Card. Т.е. в винде делаю Unplug, Eject, подтверждает что карту можно вынуть. Но в Device Manager она остаётся, и при попытке её Удалить комп зависает. А так при замене на другую карту комп даёт ошибку: не хватает памяти для карты. Приходится перезагружать каждый раз. Что посоветуете?

- Копирую файлы на внешний NTFS диск в FastCopy с записью "через буфер ОС". Получается в 2-3 раза быстрее. Но, похоже, нужные функции Win API не распознают файлы больше 2Гб, закончить такие не удаётся. В обход буфера вообще не копирует на NTFS. При копировании на FAT32 нормально копирую файлы до 4ГБ. В Проводнике такие большие файлы скопировать не могу из-за перегрева харда, и нельзя сделать паузу. В чём загвоздка с NTFS диском?
Автор: Kirill666
Дата сообщения: 07.04.2009 07:20
Seymour
Ну как вам уже сказали FAR - не есть DOS-программа, запускайте хотябы command.com,
если нет ничего иного.

Цитата:
но и ваша рекомендация ставить значение MaxFileCache "впритык" к аппаратуре тоже. Вернее его действительно нужно ставить "впритык", но не более 512-ти мегабайт, потому как последующие адреса используются не только аппаратурой, но и подсистемой DOS.

А если всетаки пропатчить VMM.VXD (RLP 3.2) ?
Цитата:
А почему вы считаете, что при использовании патченного VCACHE.VXD память "не резервируется"?
Потому что "число звериное" 800 Мб, которое используется при РЕЗЕРВИРОВАНИИ - находится именно в нем (оно и патчится).

Цитата:
А MaxPhysPage - мелкомягкие рекомендуют использовать для борьбы с ошибкой VMM.VXD, причем если память ограничивается до соотв величины, то MaxFileCache - может и не понадобится

Я имел в виду, что если MaxPhysPage - ограничен до достаточно низкого уровня - объем оставленной памяти, меньше допустимого объема кеша - MaxFileCache ставить уже не зачем.
Цитата:
размер кэша при его использовании вычисляется неправильно.

А вот этого я уже не утверждал (хотя возможно это и так), результаты вашего эксперимента можно интерпретировать по разному. Опять таки, что будет с патченным
VMM.VXD ?



Автор: MERCURY127
Дата сообщения: 07.04.2009 13:57
Kirill666
Драйвер для видеокарты нВидии скачал (спасибо IfKO, выложил компактную версию). Пока не тестировал, хотелось бы спросить: глюк хоть как то лечится волшебными клавишами а-ля Alt+Tab ?
Автор: Seymour
Дата сообщения: 07.04.2009 21:37
MERCURY127

Цитата:
По моему, MsConfig не позволяет выставлять значения MaxPhysPage > 999 MiB ?

Ну, думаю, это и так будет понятно, просто если каждый момент в подробностях расписывать инструкция станет в два раза толще.

and23

Цитата:
Опять путаем "DOS/Windows" с "консольным/гуёвым"?

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

MERCURY127

Цитата:
Консольный ли, досовый ли - но это было мое первое знакомство с описываемой проблемой... "С горя начал он кудесить, и гонца хотел ... "

Вот вот.

Kirill666

Цитата:
Ну как вам уже сказали FAR - не есть DOS-программа, запускайте хотябы command.com, если нет ничего иного.

Да иного то полно, просто FAR - это первое что попалось под руку. Забыл что он реально консольный, а не досовый, но ведь так похож с виду. Ну, в общем заменил FAR на NC 5.0 - ситуация не изменилась. Результаты почти такие же, за исключением варианта с MaxFileCache=524288 - Norton'а с этим ограничением удалось запустить на 10 копий больше.

Цитата:
А если всетаки пропатчить VMM.VXD (RLP 3.2) ?

Никакой разницы - результаты те же, что с версией 3.2, что с 5.0, то есть на глюк VMM незапуск DOS'овых прог с кэшем больше 512-ти мегабайт не спишешь.

Цитата:
Потому что "число звериное" 800 Мб, которое используется при РЕЗЕРВИРОВАНИИ - находится именно в нем (оно и патчится).

Все-таки мне кажется, что не только в нем. Возможно я ошибаюсь, но, если опять таки верить цитате из матчасти, драйвер VCACHE, при резервировании памяти не участвует вообще, а число это звериное в нем присутствует просто для перестраховки, на случай возникновения глюков с VMM, о которых разработчики знали еще при разработке. Хотя конечно лучше все-таки пропатчить, чтоб не заморачиваться с MaxFileCache и SafeMod'ом, только я так и не понял, как по этой таблице из второго поста вычислять нужные байты для нестандартных размеров кэша? Объясните хотя бы на моем примере со значением в 729087 Кб...

Цитата:
Я имел в виду, что если MaxPhysPage - ограничен до достаточно низкого уровня - объем оставленной памяти, меньше допустимого объема кеша - MaxFileCache ставить уже не зачем.

А, ну это другое дело, только на практике до таких низких отметок этот параметр никто ограничивать не будет.

Цитата:
Опять таки, что будет с патченным VMM.VXD ?

Все то же самое. Даже с патченным VMM.VXD (3.2 и 5.0) размер кэша вычисляется неправильно.

Добавлено:

А вот этого я уже понять не могу. По показаниям системного монитора с параметром MaxPhysPage=1FFFF (512 Мб) кэш устанавливается в 491.4 Мб, то есть размер кэша все-таки вычисляется правильно, а вот распределяется он в памяти некорректно. Видимо так. Из этого следует, что RAM LIMITATION PATCH от R. Loew не устраняет глюка VMM, он только увеличивает объем доступной памяти с 1164 Мб до 3 Гб, а проблема с кэшем лечится тем же банальным способом с пропатчиванием драйвера VCACHE...
Автор: Kirill666
Дата сообщения: 08.04.2009 02:08
MERCURY127

Цитата:
хотелось бы спросить: глюк хоть как то лечится волшебными клавишами а-ля Alt+Tab ?
. Лечится, и не как-то, а самым что ни есть нормальным образом . Просто, после каждого, например, выхода из PCAD-а - нажимать эти клавиши - довольно напряжно.

Seymour

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

Там просто лежит (в 2-копиях) двоичное 16-битное число, в МЕГАБАЙТАХ (по 1024кб, по 1024б ) , младшим байтом вперед, как это принято у Intel, вот и все .
Например: 512мб 512 = 0x0200 - записываем значения 00 02 .

Цитата:
Объясните хотя бы на моем примере со значением в 729087 Кб...

Ну если вы настаиваете то 729087 Кб = 712Мб - 0x02C8 - пишем байты С8, 02, С8, 02 по указанным смещениям.


Цитата:
А, ну это другое дело, только на практике до таких низких отметок этот параметр никто ограничивать не будет.

Ну почему, до 512мб - вполне реальный случай, до появления RLP - сам так жил.

Цитата:
он только увеличивает объем доступной памяти с 1164 Мб до 3 Гб, а проблема с кэшем лечится тем же банальным способом с пропатчиванием драйвера VCACHE..

Два важных замечания:
1) Он не только увеличивает до 3 Гб, но и ограничивает этим значением, т.е. делает систему нечувствительной, к сколь угодно большим обьемам памяти, давеча видел пример установки на машину с 8Гб (видно, естественно 3)
2) RLP - сам пропатчивает драйвер VCACHE.VXD, по умолчанию - на 512 Мб, но значение можно задать патчеру из командной строки.

arnyc
Я не берусь ответить на ваш вопрос по NTFS. Но мой вам совет: побороться с перегревом харда АППАРАТНЫМИ методами. Ибо если у вас диск перегревается до "сбойного" состояния при копировании болшого файла, это значит что ему там и во все остальное время - "не сладко", и надежность у него при этом - низкая. Если это ваш "резервный диск", то эксплуатировать его в таком режиме - полнейшее безумие.
Если справитесь с перегревом - ваш вопрос снимется "автоматически", а если не справитесь, то как например, вы собираетесь scandisc там гонять ? (а ошибок при такой работе там уже должно накопится немало). В любом случае: диск который перегревается при копировании файла в 4Гб - это не диск, а кусок г###а, и с ним надо чтото делать .
Если это обычный 3.5" диск в "боксе" - попробуйте оборудовать его вентелятором, либо купить нормальный "бокс". Некоторые диски, например Hitachi (IBM) - вообще не приспособлены к установке в "боксы", увы, и через полгода там подыхают от перегрева.
Если это покупной, внешний, 2.5" HDD, установленный "в коробку", уже на заводе, то при наличии гарантии - отнести в магазин, и засунуть продавцу в соотв. место, с особым цинизмом. Если гарантия уже закончилась - попробовать доработать.
Если перегревается какая-то микросхема на плате контроллера, то бывает полезно приклеить к ней кусок медной фольги (0.2-0.5мм), на теплопроводный клей вроде АЛСИЛ-5, или иной радиатор (например радиатор для чипов памяти). Найти перегевающуюся микросхему - просто: включаете (открыв "бокс", чтобы была доступна плата контроллера на жестком диске), запускаете копирование длинного файла, или scandisc, с проверкой поверхности (диск обязаельно должен "работать", потому как частенько перегревается микруха, которая управляет приводом головки, (по симптомам похоже на ваш случай) а "в покое" она может быть и вообще холодной), после нескольких минут работы щупаете пальцем все микросхемы на плате, там где "палец не терпит" - приклеиваете радиаторы (конструкция зависит от конкретного случая).
Короче, устраняйте не следствие, а причину. Удачи.
Автор: MERCURY127
Дата сообщения: 08.04.2009 15:05
ВСЕМ
Есть две новости, хорошая и плохая .

Хорошая: похоже, я довел до ума патч к ЕСДИ ... впрочем, довел до ума - мягко сказано - я его полностью переделал! Еще немножко потестирую - и выложу... куда - см. выше . Могу только сказать, что перспективы большие: вы наконец сможете выбросить из шапки оба половинчатых способа, висевших там годами (!), и заменить их на простой и окультуренный и, как я теперь уверен, надежный и безглючный ЕСДИ...

Плохая: драйвер к нВидии поставил, с глюком ознакомился (смотрел JPG/PNG в NC)...
Автор: and23
Дата сообщения: 08.04.2009 18:01
2CBB: ОГРОМНЕЙШЕЕ спасибо! Осталось настроить DOS-сессию - и вопрос с файл-менеджером - и не только с ним - под DOS можно (тьфу-тьфу-тьфу!) считать решённым.

Кстати, о консолях. Кто-нибудь из присутствующих знает заменитель консольного менеджера - winoa386.mod aka winoldap? Или хотя бы попытки такой заменитель создать? А то больно уж крива 9x-консоль :-(

P.S. (offtopic) Ещё б для полного счастья Far под Linux... (а то Midnight Commander утомил).
Автор: IFkO
Дата сообщения: 08.04.2009 19:09
Никто так и не отозвался об откате драйвера RIVA до 4.12.01.0365 русского... То ли он никому не нужен, то ли к нему нет претензий, то ли все, кто его скачал, сразу умерли....
Предполагая лучшее, я включил его в сборку драйверов nVidia "3 в 1" взамен прежнего и выложил ее - см. прежнюю ссылку на странице 24.


Цитата:
Если перегревается какая-то микросхема на плате контроллера
был на моей памяти случай, когда умирающий винт Fujitsu MPG (есть такой грех за этой серией - они все умерли от трещин на контроллере из-за перегрева) вылечили переводом на пониженный DMA (то ли с 66 на 33, то ли вообще не помню...). Так вот, он стал меньше греться, перестал глючить, но все равно умер с тем же диагнозом через год.


Цитата:
безглючный ЕСДИ
аксиома: каждая программа содержит конечное число ошибок. Теорема: сложность каждой программы растет, пока не превысит способности программиста. Но вообще прошу всех это попробовать, а то в следующую сборку 98IF может попасть полуфабрикат, а не хотелось бы.

Цитата:
драйвер к нВидии поставил, с глюком ознакомился
и что в этом плохого?


Автор: EDantes
Дата сообщения: 08.04.2009 20:20
никто не слышал-нет ли драйвера под 9х (или dos) для exfat (aka fat64) ?
теоретически это значительно проще, чем драйвер для ntfs
Автор: Kirill666
Дата сообщения: 09.04.2009 00:24
IFkO

Цитата:
был на моей памяти случай, когда умирающий винт Fujitsu MPG (есть такой грех за этой серией - они все умерли от трещин на контроллере из-за перегрева) вылечили переводом на пониженный DMA (то ли с 66 на 33, то ли вообще не помню...).

Тут другое, Fujitsu MPG это очень известная вещь (было даже несколько статей посвященных именно ремонту этой серии), я сам таких вылечил, поболее десятка.
Основная пакость, в том, что там был применен какойто очень агрессивный флюс при пайке (характерный признак - при повторном оплавлении пенится насыщенно желтой пеной). Они надежно лечились повторной пропайкой платы контроллера, в основном - самой большой микросхемы Cirrus Logic (аккуратненько оплавить припой посредством строительного фена, хотя можно конечно и паяльником - (208 ног с шагом 0.5мм гы-гы)), с последующей промывкой от остатков флюса, и после этого работали - как швейцарские, часы в швейцарском банке
Там правда на ранних партиях требовалось еще обновить прошивку (имелся баг который приводил к потере данных), я с этим не сталкивался, но писали. Но это не похоже на ваш случай, у вас скорее всего микоротрещина в пайке (отслоение припоя), которая постепенно окислялась и расширялась, сначала контакт нарушался при высокой температуре, а потом и при любой. Кстати если еще не выкинули - наверняка можно реанимировать таким образом. главное отмыть потом хорошо, а то через полгода опять начнет глючить, и придется повторять процедуру.

MERCURY127
Надеюсь за основу был взят ESDI с патчем LBA48?
Автор: maxud
Дата сообщения: 09.04.2009 07:37
Kirill666

Цитата:
Основная пакость, в том, что там был применен какойто очень агрессивный флюс

Это конечно офтоп. Но.
Почитайте форум iXBT по фуджам, будете очень удивлены (Ваша теория в корне не верна). Кстати очень познавательно чисто с точки зрения исследователя и инженера: как не надо проектировать микросхемы..
Автор: MERCURY127
Дата сообщения: 09.04.2009 10:10
Обновленная версия DMR патча по ссылке на стр 63, эта версия полностью работоспособна, в том числе и под эмулятором (проверено на VMWare). Единственный оставшийся недостаток - пробел посреди модели, это особенность ЕСДИ, как его убрать, я не знаю...

Kirill666

Цитата:
Надеюсь за основу был взят ESDI с патчем LBA48?

!!! ЕСТЕСТВЕННО !!! Но пропатчить можно любой вариант - новый патч ОЧЕНЬ прост ...

IFkO

Цитата:
аксиома: каждая программа содержит конечное число ошибок

Вы сами его (ЕСДИ) хвалили, когда сравнивали с родными дровами для чипсетов. Не мой конкретно - его еще не было в природе, но вообще. Так что не придирайтесь - модель винта ЛЮБОЙ ЕСДИ читает сам, я это видел в ВинАйсе, моя задача - заставить его еще и писать модель куда следует. Ибо он сам пишет ее куда угодно, только не туда, где мы ее видим ...
Автор: IFkO
Дата сообщения: 09.04.2009 11:03
Kirill666

Цитата:
Тут другое, Fujitsu MPG это очень известная вещь
Да я не о нем вовсе, это просто пример того, что перегрев лечится, и лечить его нужно... хотя летальный исход все равно возможен. А наш винт - он стоял на казенном учете, мы его сдали куда положено и забыли о нем навсегда.
PS
Я Вам личное сообщение вчера отправил...

MERCURY127

Цитата:
Вы сами его (ЕСДИ) хвалили
я и сейчас хвалю, только ехидничаю, чтобы народ не терял бдительность. Вообще я предполагаю, что продукт MS принципиально не пишет модель винта: он сверяет со своей базой данных, нужен ли к нему ОСОБЫЙ подход, и если нет, то так и пишет, что это - самый обычный (GENERIC) HDD. А вот если за ним числятся глюки либо фичи - я с этой ситуацией не сталкивался, об этом нам могут расказать те, кто видел винты, не любящие DMA (к примеру).
Автор: maxud
Дата сообщения: 09.04.2009 15:45
MERCURY127
На страничке с DRM написано что в архиве описание патча, там только патченная верися, описания нет. Также надо обязательно править версию (на 2231, например), шоб не заменялся при обновлениях.
Автор: IFkO
Дата сообщения: 09.04.2009 18:16
Да, в DC++ добавил русский язык.
Автор: SerbeyBV
Дата сообщения: 09.04.2009 21:52
Народ, кто очень хорошо разбирается в Windows 98 подскажите пожалуйста
несколько вещей:

1. Как из командной строки или ярлыка открыть окошко Run (которое из Start
Menu -> Run)?
2. Как открыть системный Help and Support из командной строки или ярлыка -
на какой файл ссылаться?
3. Как открыть оттуда же поиск?
4. Панели Управления соответствует какая-либо реальная папка? Если нет, то
как ее открыть оттуда же?
5. Можно ли как-то в Win98 создать ярлык не на конкретный браузер и почтовый
клиент, а на запускаемые по умолчанию?
6. Как называется и где находится папка "Главное меню" в английской версии
винды, а то у меня таковой нет, чтоб проверить.

Ответы мне нужны именно для Win98, для XP я большую часть и сам знаю.
Автор: Kirill666
Дата сообщения: 10.04.2009 00:55
maxud

Цитата:
будете очень удивлены (Ваша теория в корне не верна). Кстати очень познавательно чисто с точки зрения исследователя и инженера: как не надо проектировать микросхемы..

Проблемму я, в свое время, изучил ОЧЕНЬ хорошо пречитал немало, в т.ч. и на iXBT.
Тут у вас действительно "не забалуешь" ( (c) Seymour) придется выкладывать до конца, раз уж "пошла такая пьянка" .
Итак поправлюсь: фуджикам действительно "повезло", там в нескольких разных партиях, были разные "подарки". С остальным из описанного в сети я не встречался (к нам попали винты уже с "правильной" прошивкой, и без других глюков) прегрев сервомикросхемы контроллера головок - имеет место быть (кстати, возможно, вот тут как раз и была деградация чипа под действием перегрева и остатков флюса), но там все не особо страшно (тоже пропаять, промыть, налепить радиатор), про деградацию чипа контроллера слышал, но сам не сталкивался (видимо 99% отказов - всеже неправильная пайка).
Пропайкой и промывкой самолично вылечил столько, что уже сбился, со счета (явно больше 10 ), немало удалось "приватизировать", как дохлые. Если все сделать правильно и своевременно, то они живут "долго и счастливо", некоторые (которые мне удается отслеживать) - работают до сих пор, либо были сняты рабочими, и заменены на большего объема.

Если интересно - почитайте: http://www.hardw.net/doc/91.htm
Цитаты оттуда:

Цитата:
Оказалось, что почти на всех заводах по сборке этих винтов применялся какой-то очень агрессивный флюс, который не удаляли с монтажа после сборки платы. Со временем он разрушал паянные соединения выводов деталей с медными дорожками платы, а нагрев микросхем способствовал этому. Особенно страдал от этого многофункциональный чип Cirrus Logic CL-SH8671-450: испаряясь, флюс проникал сквозь поры платмассового корпуса этой микросхемы, со временем выводя из строя ее кристалл, и начинались глюки. Но основной причиной был именно обрыв выводов - между ними и дорожками платы образовывалась оксидная пленка, и электрический контакт нарушался. И именно этим объяснялись все «мистические» явления, происходившие с этими хардами: тепловые и механические воздействия приводили к временному восстановлению контакта, и винты ненадолго оживали.
Такие накопители подлежат ремонту путем отпайки микросхемы и тщательной промывке платы от остатков заводского флюса, после чего чип припаивается на место. Процент успешного восстановления довольно велик - теоретически это останавливает разрушение платы, и винт после этого может работать без поломок.
..........................
Описанные проблемы есть и у более ранних винтов Fujitsu - серии MPF, хотя это проявляется не так часто. Причина та же - нарушение технологии пайки микросхем на заводе. Неисправный винт обычно стучит головками при включении или после прогрева, а иногда вообще не запускается. Такой глюк лечится пропайкой выводов микросхемы Cirrus Logic, причем крайне желательно снять ее совсем, и тщательно удалить остатки заводских химикатов из под нее и с ее пласмассового корпуса, чтобы дефект не повторился снова.

Но вообщето, я это все к тому, что если винт из-за пререгрева не может долго работать, то "лечить" такие вещи оптимизацией софта "чтобы побыстрей писало" - полнейший бред, причем очень опасный.
Автор: maxud
Дата сообщения: 10.04.2009 08:23
Kirill666
Чтобы закончить с фуджами.

Цитата:
Если интересно - почитайте:

Человеку свойственно ошибаться - автор ошибся, принял следствие за причину.
Я не зря дал указал на форум iXBT (http://forum.ixbt.com/topic.cgi?id=11:19775-87 ), вот там и раскопали настоящую причину и выработали оптимальный способ лечения (заодно и опровергли эту статью). Если коротко, то причина: химические-механические (фосфорный цирроз логики) процессы связанные с новым материалом корпуса микросхемы, особенно проявляющиеся при повышенной температуре и влажности. Лечение: прогрев чипа с консервацией силиконовым маслом, через год-два повтор и не надо никаких радиаторов дополнительных.
В свое время я вылечил их штук 200 (двести), до сих пор приносят, кстати. Все по методике iXBT, ни разу не отпаивал чип и не мыл флюс. Много было с восстановлением прошивки и микропрограммы. Возвраты были, но с минимальным сроком полгода, часть была на повторе, многие до сих пор работают.

Цитата:
Но вообщето, я это все к тому, что если винт из-за пререгрева не может долго работать, то "лечить" такие вещи оптимизацией софта "чтобы побыстрей писало" - полнейший бред, причем очень опасный.

Ну с этим категорически согласен. Кстати попутно нашел еще одну причину сбоев в работе внешних винтов в контейнерах. У меня контейнер с тройным питанием: от второго USB, встроенного аккамулятора и внешнего блока питания. Заметил что на некоторых компах при питании от USB через некоторое время начинались глюки (особенно при интенсивной записи), а с внешним блоком питания все нормально. Причиной оказалось то что контейнеру категорически надо для нормальной работы напряжение на USB (дежурного питания) +5.0V или чуть выше. Глюки были на тех системиках у которых дежурка была ниже +4.8V. При заниженном напряжении питания контейнер переключался на аккамулятор, тот быстро садился и начинались глюки. Если аккамулятор отключить глюки при записи начинались почти сразу.
Автор: rsss
Дата сообщения: 10.04.2009 08:54
IFkO А когда планируется твоя следующая сборка?
Автор: arnyc
Дата сообщения: 10.04.2009 17:25
Kirill666:
Спасибо за советы по диску. Улучшить условия охлаждения чего-бы то ни было в старом лаптопе - дело не шутейное. Я даже не знаю точно, что там больше перегревается при записи больших файлов на внешний хард через USB карту: встроенный диск, процессор, материнский чипсет, шина, или сама PCMCIA карта. К тому же вибрация внешнего диска иногда приводит к сбою соединения из-за болтанки коннектора в его USB-порте. С этим как посоветуете бороться? Но если поставить лаптоп на стойки, то перегрев снижается из-за охлаждения дна. Короче, давно пора на пенсию.

О программах оптимизации копирования: они ведь не для лечения дисков разработаны, а для ускорения записи файлов. Побочный эффект очевиден: из-за резкого уменьшения числа перемещений головки и времени записи снижается перегрев, к тому же периодическая Пауза позволяет доп. охладить все схемы. Пока убедился лишь в их преимуществах. Неплохие алгоритмы копирования реализованы и в Total Commander (для больших файлов), 7Zip ( с разделением на части) и т.п. Однако перепробовав ряд прог, нашёл FastCopy более эффективной для Win98. В ней зашит ряд авто стратегий записи файлов для разных сценариев, и гибкий контроль за ними со стороны пользователя. А в Проводнике один вариант контроля: оборвать запись.
Автор: IFkO
Дата сообщения: 10.04.2009 19:01
rsss

Цитата:
когда планируется твоя следующая сборка?
уже скоро. Жду отзывов о выложенных пробных компонентах и кое-что доделываю.
Автор: daesher
Дата сообщения: 10.04.2009 19:16
98IF - сборка
Не работают драйвера Nvidia в более или менее "недревней" конфигурации (Athlon64 s939, 2Gb RAM, 2 HDD IDE+SATA, Nforce 3, NVidia GF6800LE 128 M) - слетают, будучи установленными, на загрузке в постоянный ребут. Откатил на "фирменные" 6176, вроде, работают. Работа не очень стабильная (глюк перезагрузки, только 16-битный доступ к диску, без него вис на установке, может, получится ещё чего включить, пару раз сваливался с синими экранами и т.п.). Тем не менее, это нечто лучшее, чем было.

Страницы: 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970

Предыдущая тема: Исчезают окна и папки


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.