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

Для проверки скоростных параметров вашего HDD и предназначен HAB.

На что нужно смотреть в результатах:
1.IO Deley - время доступа "до винта", показывающие скорость реакции диска (время за которое контроллер выдаёт запрос и обрабатывает его) и системы (задержка в канале передачи данных плюс задержка в драйвере плюс задержка из-за скорости самого процессора) и быстродействие интерфейса. Соответственно чем меньше, тем лучше.
2. Access - среднее время доступа, показывает как долго будет лететь головка по поверхности пластины, пока не найдёт нужные данные. Чем меньше, тем лучше.
3. Тест на Burst/Linear read - здесь мы можем посмотреть как быстро диски обмениваются данными со своим кэш-буфером/скорость чтения последовательно расположенных данных, причём блоки имеют различный размер и нам легко оценить, как быстро диск работает, например, с маленькими 4К блоками или же наоборот с большими 2Мб. Тут уже чем больше, тем лучше.

А вот так всё это выглядит:
#77

Ну и линк на скачивание: http://testmem.tz.ru/hab.zip
Зеркало HAB
_________________________________________________________________
Для корректного снятия результатов теста опции быстрого тестирования НЕ Включать!
Окно статистики и/или её текстовую версию размещать НЕ Нужно!
Оптимальный размер страйп-блока для РАЙД 0 определяем по формуле
Скорость буферного чтения блока + 10-20Мб/с >= максимальной линейной скорости диска. Стремимся к минимальному страйп-блоку, если Ваши приложения не оптимизированы читать большими блоками (для проверки этого и служит сбор статистики).
Отредактировано модератором: LAV48. Дата: 25.09.2008 21:47

страйп 8 кБ
#77
Предлагает поставить 128. Стоит ли заморачиваться с перестановкой системы? Или так оставить?

Знатоки, оцените пожалуйста работу RAID 0 с Stripe 16кб.
#77
Менять ничего не нужно?

Если WD, то попробуй 32К.

serj По совету LAV48 viewtopic.php?p=5658462#p5658462 ставил 16 кб. там по ссылке тест одиночного харда, считаешь что всё таки стоит поставить 64 кб? Харды именно WD.

Посмотрел картинки - а, ладно, тогда оставь.
Было 61, стало 120 - потерь нет.

serj Спасибо! А может тогда и по выбору хардов новых посоветуешь? viewtopic.php?p=7698813#p7698813 Хочу через недельку другую обновить это безобразие, старые они, боюсь рассыпятся...

Подскажите какой страйп поставить под мелкие файлы - средние файлы 2kb-200mb. Хардварный рэйд на ASUS P7P55D PRO & 2 x WD6402AAEX.
Ps примерно.. После установки системы буду гонять HAB. Но если совет будет верный второй раз систему ставить не нужно будет.
Думаю 32kb будет нормально?

Система новая ещё собираю.

По описанию принципа действия программы так и не смог уяснить, на основании чего она делает такие выводы. Вот два примера на двух различных винчестерах-

#77

#77

Почему программа дает именно такие рекомендации в каждом случае?

serj, я вот заметил, что у некоторых (выше пример) на мелких блоках burst меньше linear. Почему?
PoLym0rph, собсно, программа подсказывает минимальный размер блока, при котором burst больше linear:

ckotick

Я поэтому скриншоты и привел, т.к. результаты расходятся с теорией. На первом скриншоте НАВ рекомендует страйп 16Кб, при нем burst=52 linear=105

Как-бы, 'Burst' - абсолютно надуманный параметр, которого НЕ БЫВАЕТ (не бывает в принципе) в обычной работе. Для нормальной работы Burst система кеширования в диске должна специально держать память. А ее там не шибко много.
Когда блоков много, то надо хранить указатели запросов на списки секторов, это тоже съедает память. Кроме того, индексов никогда не бывает слишком много, есть же предельный IOPS, отсюда и макс. число указателей. В режиме Burst кол-во IOPS гораздо больше максимального рабочего.
Второй момент - в современных дисках стали ставить двухядерные процессоры. С одной стороны это здорово улучшает жизнь устройству, а с другой - взаимодействие ядер (т.е. задач, выполняемых ядрами) ограничено по пропускной способности и времени реакции. Если на одноядерном процессоре всё выполняется как-бы монотонно (что бы ни делал процессор, все 'его' и легко доступно), то в многоядерном процессоре всё становится веселее. Например, пример высосан из пальца, если одно ядро обслуживает привод и данные с/на него, а второе ядро обслуживает очереди и протокол SATA. Причем, наверняка сразу образуются два потока данных между ядрами - запись и считанное. Причем, передача (наверняка) будет через DMA. Что будет в 'ентом' случае в режиме Burst? А тут всё зависит от того, где лежит кеш данных. Если у ядра контроллера (что наиболее логично), то в Burst начинается передача данных между ядрами. И вот сколько полосы от всей пропускной способности их взаимного интерфейса предоставляется на данную перепосылку - это уже вопрос реализации. По идее, если считанный блок уже был хоть раз отправлен в наружу (sata), то этот блок уже не нужен и его место можно занимать (напоминаю, памяти в HDD не много). В режиме Burst блок запрашивается повторно ... а система уже хотела его удалять. Попробую предложить, что существует некоторое максимальное время нахождения блока в кеши, по истечении которого блок выкидывается (затирается поступающими данными?)
Короче - фиг ее знает. Одно 'но' - burst стал меньше linear именно с появлением двухядерных контроллеров. Посмотри характеристики WD 1T Black ...FALS - вот с него и начались чудеса. Раньше всё было 'пушисто'.

