Здравствуйте. Я столкнулся с нестабильность измерения скоростных характеристик жестких дисков. Предполагаю, что ошибка, проявляющаяся с вероятностью 5-10% связана: 1. С обращением к жесткому диску другого процесса 2. С планировщиком вытесняющей многозадачности 3. С механизмом работы виртуальной памяти Как временно ограничить доступ всех процессов на системный раздел жесткого диска? Под ограничением доступа имеется в виду запрет записи и чтения секторов HDD. Речь идет именно о системном разделе, т.к. в противном случае это можно сделать так: 1. DeviceIoControl(hDevice, FSCTL_LOCK_VOLUME... 2. Work... 3. DeviceIoControl(hDevice, FSCTL_UNLOCK_VOLUME...
Мне эта тема тоже интересна и актуальна, но я не стал запускать твою прогу - мало ли что она делает? Да и вообще, гораздо лучше было бы, если бы ты рассказал, _что_ именно мерял, и _как_ именно мерял, тогда и появится пища для обсуждения. Пока совет один: если нужны _объективные_ данные о быстродействии винта, читай сектора под ДОСом, и не через INT 13h, а напрямую через контроллер.
см. http://smarthdd.ru Это понятно, но к сожалению суровая действительность бытия говорит - DOS уходит в небытие, а необходимость измерения характеристик остается
DOS уходит в небытие, а необходимость измерения характеристик остается Ну, не буду разубеждать. Хотя, имхо, если в магазинах продаются в основном двухметровые гибкие щипцы, это еще не повод всем подряд удалять зубы исключительно через анальное отверстие, и считать это единственно возможным и единственно правильным способом. В конце концов, пиши программу из 15 строчек, грузи ДОС с дискеты и меряй _точно_ и _достоверно_, вместо того, чтобы тратить уйму времени и нервов на отключение от Маздая всего того лишнего и мешающего, что делает его отличным от того же самого ДОСа. Да еще и не будет уверенности, что оключил полностью, и что результаты измерений действительно достоверны. ReadFile(hDevice, Buffer^, SizeOf(TSector), BytesRead, nil); Кстати, почему размер буфера 1024*256? Это 512 секторов по 512 байт? А сколько дорожек/цилиндров при этом "засосет"? А зачем создавать отдельный поток для измерений, "главного" недостаточно? Ну ладно, теперь по сабжу. С перечнем возможных причин в общем согласен, хотя добавил бы еще пару: 4) обработка аппаратных прерываний от внешних устройств (включая таймер!); 5) личная инициатива винта (например, включение автокалибровки). Имхо, победтиь все 5 причин не выйдет. Но побороться можно. Не спеши рассчитывать среднее, сохрани времена в массивчике, построй гистограмку и посмотри на нее глазками. Скорее всего, она будет многомодальна (т.е. с несколькими пиками, чаще всего с двумя). В этом случае можно поступить примерно так: 1. Если результаты "естественные", то ничего не делать. 2. Иначе (пусть массивчика зовут Times) примерно так: mid := (max(Times)-min(Times))/2; n:=0; sum:=0; for i:=0 to 99 do begin if Times<mid then begin n:=n+1; sum:=sum+Times; end; end; average:=sum/n; т.е. включать в рассмотрение только "естественные" отсчеты выборки, а "пределом естественности" считать середину диапазона результатов. Это не очень корректно, но можно поюзать и более сложные модели. З.Ы. Всем ортодоксам большое аймсорри за "ламерский" Паскаль. В конце концов, каков вопрос - таков должен и ответ.
вообщето дело вот в чём как мне сдается. Ты измеряешь скорость винта из пользовательского режима, причём абсолютно не заботишься о том, что юзермод это свитчинг контекстов, потом, доступ к винту асинхронен и третье не забывай про кэш и файловой системы и винта. Поэтому измерение скоростной харрактеристики данного устройства есть среднестатистическое значение нескольуих измерений плюс погрешность от вышеперечисленного. Могу предложить вариант такой: писать дравину прямого взаимодействия с винтом, при этом перехватить порт драйвер винтового контроллера и не давать в течение определенного времени спускать сверху по стеку ирпы к драйверу контроллера. В это время поработать с винтом и получить интересующие нас данные).
Это позиционирование приблизительно на среднюю дорожку перед началом анализа линейной скорости чтения. В стандартном "де-факто" режиме LBA понятия цилиндр, головка, сектор - CHS не существуют. Увеличение размера считываемого блока больше 256кб, как показали исследования , не улучшает стабильность измерений. Да, так как считывание блока данных в "Ultra DMA" режиме практически не загружает CPU то планировщик раздает кванты времени "голодающим", несмотря на Код (Text): SetPriorityClass(GetCurrentProcess, REALTIME_PRIORITY_CLASS); SetThreadPriority(GetCurrentThread, THREAD_PRIORITY_TIME_CRITICAL);
HCode В стандартном "де-факто" режиме LBA понятия цилиндр, головка, сектор - CHS не существуют Здрасьте-пожалуйста. Это каким же образом логическая трансляция номеров секторов отменяет физические головки, цилиндры и сектора? Если головке положено ждать физический индекс или перемещаться на физически другую дорожку, то это и займет положенное время, несмотря ни на что. Да я думал об этом, но уж больно сложна реализация. И я того же мнения. Можно жизнь убить на борьбу с Майкрософтовскими наворотами , а можно просто правильно обработать результаты измерений.
LBA использует специальную таблицу "транслятор". Номер сектора это индекс в "трансляторе", т.е. вычислить CHS на основе LBA невозможно.
DOS уходит в небытие, а необходимость измерения характеристик остается А если попробывать порубать все процессы при начальной загрузке, вместо explorer-a запустить свою прогу, а swap-файл отрубить в настройках? Зачем бороться с ними в realtime, когда им можно не дать грузануться.
LBA использует специальную таблицу "транслятор". В то-то и дело, и я именно об этом! Никто же не знает, сколько раз головка сдвигается. Является ли читаемый фрагмент винта "характерным" для данного винта? 512*512 непрерывным куском - не маловато ли?
