Promise FastTRAK S150 TX4

Введение

В продолжение обещанной серии обзоров многоканальных (4-х и более) SATA RAID-контроллеров, мы рассмотрим контроллер FastTRAK S150 TX4 от Promise.
Контроллер этот, судя по всему, является близким родственником рассмотренного нами ранее Promise TX4000. Потому, многое, что Вы сегодня увидите, покажется Вам знакомым. Хотя, конечно, используемые в тестах диски - WD Raptor - придают каждому обзору SATA RAID-контроллера некоторую пикантность.
Думаю, многие из Вас втайне лелеют надежду, что SATA RAID-контроллеры сумеют когда-нибудь победить SCSI RAID. :)

Итак, чем же сегодня нас будет удивлять Promise?

Контроллер FastTRAK S150 TX4

Как можно догадаться из названия, контроллер может поддерживать до четырех Serial ATA/150 устройств. Набор поддерживаемых типов RAID-массивов стандартен - RAID0, RAID1, RAID0+1, JBOD. За счет способности контроллера работать в 66МГц слоте PCI 2.3 максимально возможная теоретическая пропускная способность контроллера составляет 266МБ/c. FastBuild™ BIOS оптимизирует производительность накопителей в зависимости от их типа, поддерживает загрузку системы из массива любого уровня, совместимость с BBS, имеет удобную систему меню для создания и конфигурирования массива, поддерживает конфигурации из нескольких массивов одновременно. Имеется возможность программного обновления BIOS. Утилита Promise Array Management (PAM) позволяет контролировать состояние массивов, винчестеров и контроллера локально или удалённо (через TCP/IP). Также утилита предупреждает об ошибках, позволяет восстанавливать аварийные устройства, синхронизирует данные в отказоустойчивых массивах, позволяет сообщать об ошибках или событиях массива по электронной почте, контролирует S.M.A.R.T-статус включенных винчестеров.
Внешний вид контроллера:


Контроллер, как мы можем видеть, имеет привычный светло-зеленый цвет с темно-зелеными прожилками дорожек, просвечивающих сквозь лаковое покрытие. Радиатором прикрыт контроллер Promise PDC20319. Сбоку расположены два разъема для подключения LED-индикаторов. Четыре SATA разъема и микросхема BIOS-a равномерно распределены по верхней кромке платы и создают ощущение свободного пространства на плате. При этом, контроллер имеет достаточно малые размеры (low profile) и, сравнив размеры FT S150TX 4 и FT TX4000, можно сказать, что SATA – определенно путь к увеличению свободного места внутри корпуса компьютера.

Таблица параметров:

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

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

корпус - Intel SC5200
материнская плата – Intel SHG2;
процессор - 2 x Intel Xeon 2.8/400FSB;
память - 2 x 512MB DDR SDRAM PC2100 ECC Registered;
винчестер - IBM DTLA 307015;
видеокарта – onboard ATi Rage XL;
операционная система - Windows 2000 Pro SP4.

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

WinBench 99 2.0
IOMeter 2003.02.15

В Winbench99 на логическом диске создавался один раздел на весь объём диска. Тесты Winbench проводились по семь раз, выбирался лучший показанный результат.

Для сравнения скорости работы винчестеров при помощи теста IOMeter использовались паттерны Fileserver & Webserver.


Эти паттерны призваны измерить производительность дисковой подсистемы при нагрузке, типичной для file- и web-серверов.

Паттерн Workstation, используемый нами, создан нашим автором Романовым Сергеем aka GReY на основании статистики обращений к диску при работе различных приложений, приведённой в описании SR Testbed3. Статистические данные собраны на файловой системе NTFS5 в режимах работы Office, Hi-End и Boot-up.


Этим паттерном мы будем руководствоваться для оценки привлекательности винчестеров для обычного Windows-пользователя.

Ну и, наконец, была проверена способность винчестеров работать с Sequential-запросами переменного размера на чтение/запись и скорость дисков в паттерне Database, имитирующем работу дисковой подсистемы с SQL-подобными запросами.

В контроллер был прошит BIOS 1.00.0.37, использовались драйвера 1.00.0.37. Для контроля состояния массива и для синхронизации массивов использовалась программа PAM (Promise Array Management) версии 4.0.0.18.

Контроллер устанавливался в слот PCI-X/133МГц (хотя контроллер поддерживает только PCI32 33/66МГц).
Диски WD360GD (Raptor) устанавливались в штатные салазки корпуса SC5200 и крепились четырьмя винтами за нижнюю грань.

