Обзор IBM IC35L020AVER07

Введение

Выполняя данное мной в статье "обзор IBM 60GXP." обещание, представляю вам результаты тестирования винчестера IBM 60GXP ёмкостью 20ГБ. Несмотря на то, что отличия в производительности винчестеров из одного модельного ряда, но имеющих разную ёмкость, невелики, я считаю некорректным сравнивать между собой винчестеры разных фирм с разными объёмами.
Как я уже показал в статье "Сравнение быстродействия винчестеров разной ёмкости", в некоторых случаях этой небольшой разницы как раз хватает, чтобы винчестер большего объёма одной фирмы опередил в рейтинге винчестер меньшего объёма другой фирмы. Сейчас на рынке винчестеров сложилась такая ситуация, что винчестеры разных фирм показывают очень близкие результаты, и, чтобы по справедливости расставить их в "рейтинге", лучше тестировать их в равных условиях.
Некоторые мои читатели справедливо заметили, что высказанное мною предположение "винчестер большего объёма показывает большие результаты" не всегда подтверждается моими же результатами. Да, действительно, в вышеупомянутой статье ровно в половине случаев WD300BB показывал большие результаты в тестах WinBench, чем WD400BB. Но, если посмотреть внимательно, то мы увидим, что подобные вещи происходят либо под Win98, где Winbench99 имеет значительно худшую повторяемость результатов, либо на UDMA66/100 протоколах. Для тестов винчестера на UDMA66/100 я использую контроллеры Promise Ultra66 и Ultra100 и общие для них драйвера версии 1.60 build 33. Эти драйвера славны тем, что имеют в своём составе специальную библиотеку pticache.vxd, которая производит кэширование диска. Именно это кэширование "сглаживает" разницу между винчестерами разных объёмов как, кстати, и между протоколами UDMA66 и UDMA100.
Итак, я попал в неловкое положение в тот момент, когда наивно решил, что тот драйвер, который показывает больший результат - лучше (знать бы где упасть, соломки б подстелил...). Конечно, для пользователя кэширование полезно, но мне теперь тяжело судить о преимуществах или недостатках протоколов и размеров винчестеров...
Таким проблемам, насколько я понимаю, подвержены также пользователи контроллеров HighPoint, где кэширующий драйвер появился очень давно и официально распространяется.
Для всех же остальных пользователей (в том числе для тех, у которых есть контроллеры Promise и которые пользуются драйверами 1.60 build32, ибо, до последнего времени, это были единственно доступная версия драйвера), эффект "сглаживания" не будет проявляться. В этом можно убедиться, посмотрев на результаты винчестеров на UDMA33, где использовался старый добрый i440BX.
Когда у меня появилась возможность протестировать винчестер IBM 60GXP, были доступны только модели с ёмкостью 40ГБ, и я, скрепя серце и скрипя зубами, сравнил по скорости 40ГБ винчестер от IBM с 20ГБ винчестерами конкурентов... Сегодня же я предлагаю вам "абсолютно честное и беспристрастное", в моём понимании (без всяких "наездов" в сторону конкурирующих изданий :) ) сравнение быстродействия винчестеров на 7200rpm с 20ГБ пластинами. Назвать его "исчерпывающим" клавиатура не поворачивается, ибо у меня в тестах пока не принимали участие винчестеры Fujitsu и Samsung... Но я не теряю надежды их испытать, да и вам не советую её терять! :)
В этой статье я, по возможности, постараюсь не повторяться, ибо про IBM 60GXP я уже однажды вам рассказывал, а только приведу цифры и диаграммы. Также, вас ожидает увлекательное тестирование IBM 60GXP с отключенными функциями кеширования записи и упреждающего чтения. Читать до конца!!!

Конфигурация стенда

материнская плата - ASUSTeK CUBX-E биос 1007A
процессор - Intel Coppermine 600MHz
память - 2*128Mb SDRAM Hyundai PC-133
видеокарта - Matrox Milennium 4Mb
операционная система - Windows 98/Windows 2000 Pro

Методика тестирования

Для того, чтобы замерить производительность винчестера в разных UDMA-режимах были использованы следующие контроллеры:

UDMA33 - встроенный контроллер чипсета i440BX
UDMA66 - контроллер Promise Ultra66
UDMA100 - контроллер Promise Ultra100, интегрированный на материнской плате.

Для контроллеров Promise использовались драйвера версии 1.60 (билд 33).
Диски подключались "мастером" на отдельный канал, поддержка DMA в Windows разрешалась. Диски размечались в FAT32 и NTFS на один раздел максимального объёма c размером кластера по умолчанию.
Тесты проводились по четыре раза, результаты усреднялись. Винчестеры между тестами не охлаждались.
Использовались следующие тесты:

Win98 WinBench 99 1.2
Adaptec Threadmark 2.0
Win2000 WinBench 99 1.2
HDTach 2.61
IOMeter 1999.10.20

Среднее время доступа

Этот параметр, для надёжности, я измеряю при помощи двух тестов - Disk Inspection test из набора Winbench99 и HDTach 2.61.
Конечно, у обоих этих тестов есть погрешность измерения, но, судя по разнице между результатами 40 и 20-ти гигабайтной модели IBM 60GXP, HDTach менее подвержен таким погрешностям...

Устоявшаяся скорость линейного чтения

О! Младшая модель на 100КБ/сек быстрее в начале диска! :)

HDTach 2.61

Разница между винчестерами лежит в пределах погрешности измерения, но 40ГБ модель показала больший результат.
Здесь различия чуть больше, но всё равно IBM 60GXP оказалась быстрее, чем WD Caviar 7200.

WinBench 99 1.2 Win98

Как я уже говорил, тесты под Win98 страдают плохой повторяемостью результатов, поэтому больше подвержены "погрешностям измерения". Это наглядно видно из следующей диаграммы:
Первое место заняла 20ГБ модель IBM 60GXP, а на третьем месте - Quantum FB Plus AS.
А в Hi-End тесте скорость обеих дисков IBM сравнялась.

WinBench 99 1.2 FAT32

Ну, вот мы и добрались до стабильной W2K:


Результаты винчестеров IBM опять очень близки, и значительно выше, чем у конкурентов.
абсолютно та же картина...

WinBench 99 1.2 NTFS

Под NTFS у нас кластер для всех винчестеров одинаков - 4КБ, но разница в результатах всё равно есть:

И большая... Интересно, почему?

А здесь винчестеры опять построились "по росту"...

Intel IOMeter

В нижеследующей таблице приведены результаты IBM IC35L020AVER07, то есть 20-ти гигабайтной модели из семейства 60GXP:


и, как обычно, сравним винчестеры между собой по сумме показаний Total I/O при трёх самых тяжёлых вариантах нагрузки:

Как и в случае с винчестерами WD, старшая модель IBM хоть ненамного, но всё таки быстрее младшей.

Нагрев и шум

Способ измерения температуры я уже неоднократно описывал в предыдущих статьях, так что, во имя экономии размера статьи, я просто укажу значение температуры, до которой нагрелся IBM IC35L020AVER07 - 36 градусов.

Выводы

Выводы на этот раз будут очень короткие: IBM IC35L020AVER07 - самый быстрый винчестер 7200rpm с плотностью записи 20ГБ на пластину.

Бонус

А теперь поговорим о самом интересном в этой статье (ибо всё вышесказанное было легко предсказать и без тестов) - о том, как винчестеру IBM удаётся достичь таких высоких результатов.
Как вы знаете, у каждого винчестера есть т.н. фирмваре, то есть та микропрограмма, по которой работает главный процессор винчестера. Так вот скорость работы винчестера во многом определяется не плотностью записи на пластине, а частотой работы этого процессора и совершенством его фирмваре. Что может делать фирмваре мы можем только предполагать, ибо эта информация закрыта производителями...
Однако некоторые сведения начинают потихоньку просачиваться. Так, совсем недавно, фирма IBM выпустила новую версию (1.20) своей утилиты IBM Feature Tool, которая теперь не только может изменять UDMA режим винчестера и его "шумность", но и позволяет откючать/включать ещё две очень интересные функции фирмваре - упреждающее чтение и отложенная запись.

