Контроллер Promise TX4000

Введение

Ажиотаж вокруг интерфейса SerialATA этим летом достиг своего апогея - множество выпущенных дисков и контроллеров с поддержкой SATA надолго завладели нашими умами (и тестовыми стендами). Однако, мы нашли в себе силы вырваться из этого порочного круга (не надолго :) ) и вернулись к обзорам более "народных" ATA RAID-контроллеров. Почему более "народных"? Да потому что ATA-диски пока существенно дешевле и не сильно уступают в скорости своим SATA-аналогам.

Очередной набег на RAID-контроллеры мы начнём с контроллера Promise FastTRAK TX4000. Контроллер этот по своим характеристикам занимает промежуточную позицию между двухканальным FastTRAK TX2000 и мощным четырёхканальным SX4000. Несмотря на то, что к контроллеру TX2000 тоже можно подключить 4 жёстких диска, согласно нашему опыту, четырёхканальные контроллеры при работе с массивами из трёх или четырёх дисков намного быстрее, чем двухканальные. Контроллер же SX4000, несмотря на то, что он тоже имеет четыре канала, находится по отношению к TX4000 в другой весовой категории, так как имеет на борту XOR-процессор, что позволяет ему делать аппаратный RAID5.

Контроллер TX4000 призван заменить крайне быстрый, но, к сожалению, конфликтный контроллер FastTRAK100 TX4. Применённая на этом контроллере мостовая схема (два ATA-чипа PDC20270, подключённые через мост PCI-PCI от Intel) позволяла избежать проблемы "два винчестера-один шлейф", так как каждый винчестер подключался к отдельному ATA-каналу, но пользователи довольно часто сталкивались с проблемой несовместимости контроллера с их материнской платой. Насколько я понимаю, корнем проблем являлся использованный мост PCI-PCI от Intel. Справедливости ради отметим, что разрабатывали этот контроллер инженеры DEC, а компании Intel он достался после поглощения последней компании DEC. Но, это уже дела давно минувших дней...

Итак, компания Promise выпустила четырёхканальный одночиповый ATA133 RAID-контроллер PDC20619 и, соответственно, контроллер TX4000 на его основе. Набор поддерживаемых типов RAID-массивов вполне стандартен - RAID0, RAID1, RAID0+1, JBOD. За счет способности контроллера работать в 66МГц слоте PCI 2.3 максимально возможная теоретическая пропускная способность контроллера составляет 266МБ/c.


В правом нижнем углу контроллера мы видим микросхему BIOS-а и разъёмы для подключения LED-индикаторов.

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

Размер stripe-блока при создании массивов устанавливался в 64КБ. Для тестов в WinBench массивы размечались в FAT32 и NTFS одним разделом с размером кластера по умолчанию. Тесты Winbench проводились по пять раз, результаты усреднялись.
Винчестеры между тестами не охлаждались. При создании RAID-массивов увеличение количества винчестеров производилось последовательным заполнением IDE-каналов.

Использовались следующие версии тестовых программ:

WinBench 99 2.0
IOMeter 1999.10.20

Тестовая система

материнская плата - Tyan Tiger MPX (S2466);
процессор - 2x AMD Athlon MP 1200;
память - 2*256MB DDR SDRAM Micron Registered ECC;
системный винчестер - IBM DTLA 307015;
видеокарта - Matrox Millennium 4MB;
операционная система - Windows 2000 Pro SP4.

RAID-массивы создавались из четырёх дисков Maxtor 6L020L0 (FW: A93.0500). На дисках был предварительно отключен AAM и проверка записи.
Контроллер тестировался с BIOS 1.00.0.26 и на драйверах 1.00.0.21. Для контроля состояния массивов и управления режимом работы кэширующего драйвера использовалась утилита Promise Array Management версии 3.2.0.12. С утилитой этой, кстати, у меня случился один забавный инцидент... При установке утилита правильно определила марку контроллера, но дальше, когда я начал с её помощью создавать RAID-массивы, в числе доступных типов массива мне был предложен RAID5! Я было обрадовался - неужели Promise реализовала программный RAID5 (по примеру HighPoint, которую я ещё буду "хвалить" за это...)? Однако при нажатии кнопки "создать массив" компьютер, тихо всхлипнув, ушёл на перезагрузку. - "А-а-а" - сказали сибирские мужики... :)

Весь цикл тестов был повторён дважды - при помощи утилиты PAM мы меняли режим работы кэширующего драйвера (WriteBack/WriteThrough).

Результаты тестов

Начнём обсуждение результатов теста с самого зубодробительного паттерна:

IOMeter: Database

На всякий случай напомню, что в этом паттерне мы проверяем способность контроллеров работать со смешанным потоком запросов на чтение и запись блоков данных объёмом 8КБ со случайным адресом. Изменяя соотношение запросов на чтение и запись, мы можем выявить качество сортировки драйвером контроллера запросов на чтение и запись.
Как обычно, сначала смотрим большую таблицу результатов контроллера в режиме WT:


а потом несколько графиков, её "раскрывающих":

Обратите внимание, что при линейной нагрузке (один исходящий запрос) скорость одиночного диска оказалась выше, чем у массива RAID1. А массив RAID01 опережает массив RAID0 из трёх и двух дисков только при большой доле операций чтения.

При увеличении нагрузки на контроллер картина резко меняется. Зеркало (массив RAID1) значительно быстрее одиночного диска в режимах с преобладанием запросов на чтение, а массив RAID01, в свою очередь, почти во всех режимах обгоняет RAID0-массив из двух винчестеров. В режиме же RandomRead (где отсутствуют запросы на запись) массив RAID01 оказался быстрее, чем RAID0 из четырёх винчестеров!
Словом, все "полезные свойства" контроллера FastTRAK100 TX4 полностью перешли к контроллеру FastTRAK TX4000.


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

А теперь посмотрим еще одну большую таблицу - результаты контроллера в режиме WriteBack:


и еще три ма-аленьких графика:


Обратите внимание - даже при линейной нагрузке массив RAID1 чуть быстрее, чем одиночный диск. То есть драйвер контроллера даже в этом режиме чередует запросы на чтение между двумя винчестерами зеркальной пары.


При нагрузке в 16 запросов мы видим, что массив RAID1 всегда быстрее, чем одиночный диск. Даже в режиме RandomWrite! Массив RAID01 тоже выглядит неплохо, но он чуть-чуть уступил RAID0 из двух дисков в режиме RandomWrite.

При нагрузке в 256 запросов картина качественно не меняется - всё что контроллер мог оптимизировать - он уже сделал.

По первому впечатлению скорость различных типов массива при WB и WT-кэшировании немного отличалась. Но, интересно, насколько? Давайте сравним скорость всех вариантов RAID-массивов на различных схемах кэширования!

Ха, легко сказать, но трудно сделать... Можно, конечно, построить 18 диаграмм с двумя графиками на каждой (6 вариантов RAID-массивов при трёх нагрузках), но, как Вы понимаете, это многовато даже для меня. :)

После долгих размышлений я нашёл весьма элегантное (сам не похвалишь - никто не похвалит) решение - я построил третью большую таблицу, в каждой ячейке которой содержится результат деления скорости контроллера в режиме WB на скорость контроллера в режиме WT. Таким образом, по величине содержащегося в ячейке числа мы сможем судить об эффективности работы WB-кэширования в каждом конкретном режиме. Если число будет меньше единицы (такие числа я подкрасил красным цветом), то WB-кэширование здесь вредно, а если число будет больше единицы (такие числа я подкрасил синим цветом), то WB-кэширование привело к увеличению скорости, т.е. оно полезно.
Если же в ячейке мы видим число "1.0", то это означает, что для этого режима что WB, что WT-кэширование одинаково полезны.


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

Очевидно, что для одиночного винчестера включение WB-кэширования в драйвере не привело к увеличению скорости. Наоборот, в режиме RandomRead скорость даже немного упала.