При выполнении основной программы тестирования отложенная запись для дисков разрешалась, а режим работы кэширования запросов драйвером (WriteBack и WriteThrough) менялся по необходимости.

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

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

IOMeter: паттерн Database

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


То же самое, только графически:



Обратите внимание, что при линейной нагрузке (один исходящий запрос) скорость массива RAID1 из двух дисков практически полностью повторяет JBOD, а RAID01 массив - RAID0 из двух дисков.
Судя по всему, при контроллер в режиме WT «не задерживает выполнение запросов», а сразу раскидывает их по дискам, и, потому, чередование запросов на чтение между дисками зеркальной пары просто не работает.
При этом, основной вклад в рост скорости массива при увеличении доли запросов на запись вносит не контроллер, а диск WD360GD. Точнее, алгоритмы отложенной записи дисков Raptor…

При чтении (в точке с нулевым процентом запросов на запись) все массивы демонстрируют очень близкие скорости, т.е. их скорость фактически зависит от access time винчестера WD Raptor.



Увеличение нагрузки меняет картину распределения скоростей. Зеркало (массив RAID1) всегда быстрее одиночного диска даже в точке RandomWrite (100% запросов на запись). Предположение, что разницу в этой точке, можно считать погрешностью эксперимента, опровергается повторяемостью результатов тестов.

Массив RAID01, в свою очередь, быстрее массива RAID0 из двух дисков во всех точках кроме RandomWrite. При небольшой доле запросов на запись (менее сорока процентов) он оказывается даже быстрее массива RAID0 из четырех дисков. Теоретически, конечно, RAID0 – самый быстрый тип массива и RAID01 по чтению должен быть медленнее. НО, так как для RAID0-массива чередование запросов на диски осуществляется согласно правилу «в чьё адресное пространство попадает запрос, тот диск и отвечает», то при случайном характере запросов может получиться так, что два (или больше) запросов подряд придут на один и тот же диск. Этот диск будет нагружен работой, а остальные в этот момент – простаивать. Соответственно, скорость массива будет ограничена скоростью одного диска. Для массива, содержащего зеркальные пары, чередование запросов на чтение (а может и на запись) внутри этой пары будет производится в строгом порядке первый-второй, т.е. диски будут обрабатывать запросы поочерёдно и вне зависимости от размера блока (на самом деле, порядок чередования винчестеров может быть и более «умным»). Загрузка дисков получается намного более равномерной, что ведёт к росту «среднего» быстродействия.



Увидев графики при нагрузке в 256 запросов, я, честно говоря, обрадовался, вот думаю, они –“хрестоматийные” распределения скоростей. Графики скоростей RAID0 массивов и одиночного диска почти «параллельны». Зеркальный массив RAID1 в точке RandomRead в два раза быстрее одиночного диска и плавно снижает свою скорость до совпадения графиков в точке RandomWrite. Скорости массивов RAID01 и RAID0 из двух дисков, ведут себя по отношению друг к другу так же.

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


И снова в виде графиков:



Даже при линейной нагрузке массив RAID1 быстрее одиночного диска, а массив RAID01 обгоняет массив RAID0 из двух дисков. Как мы помним, в режиме WT такого не происходило. Это значит, что режим WB (кэширование драйвером запросов на запись) даже при линейной нагрузке позволяет увеличить скорость работы массивов, содержащих зеркалирование.



При нагрузке в 16 запросов преимущества массивов, использующих зеркалирование (RAID1 и RAID01), над массивами JBOD и RAID0 из двух дисков соответственно, становятся еще более наглядным. Массивы RAID0 демонстрируют низкую скорость при небольшой доле запросов на запись, как и в случае WriteThrough. Однако, в данном случае, этот провал по скорости становится более выраженным. Обратите внимание на ступенчатость графиков массивов RAID0. Можно обнаружить, что для массивов из двух, трех и четырех дисков провал по скорости исчезает при двадцати, тридцати и сорока процентах запросов на запись соответственно. Кстати, эти ступеньки были и в режиме WT, так что это не результат работы алгоритмов WB. Так как мы ни разу не видели подобных "ступенек" при тестировании других SATA RAID-контроллеров, то это, по-видимому, результат работы драйверов Promise.



При нагрузке в 256 запросов картина качественно не отличается от подобных условий в режиме WriteThrough.

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


Попробуем проанализировать это лоскутное одеяло. :)

Сначала общее впечатление:
Во всех массивах включение WB-кэширования в драйвере привело к падению скорости режиме RandomRead и к увеличению скорости в режиме RandomWrite, а так же, в основном, замедлило работу при очереди в 256 запросов.

