HAB или Что Такое RAID0?
реклама
Есть два параметра - Burst Read и Linear Read. Первое означает 'идеальные' условия чтения, когда данные лежат уже прочитанные в внутреннем кеши привода. Linear Read - обычное последовательное чтение.
Т.е., быстрее Burst получить данные с привода нельзя. (При больших блоках происходит насыщение очередей ... собственно, такой режим и невозможен в природе, потому на срыв 'Burst' при больших блоках не стоит обращать внимание)
Какие факторы влияют на Burst?
1. как 'далеко' находится накопитель, т.е. время от запроса до получения блока.
2. firmware и его попытки предсказать последующие запросы
3. кеширование в драйвере
4. размер блока передачи информации
5. пропусканая способность интерфейса
По пунктам:
п1. При передаче информации от накопителя в OS используется блочный режим передачи. Одна из его неприятных моментов - блок считается принятым только по получения всех данных блока. Т.о., надо учитывать время от_запроса до момента окончания приема.
Из элементарной логики следует, что пропускной способности SATA1 'за глаза' хватает для такой скорости передачи ... но вот время на передачу блока в SATA1 будет явно больше, чем в SATA2. Тоже касается и интерфейсов между контроллером диска и памятью (данные с накопителя всегда считsdf.ncz в системную память).
Сам контроллер может быть подключен к шине PCIe или PCI. У них разное время доступа. Кроме того, есть 'родные' и 'неродные' контроллеры. Например, в nForce IDE встроен в chipset и потому имеет очень маленькое время доступа.
Как-то делал PCI устройство и был крайне огорчен замером времени доступа к PCI. Если это первичная шина и контроллер находится в чипсете, то его время доступа мало. Для внешних PCI устройств время возрастает очень сильно, буквально 'в разы'. Собственно, мост PCI-PCI и этим все сказано.
У Intel с его 'хабовой' структурой накладывется еще время доступа к 'хабу'.
Потому, потенциально, структура HT от AMD с встроенным IDE должна иметь наилучшие из возможных вариантов подключения IDE диска. Вторым по эффективности (из-за hub организации) идут варианты реализации Intel, потом внешние контроллеры, реализованные прямо на mainboard, потом 'все остальное'. Очень хороший пример привел -TRANTOR- ( link)
Очень мощный процессор, очень хорошие диски, а скорость падает практически линейно от размера блока - сказывается большое время доступа к контроллеру, да и сам контроллер явно не слишком быстрый.
Если взять два (почти)одинаковых диска и посмотреть их характеристики в вариантах AMD (nForce4) {слева} и Intel (i965/JMicron), то разница весьма заметна. У AMD диск "ближе", на JMicron 'дальше', что сказалось на Burst при уменьшении блока ... ну и на linear read, естественно.
п2. firmware и его попытки предсказать последующие запросы
Собственно, тут мало что можно сказать. Разные диски, разные версии firmware. У меня на работе достаточно древний диск:
Здесь виновато или чрезмерные аппетиты контроллера по предсказанию чтения (отсюда большое latency) или банально тормозной контроллер.
(да и Burst косвенно на это указывает)
п3. кеширование в драйвере
Есть кеширование записи и кеширование чтения. Если по записи понятно и особо деструктивным действием сие не отличается (ну, запишет 'когда сможет'), то кеширование чтения может вызвать (точнее вызывает) падение скорости. Что такое кеширование чтения? - банальное чтение данных дальше, чем требуется -- а вдруг они потребуются позже? Из-за этого растет время доступа к следующим данным, т.к. пока не передадутся ненужные данные, контроллер не сможет выдать нужные. Немного упростил.
(Потестироваль кеширование чтения в nForce и отключил навсегда. По умолчанию это кеширвоание включено.)
NCQ/TCQ ... на том, что у меня было, это не давало реального ускорения, а вот проблемы и провалы скорости были. Для _Вашего_ случая надо тестировать индивидуально. Я - отключил, это загружает процессор и когда он занят, может вызвать дополнительное падение скорости и рывки/падение FPS.
п4. размер блока передачи информации
Боюсь, влиять на прохождение информации внутри аппаратуры мы не сможем, потому и говорить особо не о чем.
Тут вот в чем дело - контроллер передает информацию блоками, на которым его запрограммировали. Тут есть ограничения на формат посылки, нельзя надолго занимать шину (изначально формат проектировался на PCI). Аппаратно-специфед, потому возможны всякие чудеса.
5. пропусканая способность интерфейса
Ну, пропускной способности даже SATA1 вроде-бы хватит, а вот с другими интерфейсами? PCI уже хватит только на 1 диск и только при том, что больше никто эту шину PCI не использует (в системе может быть несколько шин PCI, между ними ставят мосты)
RAID0 как таковой....
При чтении (да и записи) информации работа с одним файлом разбивается на чтение нескольких файлов меньшего размера, расположенных на нескольки дисках. Для примера, возьмем RAID0 на 2х дисках. При этом чтение (повторяю, и запись) файла разбивается на чтение файла половинной длины диском 0 и диском 1. Причем, диск 0 читает четные сектора файла, диск 1 - нечетные.
В результате --- читается файл в двое меньшего размера и в 2 раза быстрее (в идеале). Отходим от идеала на реальную почву, при уменьшения размера блока интерлива можно получить ситуацию, когда весь блок содержится только на одном из дисков. При этом второй не получит запрос на чтение.
С одной стороны, в 2 раза медленнее, с другой - второй диск свободен и если драйвер поддерживает многопоточность, то на него можно выслать запрос на чтение _другого_ файла.
Как-то давно тестировал и у меня вышло, что родные M$ драйверы это не умеют, в отличии от nForce. Правда, это касалось параллельной работы с двумя независимыми дисками.
Как обстоят дела у производителей с их разноплановыми драйверами (AMD/Intel/JMicron) - болото еще то. (Принцип 'Неуловимого Джо')
Так вот, если драйвер поддерживает многопотопоточность, то уменьшение размера блока интерливинг 'до железки' может и не стоит делать. А вот если не поддерживает, то надо гнать до миниума - иначе Вы банально теряете производительность.
Второй момент - любой нормальный драйвер умеет собирать 'мусор' и при чтении большого файла не высылает много мелких запросов на каждый конкретный контроллер/диск. Т.е. чтение очень большого файла при любом размере блока интерливинг будет идти одинаково.
Если драйвер кривой, то скорость чтения будет зависеть .... тогда стоит поискать новую версию софта.
Еще момент - OS, как и прикладные программы, читают данные блоками. Для выяснения этого есть закладка статистики. Можно позапускать различные программы и посмотреть на размер блока, которыми оперируют. На основании этого можно оценить эффективность того или иного размера интерливинг RAID0. Например, основной блок для OS типа XP составляет 64Kb. Для его ускорения хорошо-бы иметь блок интерливинга в 2 раза меньше (если 2 диска).
И еще момент - чем меньше блок передачи по интерфейсу диск-.-.-.-память, тем болше надо процессорного времени на обработку, ведь каждая передача сопровождается хоть небольшой, но работой процессора (надо настроить BUS Mastering &etc). Если процессор свободен (или их несколько), то проблем нет, а вот на single процессоре и сильной загрузке это может вызвать небольшие локальные загрузки процессора (микрорывки и падение FPS в играх). Потому очень-очень маленькими блоками интерливинг я бы не стал.
На nF4 у меня был блок интерливинг 8К.
Как интертрепировать результаты программы?
Если взять последний пример, то из него следует:
- линейная скорость чтения диска 55MB/s
- burst 97MB/s
- блок, на котром burst = linear read = 16Kb, но при этом скорость чтения падает не на обычные 5-10%, а в 1.5 раза (отличное железо, нечего сказать!), т.е. блок интерливинга в 16Kb даст падение скорости на мелких файлах в 1.5 раза по сравнению с одиночным диском. (Поясню - если один диск, то он бы считал 32Kb, а RAID0 из 2х таких дисков прочитли бы по 16Kb)
Т.е. 16Kb для такого диска -
Значит 32К.
реклама
Лента материалов
Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!
Комментарии, содержащие оскорбления, нецензурные выражения (в т.ч. замаскированный мат), экстремистские высказывания, рекламу и спам, удаляются независимо от содержимого, а к их авторам могут применяться меры вплоть до запрета написания комментариев и, в случае написания комментария через социальные сети, жалобы в администрацию данной сети.
Сейчас обсуждают