Зато для массива RAID0 из двух дисков WB-кэширование можно признать полезным. Максимальная прибавка в скорости массива составила 10 процентов! Но, в то же время, мы не можем не заметить красный клинышек, нависший на правом фланге... Максимальный "ущерб" скорости от включения WB-кэширования составил целых 17 процентов! :( Конечно, зафиксировано такое падение скорости в режиме, который вряд ли достижим (всё-таки очередь в 256 (!) исходящих запросов), но... осадок остался...

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

На скорость массива RAID01 WB-кэширование повлияло неоднозначно. С одной стороны при малых нагрузках мы наблюдаем снижение скорости (до 5 процентов), с другой - на больших нагрузках WB-кэширование даёт нам плюс в скорости на те же 5-6 процентов.

Для массива RAID1 включение WB-кэширования даёт просто ошеломляющий эффект - даже при линейной нагрузке в режимах с большой долей запросов на запись прирост скорости составляет два десятка процентов! Максимальный "бонус" от WB-кэширования составил гигантскую цифру в 36 процентов!
Но, как видим, красные клетки проникли и в этот тропический рай. Почему же они возникли? Обратите внимание, что они сгруппированы в левой части таблицы, то есть в "зоне ответственности" операций чтения, но ни одна из красных клеток не возникла в режиме RandomRead. Итак, снижение скорости работы массива происходит при включении WB-кэширования в смешанных режимах с преобладанием запросов на чтение.
Как мы знаем из предыдущих наших тестов контроллеров Promise, включение WB-кеширования немного увеличивает время отклика контроллера при обработке запросов. И если с запросами на запись причина замедления очевидна - драйвер контроллера тратит процессорное время на обдумывание стратегии кэширования (поиск среди отложенных запросов на запись такого, который можно "объединить" с вновь пришедшим и т.п.), но почему контроллер терял скорость при работе с запросами на чтение - загадка.
Здесь же замедления в режиме RandomRead мы не наблюдаем, а вот при появлении в потоке запросов на запись контроллер теряет скорость. И набирает её обратно контроллер либо при увеличении доли операций на запись, то есть когда WB-кэширование даёт плоды, либо при увеличении глубины очереди запросов - когда драйверу контроллера "есть из чего выбрать". Похоже на правду?

Ну, что же, после анализа результатов этого паттерна мы выяснили, что включение WB-кэширования сказывается на результатах только некоторых комбинаций из типа массива и количества винчестеров. Очевидно, что алгоритмы кэширования завязаны на работу с парой винчестеров в RAID0 или RAID1. На массиве RAID01 эти алгоритмы "сработали" потому, что организация этого массива предусматривает зеркалирование пары страйп-групп. На каком этапе сработал на RAID1 кэширующий драйвер - сказать сложно. Может быть, он работает с каждой из RAID0-групп, а может быть, он работает на зеркальной паре из двух стайп-групп. Одно ясно - для RAID01 включение WB-кэширования ощутимой пользы не даёт. Посему, лучше его и не включать. От греха подальше. :)
Для RAID0 и RAID1-массивов полезность WB-кэширования зависит от характера запросов. Например, RAID0-массив с включённым WB-кэшированием отлично работает в режимах с преобладанием запросов на чтение, но не очень любит режимы с большой долей записи и большой нагрузкой. Для RAID1-массива всё обстоит с точностью до наоборот.

Intel IOMeter: Sequential Read & Write

Итак, посмотрим, как контроллер справится с последовательным чтением/записью. О, конечно, нам интересно, влияет ли на скорость чтения/записи в таком режиме схема кэширования запросов (WB/WT).

На массив при помощи программы IOMeter подаётся поток запросов на чтение/запись с глубиной очереди команд, равной четырём. Раз в минуту в тесте меняется размер блока данных, так что после окончания теста мы получаем зависимость скорости линейного чтения или записи от размера блока данных. Полученные результаты (зависимость скорости прокачки данных контроллером от размера блока данных) сведены в таблицы.



Если сравнить между собой скорость контроллера в режимах WB и WT, то мы увидим, что разницы почти нет! Потому я привожу графики скорости чтения только для режима WB:


Ну, что же, масштабируемость скорости работы от количества дисков в массиве у контроллера просматривается, но достигается максимальная скорость чтения только при сверхбольших размерах запроса. К тому же массив из четырёх дисков не вышел на планку 160МБ/сек. Правда, чуть позже мы увидим, что проблема скорее не в контроллере, а в дисках.

Сравним скорость чтения с массива RAID1 со скоростью чтения с JBOD-диска и скорость чтения с RAID01-массива со скоростью чтения с массива RAID0 из двух дисков. Как мы помним, некоторые производители практикуют чередование запросов на чтение между дисками зеркальной пары. Таким образом, RAID1-массив при чтении уподобляется RAID0-массиву, и скорость чтения с массива (теоретически) может удвоиться!


Но при взгляде на графики становится очевидно, что подобные ухищрения контроллер Promise не использует. Скорость чтения с массива RAID1 всегда меньше, чем с одиночного диска, а массив RAID01 по скорости чтения уступает массиву RAID0 из двух дисков. К тому же на графиках скорости массивов RAID1 и RAID01 мы видим провалы при работе с блоками по 64-128 и 64-256КБ.

Посмотрим, что у нас получится с записью:



Что любопытно, скорость записи на массивы массивов при различных настройках кэширования тоже мало чем отличалась! Хотя, как мы видели в тестах SATA RAID-контроллера Promise, различия должны были быть существенными.


Посмотрите, какая прелесть! Я даже прослезился от счастья - идеальная масштабируемость контроллера. Очевидно, что при записи диски Maxtor 6L020L0 ведут себя "как примерные мальчики", и контроллер выжимает из них всё до последнего...

Сравним по скорости записи массивы RAID1 с JBOD и RAID01 с RAID0 из двух дисков.


Как видите, массив RAID1 полностью аналогичен по скорости записи одиночному диску, а массив RAID01 - массиву RAID0 из двух дисков, лишь немного уступая последнему на 8 и 16КБ-блоках.

Тестирование в паттернах последовательного чтения/записи показало, что алгоритмы WB-кэширования контроллера TX4000 отличаются от тех, что мы изучали в обзоре SATA RAID-контроллера Promise.

Winbench99

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