А теперь подробнее:
Одиночный диск демонстрирует рост эффективности WB - кэширования с ростом числа запросов на запись, и спад с увеличением числа запросов. Поэтому влияние WB-кэширования на скорость JBOD можно назвать неоднозначным. С одной стороны, присутствует как увеличение, так и уменьшение скорости. С другой стороны, уменьшение скорости не превышает 3-х процентов, а увеличение скорости порой достигает 20-ти процентов.
Для всех остальных массивов включение WB-кэширование снижает скорость работы в основном только в режиме RandomRead и при очереди в 256 запросов. Максимальный "ущерб" скорости от включения WB-кэширования составил 5 процентов, а максимальный выигрыш – 25 процентов. Особенно внимательный читатель заметит, конечно, красные вкрапления и при линейной нагрузке и при очереди в 64 запроса, но в этих случаях уменьшение скорости не превышает двух процентов.

На линейной нагрузке в массиве RAID01 при равных долях запросов на запись и чтение падение скорости составляет 10 процентов. Вероятнее всего, эта точка выпадает из общей картины потому, что этот режим самый сложный для драйвера. Сложно принимать решения, когда доли запросов равны, а массив – сложноподчинённый.

Итак, снижение скорости работы массива встречается при включении WB-кэширования в смешанных режимах с преобладанием запросов на чтение, всегда происходит в режиме RandomRead, и никогда не происходит в режиме RandomWrite.
Как мы знаем из предыдущих наших тестов контроллеров Promise, включение WB-кеширования немного увеличивает время отклика контроллера при обработке запросов. И если с запросами на запись причина замедления очевидна - драйвер контроллера тратит процессорное время на обдумывание стратегии кэширования (поиск среди отложенных запросов на запись такого, который можно "объединить" с вновь пришедшим или поиск более оптимального порядка выполнения запросов), но почему контроллер терял скорость при работе с запросами на чтение - загадка.
Здесь мы наблюдаем замедление в режиме RandomRead и рост скорости при появлении в потоке запросов на запись. При этом, положительное влияние WB-кэширования снижается, в отличие от контроллера Promise FastTRAK TX4000, при увеличении глубины очереди запросов - когда драйверу контроллера "есть из чего выбрать".
В общем случае, когда в работе контроллера используются запросы на запись, можно считать влияние WB-кеширования положительным. Очереди в 256 запросов, практически недостижимы в реальной жизни, и поэтому в большинстве случаев включение WB-кэширования не снизит скорость работы. Я, сходу, могу назвать только один пример, когда его не стоит включать – вебсервер, в работе которого, практически не встречаются запросы на запись.

IOMeter: паттерны Sequential Read&Write

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



В отличие от контроллера Promise FastTRAK TX4000, сравнение графиков в режиме WB и WT демонстрирует достаточно большие различия, поэтому рассмотрим их отдельно. Для лучшего представления, RAID-массивы разобьем на две подгруппы.



Как мы помним, некоторые производители практикуют чередование запросов на чтение между дисками зеркальной пары, причем, делают «это» даже при линейном чтении. Таким образом, RAID1-массив при чтении уподобляется RAID0-массиву, и скорость чтения с массива (теоретически) может удвоиться! Но, как мы убеждаемся по результатам теста, этим алгоритмом контроллер Promise FastTRAK S150 TX4 пользуется (впрочем, как и все предыдущие рассмотренные нами контроллеры от Promise) только при случайном чтении.
Скорость чтения с массива RAID1 почти всегда меньше скорости чтения с одиночного диска, что довольно-таки досадно.
Массив RAID01 всегда отстает от массива RAID0 из двух дисков, а при размере блока данных от двух до восьми KБ отстает и от массива JBOD. К тому же, на графиках RAID01 и RAID1 мы видим провалы при работе с блоками 32 и 256 КБ соответственно.

Теперь посмотрим, как меняется картина при включении WB-кэширования:


На первый взгляд графики кажутся хуже, чем в случае WriteThrough - изломанные и некрасивые. Однако, по абсолютной величине скорость работы при небольших блоках данных всегда выше, а при увеличении блоков почти всегда не ниже. Правда, на каждом графике встречается точка или две, где скорость упала по сравнению с WT, но можно считать, что WB-кэширование оказывает, в основном, положительное влияние на скорость работы массивов RAID0 и JBOD при линейном чтении небольшими блоками данных, и практически не оказывает влияния на скорость чтения большими блоками.


