Отправляет email-рассылки с помощью сервиса Sendsay

ATA-100 и Linux

Здравствуйте!

Меня немного смущает скорость работы моего нового винчестера Seagate blah
- 250Gb/7200rpm ( 10-20 мб/сек )

Capabilities:
LBA, IORDY(can be disabled)
Standby timer values: spec'd by Standard, no device specific
minimum R/W multiple sector transfer: Max = 16 Current = 16
Recommended acoustic management value: 208, current value: 0
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=240ns IORDY flow control=120ns

В спецификации указано, что он поддерживает ATA-100, однако в реале
скорость как уже писалось выше 20мб/сек при записи не поднимается.

У кого какие скорости ( не синтетические ) для сравнения?

Ответить   Sat, 16 Dec 2006 08:13:44 +0300 (#620981)

 

Ответы:

Ilia N Ternovich:

1) Скорость передачи данных по интерфейсу, через который подключен
винчестер, и скорость передачи данных самого винчестера - две большие
разницы. SATA II позволяет передавать до 300 Мб/с и я бы хотел посмотреть
на винчестер, который сможет выдать такую скорость чтения с блинов (из
кэша возможно, но кэша-то мало...)
2) Скорость чтения и скорость записи - две большие разницы. `hdparm -t`
показывает именно скорость чтения. Скорость записи, как правило, ниже.
3) Чтение и запись бывают разными. Бывает скорость линейного чтения/записи,
когда не используется никакая ФС. Для чтения это именно то, что делает
`hdparm -t`. Бывает же скорость чтения/записи файлов на ФС,
расположившейся на винчестере. Бывает и скорость копирования файлов с
одной ФС на другую, причем можно копировать огромное количество мелких
файлов, а можно один на несколько Гб. Все это совершенно разные вещи.
4) А не висит ли пара винчестеров на одном канале и копируем с одного на
другой?

В общем, для начала необходимо определиться с тем, откуда, собственно, взята
цифра в 20 Мб/с. Далее полезно потестировать чтение/запись с помощью dd, в
стиле (если, конечно, винчестер еще не забит бесценными данными):

$ dd if=/dev/zero of=/dev/hdd bs=1048576 count=500
$ dd if=/dev/hdd of=/dev/null bs=1048576 count=500

Линейная запись/чтение с винчестера. Если данные забиты (а, судя по всему,
так и есть), можно читать/писать в файл, цифры должны быть похожие, но чуть
меньшие (впрочем, бывает всякое, сильно фрагментированная ФС оторвется по
полной):

$ dd if=/dev/zero of=/mnt/hdd bs=1048576 count=500
$ dd if=/mnt/hdd of=/dev/null bs=1048576 count=500

Копирование файлов - уже совсем другая тема.