Не тратя время на рассматривание огромных серых и скучных таблиц, переходим к сравнению скоростей различных массивов по двум интегральным подтестам - Business Disk Winmark и High-End Disk Winmark:



Ну, обсуждать тут, по большому счёту нечего... Как и следовало ожидать, первые два места завоевали RAID0-массивы из трёх и четырёх дисков (против лома нет приёма :) ), а за третье место сражаются RAID01 и RAID0 из двух дисков. Причём при WT-кэшировании победил массив RAID01, а при WB-кэшировании - RAID0 из двух дисков. Также следует отметить соревнование между RAID1-массивом и одиночным диском - при WT-кэшировании одиночный диск быстрее массива RAID1, а при переходе к WB-кэшированию массив RAID1 выходит вперёд.
Желающие могут вернуться к обсуждению результатов паттерна Database и поискать в "цветастой" таблице область нагрузок, которая соответствует вышеописанным симптомам. :)





Под FAT32 всё оказалось намного проще, чем под NTFS - массив RAID1 всегда быстрее одиночного диска, а массив RAID01 - всегда медленнее, чем RAID0 из двух дисков.

Intel IOMeter: Workstation

Вернёмся к тестам с использованием IOMeter. Паттерн Workstation призван имитировать интенсивную работу пользователя в различных приложениях на файловой системе NTFS5.



Чтобы сравнить между собой скорость работы различных типов RAID-массивов и, одновременно, попытаться отследить эффект от WB-кэширования, мы построим диаграмму с рейтингами быстродействия массивов. Сам рейтинг мы считаем по следующей формуле:

Производительность = Total I/O (queue=1)/1 + Total I/O (queue=2)/2 + Total I/O (queue=4)/4 + Total I/O (queue=8)/8 + Total I/O (queue=16)/16 + Total I/O (queue=32)/32

Как видите, максимальную скорость опять продемонстрировали два RAID0-массива на трёх и четырёх винчестерах, что коррелирует с результатами Winbench. Однако, в отличие от результатов тестов Winbench, в этом паттерне RAID01-массив намного опередил RAID0-массив из двух дисков и буквально дышит в затылок RAID0-массиву из трёх дисков! Да и RAID1-массив намного оторвался от одиночного диска, но, к сожалению, опередить RAID0 из двух дисков не смог.
Отметим, что WB-кэширование практически для всех массивов оказалось полезным (а всё потому, что в паттерне Workstation довольно солидна доля запросов на запись).

Intel IOMeter: Fileserver & Webserver

Завершают программу нашего тестирования паттерны, имитирующие работу дисковой подсистемы файл- и веб-сервера.




Для сравнения производительности различных типов RAID-массивов мы опять применим рейтинг. Однако для серверных паттернов мы просто усредняем значения Total I/O, полученные при всех вариантах нагрузки (считая все нагрузки равновероятными).


Очевидно, что массивы, использующие зеркалирование - RAID1 и RAID01 при подобной нагрузке чувствуют себя, как рыба в воде. Только посмотрите, как RAID01-массив порвал на британский флаг RAID0-массив из трёх дисков. Массив RAID0 из четырёх дисков удержал первое место, но только потому, что в паттерне Fileserver присутствуют операции записи, которые RAID0-массив исполняет быстрее, чем массив RAID01. Массив RAID1 с трудом, но одолел RAID0-массив из двух дисков.

Посмотрим, как будут вести себя массивы в паттерне Webserver, которые примечателен тем, что в нём отсутствуют запросы на запись (подразумевается, что сервер не содержит динамического контента и просто выдаёт "на гора" затребованные файлы).





Отсутствие в потоке запросов операций записи коренным образом меняет расстановку сил между массивами. На первое место с солидным отрывом выходит массив RAID01, а массив RAID1 вплотную подбирается к RAID0 из трёх дисков!

По результатам тестов в паттерне Database и паттерне Webserver мы можем сказать, что при случайном характере запросов на чтение контроллер Promise TX4000 чередует запросы между винчестерами зеркальной пары.

Выводы

Контроллер Promise FastTRAK TX4000 произвёл на меня весьма приятное впечатление.
Во-первых, для первой версии драйверов/BIOS он показал очень высокую производительность. Причём "слабых" мест я вот так сходу назвать и не могу.
Во-вторых, уже с первой версией драйверов/BIOS контроллер не создал мне ни одной проблемы (исключая вышеописанный курьёз с утилитой PAM).

От контроллера FastTRAK100 TX4 наш герой выгодно отличается простотой конструкции и, следовательно, ценой. Будем надеяться, что и проблем с совместимостью у TX4000 будет много меньше. Впрочем, тот факт, что чип PDC20619 интегрирует на свои материнские платы такой производитель, как Intel, уже о многом нам говорит...

P.S. Следующий наш рассказ о контроллере HighPoint RocketRaid 404, который не так давно научился делать RAID5.