Использование WB-кэширования увеличивает скорость зеркальных массивов при размерах блоков данных менее восьми КБ и не оказывает влияние на скорость чтения большими блоками.
Это приводит к тому, что скорость чтения на блоках менее восьми КБ одиночного диска и массива RAID1 одинакова. При увеличении размера блока, скорость начинает ограничиваться скоростью работы винчестеров и влияние WB-кэширования становится незаметным.

Переходим к последовательной записи:



А теперь в графической интерпретации:


А вот и первые неприятности. Массив RAID0 из двух дисков демонстрирует почти полное удваивание скорости одиночного диска, что вполне приемлимо, но уже скорость массива RAID0 из трех дисков практически совпадает со скоростью массива из двух. А массив из четырех даже начинает отставать от остальных RAID0 массивов при записи блоков данных, превышающих 16 КБ. Подобная картина наблюдалась и на контроллере Intel SRCS14L. Но если там был виноват недостаточный размер кэша, то в контроллере FastTRAK S150 TX4 (кэш только программный), по видимому, виноват драйвер.


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

Теперь посмотрим, как изменятся графики при включении WB-кэширования:



Как и при случайном чтении, включение WB-кэширования позволяет сильно увеличить скорость работы с небольшими блоками данных.

Скорость записи становится максимальной при очень маленьких блоках данных и не изменяется с их увеличением. Как мы помним, это происходит потому, что драйвер контроллера, используя ресурсы центрального процессора «склеивает» запросы на последовательно расположенные данные. При этом запросы, отсылаемые драйвером на диск, имеют довольно большой размер, удобный и для диска и для интерфейса.
Что любопытно, это приводит к тому, что скорость массива RAID0 из четырех дисков всегда меньше скорости остальных RAID0 - массивов.

Скорость массива RAID01 самая низкая при любом размере блока, а скорость массива RAID1 совпадает со скоростью одиночного диска всегда, кроме работы с блоками в 1 и 2 КБ.

Теперь посмотрим, на поведение контроллера в условиях, приближенных к боевым:

IOMeter: Fileserver&Webserver

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



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





Массивы, использующие зеркалирование (RAID1 и RAID01), демонстрируют прекрасные результаты. Массив RAID1 практически совпадает с массивом RAID0 из двух дисков, если не считать провала при глубине очереди в 16 запросов. Этот провал встречается как в режиме WT, так и WB, но при включенном WB-кэшировании, глубина провала значительно меньше. Массив RAID01 обгоняет все массивы, кроме RAID0 из четырех дисков, а при глубине очереди в 4 и 16 запросов, демонстрирует самую высокую производительность

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


Массив RAID0 из четырёх дисков удержал первое место по производительности, но только потому, что в паттерне Fileserver присутствуют операции записи, которые RAID0-массив исполняет быстрее, чем массив RAID01. Массив RAID1 отстал от массива RAID0 из двух дисков, из-за тех же самых 20-ти процентов операций записи, хотя их графики практически совпадали. К тому же, рейтинговая система демонстрирует, что для увеличения производительности при включении WB-кэширования достаточно даже такого количества операций записи.
Посмотрим, как будут вести себя массивы в паттерне Webserver, в который примечателен тем, что в нем отсутствуют запросы на запись.
Пара табличек:



И несколько графиков:




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


Рейтинговая система, в которой мы сравниваем производительности различных RAID массивов (рассчитываем общий балл так же, как и в рейтинге Fileserver), демонстрирует такое же распределение по производительности, как и на графиках. Использование WB-кэширования приводит к явному снижению производительности. Причина проста - отсутствие запросов на запись. В этом случае кэширование не дает полезного вклада, а процессорное время на работу драйвера тратится, что, в целом, дает снижение производительности.

IOMeter:Workstation

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



На этот раз рассмотрим графики для WT и WB отдельно:



Массивы RAID0 демонстрируют рост, однако, начинают масштабироваться по количеству дисков только при очереди более четырех запросов. Массив RAID01 при четырех запросах обгоняет массив RAID0 из четырех дисков, но имеет провал, так же как и массив RAID1 при очереди из шестнадцати запросов.



Использование WB-кэширования, как уже было показано выше, повышает производительность. RAID01 обгоняет массив RAID0 из четырех дисков при очереди из двух запросов.

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

Производительность = 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


Присутствие большой доли запросов на запись в паттерне привело к тому, что массив RAID1 отстал от массива RAID0 из двух дисков. А вот массив RAID01 удержал второе место, хотя массив RAID0 из трех дисков приблизился к нему вплотную. WB-кэширование демонстрирует увеличение производительности до от шести до десяти процентов.

