3ware 9500S - низкая скорость
Модераторы: Trinity admin`s, Free-lance moderator`s
Wisky
Вообще-то тест от Fast. Но Fast сначала купил Pinnacle, теперь Avid потому и называют его сейчас авидовским.
Показатели у теста по чтению более-менее. Ясно, что скорость шины нормальная, иначе чтение за 110 бы не ушло. На запись, правда, все хреново. Все-таки, вот эти
9500S_cache_control_no_FUA_cache_setting_(best_write_performance).reg
изменения в реестр вносились?
P.S. Stripe size какой, кстати?
Вообще-то тест от Fast. Но Fast сначала купил Pinnacle, теперь Avid потому и называют его сейчас авидовским.
Показатели у теста по чтению более-менее. Ясно, что скорость шины нормальная, иначе чтение за 110 бы не ушло. На запись, правда, все хреново. Все-таки, вот эти
9500S_cache_control_no_FUA_cache_setting_(best_write_performance).reg
изменения в реестр вносились?
P.S. Stripe size какой, кстати?
-
- Power member
- Сообщения: 49
- Зарегистрирован: 12 дек 2005, 03:54
- Откуда: Moscow
- Контактная информация:
изменения в реестр вносились. Проверю еще раз.
Stripe size для массива я указал 256 Кб(зря?), а вот при форматировании - поторопился, не выбрал размер кластера.
Судя по всему он 512 байт на сектор...
В этом смысле меня больше парит именно рандомное чтение, т.к. вероятно, оно и дает проседание на некоторых тестах, если кластер маленький...
Это где-то можно глянуть(текущий размер)?
Stripe size для массива я указал 256 Кб(зря?), а вот при форматировании - поторопился, не выбрал размер кластера.
Судя по всему он 512 байт на сектор...
В этом смысле меня больше парит именно рандомное чтение, т.к. вероятно, оно и дает проседание на некоторых тестах, если кластер маленький...
Это где-то можно глянуть(текущий размер)?
Stripe size определяется задачами. Для видео мы ставим 1024. Для всяких других дел 64...128.
Размер кластера по умолчанию в XP и т.д. 8 секторов по 512 байт. Посмотреть текущий размер можно, например, такой программкой http://www.pxserver.com/WinAudit.htm.
Что касается того, какой размер нужен, то надо плясать от задач, для видео можно и увеличить, но в сущности это не очень важно.
Размер кластера по умолчанию в XP и т.д. 8 секторов по 512 байт. Посмотреть текущий размер можно, например, такой программкой http://www.pxserver.com/WinAudit.htm.
Что касается того, какой размер нужен, то надо плясать от задач, для видео можно и увеличить, но в сущности это не очень важно.
Несогласная я . Мы сами тестировали и просто некогда выкладывать полные результаты авидовского теста, поэтому только пару привожу. Размер файла 1 гиг.
Strip size 128 sectors
Rnd read 16 kB 21.5
Lin read 4096 kB 192.4
Strip size 1024 sectors
Rnd read 16 kB 8.5
Lin read 4096 kB 272.4
Это мы не 3Ware тестировали, но результат очевиден.
Кстати, кластер был по умолчанию 4К .
Да и вот нашел сходу
In general, a larger block size is better when handling large data transfers (such as A/V Editing or graphics) while a smaller block size is better handling email and other common server data. The default setting is 64Kb.
Strip size 128 sectors
Rnd read 16 kB 21.5
Lin read 4096 kB 192.4
Strip size 1024 sectors
Rnd read 16 kB 8.5
Lin read 4096 kB 272.4
Это мы не 3Ware тестировали, но результат очевиден.
Кстати, кластер был по умолчанию 4К .
Да и вот нашел сходу
In general, a larger block size is better when handling large data transfers (such as A/V Editing or graphics) while a smaller block size is better handling email and other common server data. The default setting is 64Kb.
-
- Power member
- Сообщения: 49
- Зарегистрирован: 12 дек 2005, 03:54
- Откуда: Moscow
- Контактная информация:
ну, во-первых, из твоего теста понятно, что на бОльших страйп-сайз больше пиковая скорость, но в случае рандома и тормозов мы огребем поболее. Т.е. как-раз интересует стабильность потока, не так ли?
во-вторых, я это не сам придумал.
у меня в мануале написано ровно следующее:
The default stripe size of 64KB will give the best performance with applications that have many sequential reads and writes. A larger stripe size will give better performance with applications that have a lot of random reads and writes. In general, the smaller the stripe size, the better the sequential I/O and the worse the random I/O. The larger the stripe size, the worse the sequential I/O and the better the random I/O.
PS. может у них разная организация работы с кластерами?
Я читал документацию от 9500S
во-вторых, я это не сам придумал.
у меня в мануале написано ровно следующее:
The default stripe size of 64KB will give the best performance with applications that have many sequential reads and writes. A larger stripe size will give better performance with applications that have a lot of random reads and writes. In general, the smaller the stripe size, the better the sequential I/O and the worse the random I/O. The larger the stripe size, the worse the sequential I/O and the better the random I/O.
PS. может у них разная организация работы с кластерами?
Я читал документацию от 9500S
Это как -то противоречит цитате из мануалано в случае рандома и тормозов мы огребем поболее.
Дабы не увеличивать энтропию, могу только констатировать, что с большей strip size с видео работа быстрее. Файлы огромные, чтение и запись в основном последовательные. Да и по логике так должно быть. Авидовский тест это тоже подтверждает. Что касается random доступа, то для видео это актуально только при большой запущенности диска, на котором за многие месяцы ни разу не делали дефраг, а работали круглые сутки . Стабильность потока тоже в норме . Именно на Canopus, кстати, гоняли некомпресс HD, поток под 100 мегов в секунду и все нормально. С маленьким strip size было хуже. Что имели ввиду 3ware, не знаю. Гуглом обнаруживаются разные точки зрения на stripe size в зависимости от задачи. Мы танцевали от практических результатов.A larger stripe size will give better performance with applications that have a lot of random reads and writes
Но далее дело ваше .
-
- Power member
- Сообщения: 49
- Зарегистрирован: 12 дек 2005, 03:54
- Откуда: Moscow
- Контактная информация:
С одной стороны - да, с другой - эту фразу я написал исходя из глубокого и всестороннего анализа приведенных тобой результатов.SMBV писал(а):Это как -то противоречит цитате из мануалано в случае рандома и тормозов мы огребем поболее.
И с логикой вещей и наглядностью авидовского теста - я тоже поспорить не могу.
В результате, придется как всегда все вытягивать на своем горбу. поэтому массив оставлю в покое, а вот переформатнуть видимо пару раз все-таки придется.
А вы с каким размером кластера в итоге форматировали? Отталкиваемся от того, что stripe size 256 Кб.
Гм.. Я писал ранее:А вы с каким размером кластера в итоге форматировали?
Размер кластера и размер stripe size в общем случае никак не связаны (но 512 байт это перегиб, конечно ), поэтому мы размер кластера по умолчанию (4K) не меняем.Кстати, кластер был по умолчанию 4К
Возвращаясь к теме топика, у Вас слишком медленно только запись работает. Это вряд ли связано с размером кластера или stripe size, иначе, как нетрудно понять, это бы отражалось не только на записи. Большой stripe size позволяет на видео файлах иметь линейный поток под 200 мегов на запись, но даже с маленьким stripe size скорость не может быть меньше 120-130 мегов на таком количестве дисков и приличном RAID контроллере.
-
- Power member
- Сообщения: 49
- Зарегистрирован: 12 дек 2005, 03:54
- Откуда: Moscow
- Контактная информация:
За кластер - сорри, проглядел видимо...
Тогда остается вот это:
Версия прошивки или что-то еще подобное?
2. Может ли быть такое, что контроллер без батарейки не включает кеш на запись? В биосе он ругается но включает. Только насколько это соответствует действительности?
Тогда остается вот это:
1.Вопрос - его как-то можно включить?gs писал(а):Кроме того, на винтах RE, насколько я знаю, отключен кэш на запись, что хорошо для надежности, но не для скорости.
Версия прошивки или что-то еще подобное?
2. Может ли быть такое, что контроллер без батарейки не включает кеш на запись? В биосе он ругается но включает. Только насколько это соответствует действительности?
Wisky
1. Вот так написано у 3ware по поводу кэша:
Write cache is a combination of the physical hard drives? write cache as well
as the controller?s memory, depending on what type of unit you are using.
Вроде бы из этого следует, что они разрешают кэш на дисках на запись, если это разрешается для массива. Но gs прав, делать это незачем. Не может быть такой провал по записи в потоке из-за запрета кэша на дисках. Я приводил результаты своего теста, так вот там все по умолчанию было, никаких манипуляций с кэшем мы не делали.
2. 3ware разрешает включать на запись без батареи (бабуина ), но предупреждает о возможных последствиях, если мне память не изменяет. В 3DM можно в любой момент посмотреть, включен ли кэш.
1. Вот так написано у 3ware по поводу кэша:
Write cache is a combination of the physical hard drives? write cache as well
as the controller?s memory, depending on what type of unit you are using.
Вроде бы из этого следует, что они разрешают кэш на дисках на запись, если это разрешается для массива. Но gs прав, делать это незачем. Не может быть такой провал по записи в потоке из-за запрета кэша на дисках. Я приводил результаты своего теста, так вот там все по умолчанию было, никаких манипуляций с кэшем мы не делали.
2. 3ware разрешает включать на запись без батареи (бабуина ), но предупреждает о возможных последствиях, если мне память не изменяет. В 3DM можно в любой момент посмотреть, включен ли кэш.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 23 гостя