Совершенно непонятно, зачем давать пользователям в руки возможность столь глубоко вмешиваться в алгоритмы кэширования. Единственная мысль, которая возникает в моём воспалённом мозгу, - это возможный способ лечения "проблем с семейством винчестеров 75GXP". Об этой проблеме я выскажусь чуть ниже, а сейчас вернёмся к IBM Feature tool.
Итак, что же такое упреждающее чтение - это давно известный способ увеличить быстродействие винчестера при чтении данных. Смысл его состоит в следующем: - при запросе на чтение сектора винчестер зачитывает в кэш не только запрошенный сектор, но и несколько соседних. Если при следующем обращении к винчестеру будет запрошен сектор, уже имеющийся в кэше, он будет незамедлительно оттуда выдан. Этот же способ используется и в процессорах и... где только не используется... Отличия между алгоритмами кэширования состоят в организации кеша и алгоритме принятия решения - нужно кэшировать или нет. Ведь если винчестер бомбардировать случайными короткими запросами на чтение одного сектора, а винчестер будет при каждом запросе открывать новую линейку кеширования и засасывать туда с пластины n-секторов, то он просто потратит время зря. Ведь из каждой линейки будет затребован только первый сектор, который уже передан программе. Все остальные сектора будут благополучно забыты... Умное фирмваре должно оценить вероятность того, читаются ли сектора цепочкой или это случайное короткое обращение.
Вторым, не менее важным параметром, влияющим на "производительность" кэширования, является размер линии кэширования, т.е. то количество секторов, которое читается "про запас". Размер этой линии может быть постоянным или динамически изменяться, в зависимости от "характера чтений", т.е. среднестатистической длиной, если хотите, файла.
Что же ещё можно сказать о кэшировании... Ах, да, я совсем забыл про запись! Делаем плавный, незаметный переход темы...
Умное фирмваре также не делит кэш-память на две части со статическим размером (под чтение и под запись), а меняет размеры этих областей динамически, в зависимости от характера действий пользователя. Если пользователь больше читает с винчестера, количество линий кэша под чтение увеличивается, если преобладают операции записи, то увеличивается количество линеек кэша под запись. Иногда бывает выгоднее сбросить всё содержимое линеек кэша, отведённых под чтение, и отдать их под запись. После окончания сеанса записи фрагментированного свап-файла на винчестер можно восстановить содержимое линеек чтения в первоначальном состоянии.
А теперь перейдём к записи! :)
Отложенная запись - это когда винчестер принял от драйвера сектор и не записал его немедленно, а положил себе в кэш до лучших времён. Если приходит запрос на чтение этого сектора, то он немедленно записывается, а потом читается или выдаётся прямо из кэша (это зависит от наглости фирмваре). Если фирмваре видит, что сейчас винчестер ничем не занят, она выполняет отложенную запись... Или не успевает выполнить, когда компьютер экстренно выключают... При этом следующая загрузка Windows начнётся со Scandisk-а...
Ну, как говориться, всё, что знал - рассказал, теперь начнём врать :) - шутка!
Теперь вы знаете, что есть утилита, и что мы можем ей у винчестера отключить. Настала пора узнать, к чему это всё может привести.
Для того, чтобы понять, как производительность винчестера изменится при отключении ему упреждающего чтения и отложенной записи я провёл три дополнительных тестирования винчестера IBM IC35L020AVER07 ("C2H5OH на пару...") на UDMA100 протоколе. Вместе с ранее проведёнными тестами IBM IC35L020.... в его нормальном режиме у меня получилось 4 варианта работы винчестера:


Быстродействие винчестеров я проверял двумя тестами - WinBench99 и IOMeter.
Начнем с Winbench99. Таблицу я приводить не буду, ибо практического смысла в этом не вижу, а приведу я только значения Business и Hi-End тестов:

Очень интересная картина! Отключение упреждающего чтения уменьшает результаты и в Business Disk Winmark и в Hi-End Disk Winmark.
Само по себе отключение отложенной записи больше сказывается в Hi-End тесте, где результаты винчестера с отключенным режимом отложенной записи хуже, чем результаты того же винчестера с отключенным упреждающим чтением. Интересно - почему? Насколько я понимаю, в этом тесте на винчестер распаковывается некий набор файлов, характерных для приложений, а потом запускается секундомер и эти файлы "читаются". Т.е. измеряется время чтения файлов. Но при чём здесь запись? Неужели размеры этих файлов настолько малы, что той информации, которую умное фирмваре винчестера IBM не записывает а "откладывает" её запись, достаточно для такого существенного теста производительности?
При отключении и упреждающего чтения и отложенной записи винчестер показывает результат, практически в три раза меньший, чем его "нормальный" вариант.
Таким образом, роль кэша в этих тестах оказывается очень значимой, если не сказать - определяющей.
Посмотрим, как изменится производительность винчестера при выключении упреждающего чтения и отложенной записи в IOMeter.
Кратенько приведу полученные результаты в виде таблицы (только Total I/O):


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

Красиво, не правда ли? Первое, что бросается в глаза, так это то, что при отключении только упреждающего чтения и упреждающего чтения и отложенной записи одновременно винчестер показывает более высокие результаты, нежели когда эти опции активированы. Фантастика! Хотя, если мы посмотрим на это с другой стороны, то всё можно объяснить.
В этом паттерне вероятность того, что запрошенный блок будет следовать за только что отработанным практически равна нулю, ибо вычисление адреса следующего блока на 100% случайно. И алгоритмы упреждающего кэширования работают в холостую! Мало того, они ещё и ухудшают скорость работы винчестера, ибо ему приходиться:

а) думать, сколько следующих секторов считать и куда их положить
б) читать эти сектора (на начальных треках примерно 800-1000 секторов, время оборота = 4,17мс, пропорцию можно рассчитать...)

Т.е. у нас в этом случае есть непроизводительные затраты времени при работе алгоритма упреждающего чтения. При его отключении винчестер показывает самые высокие результаты.
При втором взгляде, мы можем заметить, что самые плохие (почти ужасные :) ) результаты винчестер показывает при отключенной функции отложенной записи. Это тоже легко объяснимо - потери на упреждающее чтение есть, а все запросы на запись исполняются НЕМЕДЛЕННО, по мере их поступления. Согласно спецификации этого паттерна, операции записи выполняются в 20% случаев и, так как винчестер лишён возможности изменять порядок выполнения операций, его результаты резко падают.
В этом паттерне "случайность" вычисления адреса следующего блока данных составляет 80%, то есть в двадцати случаях из ста для следующей операции берётся блок, следующий за только что обработанным. И это кардинально меняет расстановку сил. Самый высокий результат показывает винчестер, вооружённый "до зубов", а худший - с отключённой отложенной записью!
Таким образом, при неслучайном характере обращений отключение исследуемых фунций фирмваре приводит к ухудшению производительности.
Этот паттерн любопытен тем, что в нём опять адрес блока вычисляется случайно в 100% случаев, но здесь растёт и доля операций записи. Это привело к тому, что вид графиков и их расстановка между собой повторяют ситуацию в паттерне Fileserver, но результаты винчестера с отключенной отложенной записью стали ещё хуже.
"Как я рад, что моя жизнь подтверждает чью-то теорию..."

Выводы-2

Для обычных пользователей, отключение у винчестеров IBM упреждающего чтения и отложенной записи приводит к существенной потере скорости при работе с Windows-приложениями.
Для тех, кто использует винчестеры IBM в "серверных" задачах, отключение упреждающего чтения может привести к некоторому увеличению производительности в ряде задач. Но, на мой взгляд, овчинка не стоит выделки, ибо выигрыш не так уж велик...
Выводы для всех - не трогайте тонких настроек, если у вас нет проблем.

Тайна чёрных дятлов

