Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Угу, но у меня фантазии не хватает оценить затраты на... 18.01.05 19:07 Число просмотров: 1645
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 18.01.05 19:11 Количество правок: 3
|
> Возможно, но аппаратная реализация была бы существенно
> быстрее, против гибкости замены алгоритма.
Угу, но у меня фантазии не хватает оценить затраты на разработку/производство даже 512 байтного аппарата, а стрип в РАИДах достигает нескольких килобайт. Естественно для 0 и 1 хитрой железяки не надо, рассмотрим 5 уровень, где код коррекции считать надо или восстанавливать инфу по нему. Этак получается секторок с каждого диска надо в четырехкилобитные регистры закатать. Потом все просто - обработка за несколько тактов, подаются сигналы на четырехкилобитный исключающийИЛИ элемент, далее на хитрую матрицу из восьми тысяч элементов И-НЕ. Представляем шинки на плате по четыре тысячи в ряд или микруху в восемью тысячами ножек!!!
Быстрее - наверняка, но зачем все это делать за одну наносекунду? Может и 16 выше крыши хватит. Не только гибкость, что приятно, но и функциональность, экономическая выгодность.
> Не думаю, что процессор RAID контроллера использует
> многопоточность - это не совсем эффективно для контроллера,
> да и наверное ни к чему. Хотя как знать...
Только старые СимбосЛоджики-810 и АХА-416 могли очереди не отрабатывать - зачем какому-нибудь сканеру или стримеру многопоточность. В современных - от 16 и более тэгов поддерживается, за что скайзя и выигрывает перед ИДЕ. В контроллере за несколько сотен долларов (цена приличного настольного писюка) вполне вероятно многопоточность есть. В ИДЕшниках, которые только уровни 0 и 1 поддерживают наверняка нет.
> Ты считаешь только скорость работы с памятью или все же
> скорость выполнения алгоритма вычисления над определенным
> блоком данных?
Ну если в массиве несколько дисков, то скорость обсчета во столько же раз упадет. Все равно ее за глаза хватает - обсчет не займет больше времени, чем считывание. В конце концов можно двухканальных контроллер памяти поставить.
Что-то мы все о скорости, как будто РАИД контроллеры ставят для этого. Расшифруем мнемонику и вспомним о том, что эти контроллеры ставят в серваки для повышения отказоустойчивости дисковой системы, а скорость - это побочный приятный эффект.
> Просто меня смущает твое утверждение, что RAID5 по
> чтению/записи быстрее чем RAID1.
> Никак не могу в это поверить. :)
5 это фактически 0 при количистве дисков стремящемся к бесконечности, но с избыточностью. Мало того, по чтению 1 будет равен 5, поскольку все диски будут нагружены чтением равномерно (к стати 1 будет заведомо быстрее 4). По записи 1 будет тормознее, поскольку на единицу записи полезной информации на диски будет писаться больше. И дело тут не в расчетах кодов восстановления а в факте их записи.
> Ну незнаю... APC вроде бы качественный брэнд...
> А какие сейчас упсы лучшие? Ну или нормальные?
АРС - классные, если не брак и не подделка. Еще уважаю РСМ.
Из двух классов ОНЛАЙН и ОФЛАЙН, первые действительно защищают, вторые можно использовать на случай провала напряжения чтоб без света на сидеть :).
ИБП двойного преобразования - идеал.
Вполне достаточно наличия фильтра ВЧ, наличия разрядника (защита от резкого перенапряжения) и наличия AVR (Automatic Voltage Regulator).
> З.Ы. Может не будем на Вы? ;)
Согласен, уже давно пора.
> Думаю, мы пришли к некоторому консенсусу. Как сам думаешь?
Лады, буду новый сервак ставить - все на РАИД5 и оставлю 1/5 емкости на другие виды для экспериментов. На основном массиве два раздела - небольшой для системы, все остальное - под рабочую инфу.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