Ответить   Roman I Khimov Sat, 16 Dec 2006 12:07:29 +0300 (#621054)

 

On Sat, 16 Dec 2006 12:07:29 +0300 Roman I Khimov <rik@o*****.info> wrote:

Поясните эту фразу, пожалуйста.

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 29345; Возраст листа: 1246; Участников: 1408
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/623053

Ответить   Strong Thu, 21 Dec 2006 00:24:50 +0700 (#623053)

 

Здравствуйте, Strong.

Вы писали 20 декабря 2006 г., 20:24:50:

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

Ответить   Fri, 22 Dec 2006 13:11:00 +0300 (#623073)

 

В сообщении от 22 декабря 2006 13:11 timothy silent
написал(a):

<rik@o*****.info> wrote:

Ещё один теоретик.

Это правильно только если система работает только с одним
файлом на каждом физическом диске (а для IDE вообще на
контроллере), и при этом I/O кэш маленький.

Для LINUX ни одно из этих условий не выполняется практически
никогда.

Да и добиться заметного фрагментирования тоже весьма
непросто.

Ответить   "Sergey B. Khvatov" Fri, 22 Dec 2006 13:44:15 +0300 (#623087)

 

Здравствуйте, Sergey.

Вы писали 22 декабря 2006 г., 13:44:15:

Ага. Очень смешно. Я отвечал на просьбу пояснить, а не оценить
реальную вероятность. Рад, что Вы смогли продемонстрировать свой
высокий уровень.

Ответить   Fri, 22 Dec 2006 14:17:58 +0300 (#623107)

 

Sergey B. Khvatov:

Неправильно. Откуда взяты такие условия непонятно. I/O кэш серьезно помогает
только в случае чтения (поскольку по умолчанию он радостно занимает всю
доступную оперативную память), на запись он без дополнительных настроек
всегда довольно мал. Тестирование такого рода предполагает, что
читаемый/записываемый файл значительно больше размеров кэшей.

Надо постараться. Факт. Но бывает.

Ответить   Roman I Khimov Fri, 22 Dec 2006 16:24:22 +0300 (#623140)

 

В сообщении от 22 декабря 2006 16:24 Roman I Khimov
написал(a):

Вы не заметили главного - файл может быть совсем
нефрагментированым, но вы на машине не один (даже если вам
кажется обратное) и соответственно i/o subsystem в ядре
обслуживает далеко не только вас. Даже если swap не нужен.
Про глупости конкретных интерфейсов повторять не буду.

А я даже знаю как

Но для этого надо специально стараться и я рискну утверждать
что вы не знаете как это сделать.

Ответить   "Sergey B. Khvatov" Fri, 22 Dec 2006 17:28:33 +0300 (#623158)

 

Sergey B. Khvatov:

Логично. Опять-таки, это все к методике тестирования. Естественно, что
по-нормальному такие тесты надо делать в однопользовательском режиме с
прибитыми напрочь демонами.

Ответить   Roman I Khimov Fri, 22 Dec 2006 17:45:45 +0300 (#623165)

 

Roman I Khimov пишет:

Ну и какая польза от такого теста? Поясните.

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 29376; Возраст листа: 1247; Участников: 1407
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/623519

Ответить   Sat, 23 Dec 2006 22:46:04 +0200 (#623519)

 

spider:

Здесь обсуждалось сразу много тестов, поэтому для начала стоит определиться
с тем, о каком тесте идет речь. Изначально речь шла об измерении скорости
чтения/записи на винчестер. И чтение/запись в файл в однопользовательском
режиме с прибитыми напрочь демонами на не сильно фрагментированной ФС дает
вполне адекватную оценку такой скорости. Хотя, на чтение всегда можно
почитать /dev/hd*. А вот на запись без убийства ФС - адекватный метод.

Ответить   Roman I Khimov Sun, 24 Dec 2006 00:05:02 +0300 (#623524)

 

Roman I Khimov пишет:

<<..об измерении скорости чтения/записи на винчестер. И чтение/запись в
файл в однопользовательском режиме с прибитыми напрочь демонами ..>>.
Именно об этом. Просветите, плз., в чем практическая польза таких
тестов? Что мне в практической работе даст информация о
производительности дисков в остановленной системе? У меня часто
случается, что в системе запущено полдюжины tar+bzip2 или утилиты djvu,
результаты которых тут же сбрасываются на DVD, а на этом фоне надо
активно погуглить или почитать доку файрфоксом. А так я помню только два
случая, когда моя система была загружена в однопользовательском режиме.

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 29378; Возраст листа: 1248; Участников: 1406
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/623631

Ответить   Sun, 24 Dec 2006 13:25:35 +0200 (#623631)

 

On Sun, 24 Dec 2006 13:25:35 +0200
spider <spid***@l*****.by> wrote:

Польза в том, что можно убедиться и успокоиться насчет скорости работы
своей железки. А падение реальной скорости в реальной обстановке с легкой
душой списать на большое число демонов, p2p клиенты и прочий контент :-)

Всем откликнувшимся спасибо! Тема закрыта.

Ответить   Sun, 24 Dec 2006 14:56:25 +0300 (#623641)

 

В сообщении от 16 декабря 2006 08:13 Ilia N Ternovich
написал(a):

Так скорость винчестера прежде всего определяется тем,
насколько быстро головки и запись на диске найдут друг
друга. Особенно для ATA с его синхронными операциями.

20 mb/s - нормальная скорость для 7200
Она ещё зависит от того, где записаны данные - в центре
диска скорость меньше

Да и ext3 - не самая быстрая fs - за удобство и надёжность
приходится платить.

Ответить   "Sergey B. Khvatov" Sat, 16 Dec 2006 12:41:51 +0300 (#621062)

 

На Sat, 16 Dec 2006 12:41:51 +0300
"Sergey B. Khvatov" <xbat***@t*****.ru> написал(а):

Все-таки немного побольше должно быть, у меня на сигада 120ГБ 7200рпм сата
пишет со скоростью 25-30МБ/с, на ext3 тоже, кэш на диске 2МБ, а у
товарисча поди все 8МБ.

Как впрочем и не самая медленная. :)

Ответить   Sat, 16 Dec 2006 15:13:16 +0500 (#621075)

 

В сообщении от 16 декабря 2006 13:13 Dmitry V. Balabanov
написал(a):

Переспрошу - в начале или в конце диска? Скорости
различаются почти в два раза.
И есть ли дисковые запросы от других процессов?

Кэш имеет смысл в однозадачной системе, а ух в linix даже
от системного (который всю свободную память занимает) толк
не всегда есть, а уж от ещё каких-то 8 Mb толку точно
никакого нет.

Нужно быстрее - используйте JFS или XFS. Хотя гораздо
эффективнее - отдельный привод (даже не очень быстрый) на
отдельном интерфейсе.

Ответить   "Sergey B. Khvatov" Sat, 16 Dec 2006 13:33:23 +0300 (#621082)

 

На Sat, 16 Dec 2006 13:33:23 +0300
"Sergey B. Khvatov" <xbat***@t*****.ru> написал(а):

Диск рабочий, на нем пингвин сидит. Забит на половину. Фрагментация
примерно 4%. Проводить какие-то специальные замеры мне не хочется.

Возможно, в памяти висит все, включая иксы. Надо сказать, что я просто
скопировал каталог 3500МБ на этот диск(SATA) с другого диска(IDE) в мс и
посмотрел скорость. Это вряд-ли можно назвать точным замером, но все-таки
дает представление о скорости записи. Причем о скорости в реальных
условиях, а не каких-нибудь тепличных.
hdparm -t показывает на диске 56.7 МБ/с.

Нет уж, спасибо. Лошадей не меняем. :)

Ответить   Sat, 16 Dec 2006 16:31:43 +0500 (#621099)

 

Sergey B. Khvatov пишет:

Дисковый кеш никакого отношения ни к винчестеру, ни к интерфейсу не
имеет и располагается в памяти ядра. А на диске не кеш, а буфер,
возможно на одну-две дорожки.
Что касается много/одно-задачности, то здесь не все так очевидно. По
всей видимости аппаратное переключение контекста не аннулирует кеш в
составе процессора. И если данные не переполняют кеш, то процесс
вернувшись получит свои данные в кеше без реального обращения к памяти.
Что касается кешей более низкого уровня, ими занимается операционная
система и тут вообще ничего неясно. Ну а в дисковых операциях данные
ходят мимо кешей.

-*Название листа "Linux: разрешение вопросов, перспективы и общение";
Написать в лист: mailto:comp.soft.linux.discuss-list@subscribe.ru
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.discuss/rules
Номер письма: 29290; Возраст листа: 1243; Участников: 1408
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.discuss/msg/622161

Ответить   Tue, 19 Dec 2006 17:03:55 +0200 (#622161)

 

На Tue, 19 Dec 2006 17:03:55 +0200
spider <spid***@l*****.by> написал(а):

Вот объясните мне, идиоту, в чем разница между кешем и буфером, если и то
и другое просто область памяти для временного хранения данных?

Ответить   Wed, 20 Dec 2006 04:30:36 +0500 (#622284)

 

В сообщении от 19 декабря 2006 18:03 spider написал(a):

Я рад, что вы знаете столько умных слов:-)

Когда узнаете, что они означают - поговорим ещё. А пока -
извините...

Ответить   "Sergey B. Khvatov" Wed, 20 Dec 2006 11:03:24 +0300 (#622372)