Кстати, о проблемах - в последнее время я наблюдаю некоторую истерию по поводу проблемы надёжности серии жёстких дисков IBM 75GXP (DTLA3070xx). На мой взгляд, проблема несоизмерима с маштабами той антирекламной компании, которую поднимают некоторые средства массовой информации. Со стороны это похоже на панику в сумашедшем доме, когда все пациенты легковозбудимы и как только один горлопан поднял крик, его тут же поддерживают двое-трое соседей и далее начинается лавинный эффект...
Есть в России три национальных игры:
Первая игра - это всем известная русская рулетка. Для иностранных читателей поясню, чем русская рулетка отличается от всех остальных. В них в пустой барабан револьвера вставляется один патрон, барабан прокручивается и... А в русской рулетке из полного барабана вынимают один патрон...
Вторая игра, которую мы постигли в совершенстве - игра в пирамиду (финансовую, а не Хеопса...).
И, наконец, третья национальная игра - паника... В неё мы играем с начала века, ибо каждая революция сопровождалась погромами и переделами собственности. Столь частое обесценивание накоплений населения, несомненно наложило свой отпечаток на генотипе нации...
Ответьте себе на вопрос - почему слухи вы распространяете быстрее, чем информацию, подкреплённую фактами? Конечно, слухи распространять приятно и легко. Знать при этом много не нужно - чем меньше знаешь, тем больше расскажешь. И вот, слухи распространяются, причём каждый новый пересказ добавляет в этот слух экспрессию и правдивость... Через некоторое время слух обретает то совершенство, которого никогда не смогут добится спичрайтеры президентов...
Да, линейка 75GXP значительно опередила своё время. Да, IBM применила в ней некоторые технологии, которые существенно повысили скорость винчестера. Но, как и все "рекордные" изделия, винчестеры получились достаточно "нежные". Их нельзя бросать, перегревать их и бить их нежные головки об пластину или упоры... Я не по наслышке знаю, как у нас пользователи общаются со своими винчестерами, я проработал менеджером долгие 7 лет и видел всякое...
Дело, на мой взгляд в том, что практически все пользователи утратили "трепетное" и уважительное отношение к компьютерным комплектующим. Для нас они стали чем-то обыденным, бытовым... Поэтому мы не моем руки, перед тем как взять в них комп. железку и не снимаем себя заряд статического электричества... А хоть пять процентов из нас читает инструкцию ПЕРЕД тем, как установить железку?
Нет, мы читаем только гарантийный талон, после того как железка уже сгорела!
Но кто же виноват в наших бедах? Конечно, буржуи-производители и нехорошие продавцы!... Это называется покупательский экстремизм.
Господа, согласно статистике компании Ф-Центр, на текущий момент проблемы возникли только у 5 процентов винчестеров IBM 75GXP. Т.е. нами принято по гарантии один винчестер на каждые двадцать проданных... Остальные девятнадцать ещё где-то катаются... как в том анекдоте про мотоциклистов... (шутка!)
Причем, принят на гарантию, это не значит неисправен!

Рецепты продления жизни винчестеров были описаны неоднократно, но я всё же повторюсь:

1. Нужен хороший, просторный корпус с хорошим блоком питания, крепкой станиной и жёстко закреплённой корзиной под винчестеры.
2. Категорически не рекомендуется использовать звукопоглощающие прокладки, ибо они плохо проводят и тепло.
3. Крайне необходимо обеспечить внутри корпуса комфортную для винчестера температуру
4. Если наблюдаются "нехарактерные" для нормальной работы винчестера звуки, нужно немедленно разбираться в причинах их возникновения.
5. UPS - не роскошь, а средство предотвращения инфарктов и инсультов у пользователя компьютера. Дешёвый UPS - не UPS...
6. Крайне осторожно нужно подходить к выбору MobileRack-a (о правильных мобайл-реках я расскажу в одной из ближайших статей)
7. Не используйте длинные IDE шлейфы.

список можно продолжать и дальше, но... теперь я расскажу вам, как я своими собственными руками задушил "двух дятлов".
Первая смерть винчестера IBM 307015, невольным виновником которой я стал, произошла в мобайл-реке неизвестного науке китайского производителя. Корпус мобайл-река был пластмассовый и вентилятор у него не вращался. Таким образом я лишился системного винчестера и всех данных на нём, что привело к задержке с одной из статей...
Второй винчестер также помер при отягчающих обстоятельствах с моей стороны. Это было тогда, когда я тестировал IDE RAID-контроллеры 3Ware, Adaptec и Promise. Вот Promise и отличился...
Всё было хорошо, пока я тестировал контроллеры, поддерживающие максимум 4 винчестера. Я выписал со склада 4 винчестера DTLA 307015 и никаких проблем не возникало. А контроллер Promise поддерживает 6 винчестеров и я выписал ещё два. Подключил их и начал тесты... Системный блок стоял на столе, справа от монитора, за которым я сейчас пишу эти строки. Точно так же, как и сейчас, я был расслаблен... "И голова моя становилась легкой от утомления, и Пилат летел к концу."
Как вдруг, ровное стрекотание кузнечиков в моём правом ухе сменилось рёвом боевых верблюдов! Контроллер верещал дурным голосом (именно для этих целей там установлен пищик ужасно неприятной тональности), винчестеры (шесть штук) синхронно выводили "БзныыннььККжжжЖ, бзныыннььККжжжЖ, бзныыннььККжжжЖ..." и это не прекращалось ни на секунду. Выключение компьютера спасло мою жизнь, ибо ко мне со всех сторон подбирались сотрудники отдела с заранее злыми выражениями лиц...
Но после включения компьютера какофония началась по-новой... После этого праздника музыки один винчестер также отбросил лапки... Он не определялся и пел свою прощальную песню...