Это описание не соответствует, а прога как раз хороша. И даже советы дала вполне вменяемые (во 2-м случае я бы подумал ещё о 16К).
Давно заметил этот диссонанс, молча удивлялся, т.к.не улавливал модели, по которой могли бы делаться предсказания.
1. Собственно, прога хороша уже как тест, компактный, интуитивно понятный, вменяемый, внутренне непротиворечивый - в качестве антипримера гляньте вкладку Extra tests в HD Tune Pro - местами произведение числа iops на размер блока отличается в разы от скорости, приведенной рядом.
Статистика - отдельная возможность наблюдения - спасибо за неё.
serj, за флэшкой статистику подсмотреть уже никак? Вот и вкладка Disc Monitor в HD Tune Pro молчит...
2. Моделька выбора в общих чертах, голая идея без важных возможно, но утяжеляющих текст, элементов.
а. При линейном чтении блоком b

где V - чистая линейная ск.чтения с блинов (определяется rpm и spt), Vb - ск.чтения блоком b с присущей реальности задержкой D для каждого блока (надеемся, задержка более-менее стабильная). Tb - время чтения блока b, именно времена выполнения операций у нас суммируется "по жизни", поэтому и усреднять обычно стоит времена (чуть ниже будет такое усреднение). По большому счёту и в проге стоит отображать Tb вместо Vb, хотя бы в столбиках для начала. Тогда б и D можно было показать и прикидки легче было делать.
Там, где представление (1) достаточно адекватно, имели б результатами HAB:

В хорошем случае примерно так и получается. Но раз уж мы имеем реальные результаты, формулу (1) будем использовать просто для понимания "на пальцах")
б. Выбрав размер s для Stripe, мы определяем у будущего RAID0 из n дисков скорость n*Vs для блоков от n*s и больше. Понятно, что из результатов HAB измерений Vb одиночного диска нам не выгодно выбирать для страйпа размер s, для которого скорость Vs (измеренная HAB'ом скорость Vb для блока b=s) чересчур далека от полки/максимума для измерений.
Аналогично издержки RAID, привязанные к страйпу, будут заметнее для меньших значений s (по идее, на эти издержки можно списать подсадку скорости у рэйда по отношению к одиночке на совсем малых блоках (для больших блоков и др.причин хватает); эти незаметные в хорошем случае издержки упомянуты чисто из вредности, чтоб было понятно, что не всё можно измерить до сборки).
в. Теперь интересно прикинуть скорости у будущего RAID0 из n дисков для блоков менее n*s. Если бы блокам из этого диапазона не случалось быть "разорванными" между дисками, скорости для блоков b от s и менее у RAID0 и одиночного диска совпадали бы. Так и получится для достаточно малых блоков. Но скорость рэйда для блоков, чуть меньших, чем n*s, будет в среднем больше, чем у одиночного диска. Для понимания: полблока с каждого из 2-х дисков RAID0 параллельно прочтётся заметно быстрее, чем целый из одного. В среднем для блока b=s у будущего RAID0 предположительно получится скорость

будто чистая линейная скорость на треть выше, чем в (1). Более общо, для блока b, равного s и меньше, у будущего RAID0 ожидаем скорость

Надеюсь, нигде не ошибся) (3) и (4) справедливы для любого n, другой вопрос, что для n>2 они описывают ситуацию для блоков b, уже не столь близких к n*s.
Таким образом, выбирая чуть меньший размер s с чуть меньшей скоростью, чем полочная, мы улучшаем ситуацию для малых блоков будущего рэйда... ухудшая для больших.
г. Существование оптимума следует из классически разнонаправленных тенденций, описанных в пунктах б,в, осталось его найти. Тут бы и статистика пригодилась и т.д., и т.п. Вы ж не думаете, что с рэйда часто будет читаться блоком, обеспечивающим макс.скорость? В общем, кому надо, тот озаботится)
Ну а грубо, в качестве Stripe можно просто выбрать минимальный блок, для которого скорость с коэффициентом n (n-число дисков в будущем RAID0) всё ещё устраивает в качестве макс.скорости рэйда.
3. Упс, я ничего не сказал про Burst и буфер диска. А что, собственно, мешает аналогично оптимизировать Burst, если вдруг это для вас важно и измерения адекватны?
4. Откуда взялось противоречащее описание и как на самом деле прогой вырабатываются рекомендации, следует терзать соответствующего автора.

можно хоть один пример? а то остальное читать очень страшно.

результаты системы в профиле

#77
#77
#77

Random seek / size 64 KB
Random seek / size 8 MB
на вкладке Extra tests в HD Tune Pro.
Конечно всё там правильно, надо просто в мануал заглядывать. Оказывается, там кроме адреса случаен и размер блока. Слово size, по мнению авторов, куда важнее намёка на случайность этого size в виде буковок max (как в мануале) или up to... Слэш до меня не дошёл, в сочетании с фиксированным размером мне показался лишним элементом.
Хороший способ напомнить про RTFM, но мне всё равно жаль потраченного времени на поиск слова random возле block. Это не единственное место, где, по моему мнению, в HD Tune сэкономлено на нескольких буквах. Пара безымянная абсцисс... ага, придираюсь, но ведь не просто так глаз споткнулся.

Ну и не читайте, киньте свою идею, как обходиться с результатами HAB. Спасибо.

Народ подскажите может я ошибаюсь, но после долгих выходных и манипуляции с райд 0 и stripe я пришел к мнению, что размер stripe можно получить по формуле, количество блоков на диске умноженное на размер кластера и умножено на два. В моем случае количество блоков 8*4*2=64, в этом случае получается наибольшая производительность. Я пробовал делать блоки на диске по 16. Тогда в этом случае получается 16*4*2=128. Ну и конечно если ставить количество блоков 4 то 4*4*2=32