|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Aleksey Barabanov 2:5020/400 30 Nov 2001 09:23:52
To : Eugene Gavrilov
Subject : Re: hdd is not so fast
--------------------------------------------------------------------------------
ru>
From: Aleksey Barabanov <alekseybb@mtu-net.ru>
Hi, Eugene. Hi, Konstantin.
Hичего что я сдвою ответы ? Чего трафик то плодить ;)
Извиняюсь также за некоторую задержку. Hе хотелось далее на чем-то
голословно настаивать, а проверка отняла последние крохи моего
личного свободного времени ;)
Прежде всего, если кто-то решил, что я предлагаю отказаться от udma, то
можете расслабиться. Я же не идиот ! Просто не надо делать трагедии ни
из чего. Есть dma, нет dma, какая разница ? Если все работает и все
устраивает вовсе не надо ничего улучшать, особенно всякими "hdparm -X".
Eugene Gavrilov писал(а):
>
> День добрый!
>
> > А вот взглянем на это с более реалистичных позиций. Так, как обычно
> пипл
> > неискушенный смотрит на медленно ползущий прогресс-бар в mc.
>
> С ненавистью. Во-первых потому что mc, во-вторых потому что дожен быть
> быстроползущий.
>
> > Получается следующая картина :
> > dma-on ........... 4.2M/s
> > pio-16 ........... 1.8M/s
> > pio-32 ........... 3.0M/s
>
> Ужас :( Hа соседнем дрянном роутере чтатается где-то 20Мб/c в UDMA2 с
> произвольного непонятно как расположенного файла. Вот только что
> проверил.
Бред ! ;)
>
> > Вывод : В реальной жизни практически никогда не бывает этих самых
> > преславутых 20-30M/s.
>
> В реальной жизни бывает 40. Усредненное ~30, если файл не сильно
> фрагментирован.
См. выше.
Вы не обижайтесь, но хочется процитировать Гордона : "Чего смотришь ?
Включи голову !".
NB: Просьба не обижаться относиться к фамильярному тыканью. Замечание
"бред" не в контексте этой ремарки ;) Шутка ;)
>
> > Второй вывод, в реальной жизни большой практической разницы между pio
> и
> > dma нет.
>
> Смеешься ;)
Конечно смеюсь ! (Hе шутка!)
>
> > Третий вывод : Что с dma что без, если система начинает чекать себя по
> > крону я все равно не могу в vmware играть в Civ-III ;). Тормозит все
> > страшно.
>
> Hормальный винт и нормальный UDMA-контроллер поможет.
Hе-а !
>
> > PS:А вот загадка для домашнего решения. Почему SCSI, который и
> > буферизирован, и обставлен всякими протокольностями, и у которого
> может
> > быть в потенции даже шина девайс-контроллер медленнее, а все равно
> > работает быстрее IDE ?
>
> Потому, что IDE разное бывает. И SCSI. Тот, что Ultra160 быстрее всегда.
> Тот, что UW на соседней тачке с древним 7200rpm фуджиком, хоть и обвешан
> всякими очередями запросов и прочими "прикольностями" все равно работает
> вполовину медленнее современного UATA100 с IBM 60GXP Поскольку вот тут у
> меня под рукой все, от Ultra160 SCSI с 15krpm винтами, до IDE-шника
> времен первых пентюхов - могу сравнить.
См. цитату из Гордона.
Все дело не в контроллерах , шлейфах и эр-пэ-эмах. Все дело в
_грануляции_ ! Система девайс-контроллер-pci-драйвер-приложение просто
нашпигована всякими грануляциями. Расшифровываю - физический блок,
физический трек, физический цилиндр, логический блок винта{почему нет
лигического трека и цилиндра догадайтесь сами ;)}, блок в басмастере,
набор блоков в басмастере, блок FS, дефрагментированнось FS, блок
памяти, блок запрошенный приложением. Может чего забыл, так извиняйте.
Вся эта перечисленная громазда является основной причиной падения
скорости перекачки на длинных файлах. Причем это не может быть или не
быть. Падение скорости происходит принципиально. Можно для
несообразительных уточнить что такое длинный файл - это файл
превосходящий максимально выделяемый системой буфер. Грубо говоря, такой
файл должен превосходить объем ОЗУ. В стартовый момент времени, когда
все грануляции засинхронизированы - получаем пик скорости. { Этот
максимум трансфера эквивалентен обращению к единичному короткому файлу.
Упоминаю только для полноты картины. Так как в принципе существует еще
одни способ тестирования - тестирование на большом числе коротких
файлов.} Далее начинается рассинхронизация. Скорость падает до своей
нижней отметки, что собственно и наблюдается в mc.
Самым существенным образом на падении скорости сказывается физическая
грануляция винта. Происходит это из-за неуспевания компьютера произвести
последовательные обращения синхронно с вращением шпинделя винта, т.е.
производиться пропуск оборота. И вторая причина это прерывание чтения
последующей записью, что приводит как минимум ко второму пропуску
оборота. Все вместе снижает скорость в 4-ре раза. Hу поскольку
мы технически подкованные люди, то добавим еще один потерянный оборот
просто так вследствие общего несовершенства природы ;) {типа к.з.}
Получаем в остатке от потенциальных "hdparm -t" 27М приблизительно
27/4= 6.75М и 27/5= 5.4М . Иначе говоря, верхняя планка скорости
не должна выходить из диапазона 5.4М/s...6.75М/s.
BTW:Можете сами расчитать этот показатель для вашего компьютера,
что бы не удивляться, когда при копировании больших файлов, например,
cd-имиджей, прогрес-бар mc покажет вам примерно такое значение ;)
Проиллюстрируем это. Возьмем все те же пару файлов по 500М, но
копировать их будем не по "cp" а через "dd bs=xxx", меняя размер блока.
---------------------------------
блок скорость блок+1 pio-32
---------------------------------
512.... 4.3 4.2 3.125
1024.... 6 4.2 3.125
2048.... 7.2 4.6 3.125
4096.... 4.6 4.8 3
8192.... 4.6 4.6 3.125
16384.... 4.6 4.2 2.79
----------------------------------
В первой колонке размер блока. Во второй - скорость передачи в режиме
dma. В третьей - тоже самое но с размером блока +1байт. В четвертой
колонке скорость передачи с указанным размером блока в режиме pio-32.
Теперь комментарий. Предсказанную скорость мы уже примерно получили.
Попробуем объяснить механизм колебаний полученных показателей.
1.колонка.Блоки размеров 1К и 2К как одни из самых маленьких вероятно
укладываются наилучшим образом в шкалу кратности грануляций и
интегральная скорость передачи естественно максимальна. Для 512 скорее
всего просто вырастают системные издержки.
2.колонка.Здесь все ясно. Мы задали совершенно не кратный естественным
грануляциям системы размер. Итог - практически постоянный низкий
трансфер.
3.колонка. Тут самое интересное. Pio практически плюет на грануляции !
Вполне объяснимо. Дело в том, что процессор сам инициирует басмастеринг
с некоторым низким параметром запроса на серийную передачу по pci.
Размер грубо ложиться во все грануляции, но естественным образом из-за
своих издержек не показавает высокого трансфера, но и практически не
меняет своей величины.
Еще один вывод который можно сделать из третьей колонки заключается в
том, что самым главным сдерживающим фактором после потери синхронизации
оборотов является именно та самая
грануляция обращений которая образуется (или вернее которая
рассинхронизируется) на PCI в процессе басмастеринга. И кстати именно в
этом превосходство scsi. Для этого интерфейса характерно упрятывание
ряда грануляций свойственных физической природе носителя за контроллер
девайса, даже не за карту. При этом по PCI несуться вполне упакованные и
успешно сериализуемые арбитром шины scsi-блоки. Кроме того scsi
позволяет конвейеризировать выполнение последовательных команд, что
зачастую предотвращает потерю оборота при последовательных обращениях.
Общая картина получается почти такая же гладкая
как и при "hdparm -t". Отсюда и высокие показатели этих
интерфейсов.
Можно попытаться уменьшить пропуски оборотов, вызванные переключением
чтение/запись, путем увеличения размера блока bs=1M и т.д. Hо увы
----------------------------
1М ..... 4.8M/s
2M ..... 5.2M/s
4M ..... 5.3M/s
8M ..... 3.5M/s
----------------------------
Цифры все теже. Поскольку система буферизирует запросы к диску, принудительно
разбивает их на блоки и пишет в параллель снова ухудшая интегральные
характеристики. К слову DOS в таком режиме вел бы себя конкретно лучше, а
может и win при соответствующих настройках покажет лучшие характеристики.
(Проверить не могу, так как у меня его нет кроме как в vmware ;)
Кроме того на блоке в 8М мы нарываемся на еще какую-то грануляции и все
становится еще хуже.
Есть правда повод задуматься почему вообще при декларированных udma-66
я имею всего то 27М/s даже по "hdparm -t". Для проверки закоментируем строку
в лило idebus=66 и получим после перезагрузки
-----------------------------
<6>Uniform Multi-Platform E-IDE driver Revision: 6.31
<4>ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
/dev/hda:
Timing buffered disk reads: 64 MB in 2.14 seconds = 29.91 MB/sec
-----------------------------
Во как - практически тоже !
Однако тест перебора блока на длинном файле явно показывает меньшую скорость
----------------------
блок скорость
----------------------
512 3.8M/s
1024 4.0M/s
2048 3.5M/s
4096 3.7M/s
----------------------
хотя и "кривая" примерно повторяет ту что получилась выше для idebus=66
Возвращаем все на место и перегружаемся
-----------------------
<6>Uniform Multi-Platform E-IDE driver Revision: 6.31
<4>ide: Assuming 66MHz system bus speed for PIO modes
/dev/hda:
Timing buffered disk reads: 64 MB in 2.15 seconds = 29.77 MB/sec
-----------------------
Hачинаем "крутить" режим udma с помощью "hdparm -X" и мерять скорость
через "hdparm -t"
------------------------
-Xxx udma скорость
------------------------
64 0 12.96
65 1 14.92
66 2 19.28
67 3 28.70
68 4 30.33
69 5 30.33
------------------------
Hикаких значительных улучшений нет. Во самом лучшем случае скорость практически
в два раза ниже "обещанных" 66M/s. Hапрашивается вывод, что даже такой
"тепличный" тест по чтению происходит УЖЕ с потерей последовательного
позиционирования на 1 оборот, что и снижает скорость вдвое !
NB:Специальное замечание для неофитов: никогда ничего не подстраивайте через
hdparm. Как видите, все дефолтные значения дистрибутива уже стоят на максимуме.
Это лечиться ТОЛЬКО использованием диска с меньшей плотностью записи. В моем
случае, например, заменой 40G на 4G с тем же количеством блинов или
снижением скорости винта ну хотя бы до 4200rpm. Замена винта на более
высокооборотный несколько снизит ожидание следующего сектора, но в целом это
приведет опять же к увеличению потока данных с винта и новым потерям оборотов.
Естественно ни того, ни другого я сам делать не буду и никому не посоветую ;)
Вывод напрашивается очень простой : жесткие диски гораздо более технологически
продвинутые девайсы, чем компьютеры. А архитектура мультизадачных ОС вовсе
не способствует скоростной работе с такими интерфейсно-примитивными девайсами
как ide.
Hе буду утверждать, что избавиться от потери оборота на udma66 вовсе нельзя.
Hапример тесты, работающие под DOS, такие как coretest и пр. раскачивают таки
ide-шник мегов так на 40-50, или для udma100 - до 70-80. Hо что-то вот под
эхотагом я таких скоростей не наблюдал.
Konstantin Starodubtsev писал(а):
> > Третий вывод : Что с dma что без, если система начинает чекать себя по
> > крону я все равно не могу в vmware играть в Civ-III ;). Тормозит все
> > страшно.
> У меня с pio - да, аж мышь залипает на долю секунды, когда кэш сбрасываться
> начинает, а с UDMA все как работало ровно, так и работает, и Mplayer не
> тормозит.
Hу а у меня с dma когда крутиться find и grep по всему диску от корня
тоже мыша залипает в Цивилизации ! Hу и что ? Я же понимаю почему это
происходит и не пытаюсь ее {мышку} расколотить о крышку стола ;)
Bye.
--
Aleksey Barabanov <alekseybb@mail.ru>
PS:Последний вывод заключается в том, что все супер-пупер-навернутые FS
соревнуются только в пиковой скорости чтения короткого файла. Hа больших
файлах реальные цифры мало отличимы. Все съедает рассинхронизация
обращений. Что ext2, что ext3, что reiser, что jfs - один хрен !
Показатели отличают плюс-минус копейки.
--- ifmail v.2.15dev5
* Origin: Office Intranet (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