пример "бульварной" журналистики:

Вы слыхали, как поют дятлы?
Нет, не те дятлы, не полевые,
А дятлы, волшебники-дятлы,
Певчие избранники России.

Вот они расселись по лесам,
Зазвучали до самозабвенья,
Узнаю я их по голосам,
Звонких повелителей мгновенья.
Узнаю я их по голосам,
Звонких повелителей мгновенья.

Звуки вырастают, как цветы, -
Грустные, веселые, любые,
То горячие до красноты,
То холодновато-голубые.

Достают до утренней звезды,
Радугами падают на травы.
Шапки прочь! В лесу поют дятлы,
Для души поют, а не для славы.
Шапки прочь! В лесу поют дятлы,
Для души поют, а не для славы.

В. Шаинский - С. Островой, испортил niknik

Однако, я был уже морально готов к вкрытию тушки (инструменты , спирт, огурчик...) и я подключил его к другому стенду, вставил дискетку с IBM Drive Fitness Test и сказал, "поехали"!
"Сказав это, Он воззвал громким голосом: Лазарь! иди вон."
Через пятнадцать минут я держал в руках абсолютно живой винчестер (он работает у меня и сейчас...).
Что же произошло с контроллером и подключёнными к нему винчестерами? А вот что - полученные мною со склада во второй раз винчестеры имели другую страну изготовления и (внимание!) - другой объём. Оказалось, что венгерские DTLA имеют чуть меньший объём, чем таиландские и филлипинские. Получилось так, что винчестер большего объёма был в массиве первым и на нем были сектора с таким адресом, которых не могло быть на винчестере меньшего объёма именно по причине его меньшего объёма. Биос контроллера не контроллировал размеры винчестеров и не ограничил их по меньшему. Во время теста IOMeter генератор случайного числа выдал адрес сектора, которого не было на нескольких винчестерах массива и контроллер начал ребилдить массив. Причём ему эта процедура так понравилась, что он ушёл очень глубоко в себя и реагировал только на выключение питания.
После такой "встряски" один из винчестеров и дал дуба... но не насмерть.
Вот вам страшная история, о том, как программно можно "убить" винчестер, и о том, как, при помощи программы, вернуть его к жизни.
Так что не всегда и во всём виноваты инженеры IBM. Значительно чаще в случаях смерти винчестеров повинны грузчики, которым всё равно, что разгружать - шлейфы или винчестеры, и пользователи, которые не знают, каким концом - чёрным или синим втыкать UDMA66 шлейф в материнскую плату, а каким - в винчестер. И не нужно, услышав доносящиеся из винчестера подозрительные звуки, бегать по форумам и спрашивать "как бы мне убить винчестер, чтобы мне его наверняка поменяли по гарантии"... Сделайте резервную копию жизненно важных для вас файлов и попробуйте поискать причину возникновения тревожащих вас звуков.

В заключение, искренне прошу прощения у инженеров и сотрудников самой моей любимой фирмы - IBM, за несколько вольный стиль изложения этой статьи. Я пользовался винчестерами IBM всю свою сознательную жизнь (в моём домашнем компьютере последовательно сменили друг друга DTTA, DNES, DPTA, DTLA) и по сей день остаюсь поклонником её продукции.

Какой винчестер вы выберете себе - ваше дело, это ваш выбор и ВЫ несете за него ответственность. "Собственность - не только право, но и...