Winbench99

Завершаем этот обзор пакетом Winbench, который служит нам в качестве "измерителя" производительности винчестеров при работе с "десктопными" приложениями.



Сравним скорости различных массивов по двум интегральным подтестам - Business Disk Winmark и High-End Disk Winmark:



Как и следовало ожидать, первые три места завоевали RAID0-массивы из четырёх, трёх и двух дисков. Массив RAID01 вплотную приблизился к массиву RAID0 из двух дисков. Следует отметить соревнование между RAID1-массивом и одиночным диском - при WT-кэшировании одиночный диск быстрее массива RAID1, а при переходе к WB-кэшированию массив RAID1 выходит вперёд.






Массив RAID01 опять отстал от всех RAID0 – массивов, а RAID1 – массив от одиночного диска.

Так как скорости линейного чтения одинаковы для NTFS и для FAT32, то приведем всего одну диаграмму:


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

1HDD - JBOD
2HDD - RAID1
2HDD - RAID0
3HDD - RAID0
4HDD - RAID0
4HDD - RAID01

Глядя на графики линейного чтения в RAID1 и RAID01 становится очевидно, что контроллер всё-таки пытается как-то оптимизировать процесс чтения с зеркальных пар, но вот получается это у него пока плохо. :(

Отказоустойчивость

Для проверки способности контроллера обеспечивать сохранность данных в массиве при отказе одного из дисков были смоделированы "аварии" одного из дисков в массивах RAID1 и RAID10.

Как и в обзоре контроллера Intel SRCS14L отказ жёсткого диска имитировался выдергиванием из диска SATA-разъёма питания. Состояние массива контроллировалось при помощи программы PAM (Promise Array Management).
Через, примерно, минуту после "отказа" диска программа PAM зафиксировала этот факт, и изменила статус массива с "Functional" на "Critical". Чтобы не нервировать окружающих (программа начала призывно "пикать" динамиком), питание диску было восстановлено. После чего, программа немедленно начала восстановление массива. На мой взгляд, это не совсем корректно - а, вдруг, я подсунул в массив всё тот-же отказавший диск...

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

Массив RAID1 был восстановлен за полчаса, а на восстановление массива RAID01 контроллер затратил чуть больше часа.

Выводы

По результатам тестов контроллер Promise FT S150 TX4 оставил, в целом, очень хорошее впечатление. Но, чтобы быть до конца справедливыми, давайте кратко вспомним поведение контроллера в каждом тесте.

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

Кстати, о настройках... Пришла в голову мысль, никак не могу от неё избавиться (от мысли, естественно...). Почему бы производителям RAID-контроллеров не облегчить работу собственным программистам - сделать в драйверах "пресеты", такие же, как в драйверах некоторых видеокарт. дейтвительно, зачем возлагать на драйвер тяжёлую задачу по определению типа текущей нагрузки, если можно просто выставить её в драйвере?!

Мысленно представил себе настройки "Winbench" и "FC-Test" и почти отказался от идеи. :)

Но, вернёмся к контроллеру Promise и его производительности.

В паттернах SequentialRead & SequentialWrite контроллер показал высокое быстродействие только при работе с массивами RAID0. Увы, и для RAID1 и для RAID01 мы наблюдали снижение скорости...

В паттернах Fileserver и Webserver контроллер отработал выше всяких похвал. Блестящая скорость массивов с резервированием данных заслуживает отдельного упоминания. Правда, и здесь мы наблюдали немотивированное снижение производительности массива RAID1 в паттерне Fileserver при нагрузке в 16 запросов.

В паттерне Workstation контроллер также был весьма быстр, правда большая доля запросов на запись, характерная для этого паттерна, не позволила контроллеру "блеснуть" скоростью при работе с RAID1 и RAID01.

В тестах Winbench контроллер также продемонстрировал отличную масштабируемость при работе с массивами RAID0, а вот массивы RAID1 и RAID01 скоростью, увы, не блеснули.

В целом, по результатам тестов контроллера у нас сложилось впечатление, что он больше подходит для серверов начального уровня, чем для высокопроизводительных рабочих станций. Впрочем, единственная проблема, с которой мы столкнулись при тестировании - низкая скорость линейного чтения в некоторых режимах, может быть вызвана некорректной работой контроллера в слоте PCI-X 133МГц.
Будем следить за обновлениями BIOS-а и драйверов контроллера. :)