Page 1 of 6 123 ... LastLast
Results 1 to 15 of 88

Thread: Тестирование скорости чтения/записи USB-HDD.

  1. #1

    Exclamation Тестирование скорости чтения/записи USB-HDD.

    Предыстория.
    После приобретения WL-500gP, при последующих экспериментах я заметил, что скорость чтения/записи на USB-Flash и USB-HDD сильно отличается от скорости передачи файлов, скажем, по FTP.
    Я решил провести несколько экспериментов, измеряя в различных условиях скорости чтения/записи файлов на диск.

    Оборудование.
    Для тестирования я, помимо самого маршрутизатора Asus WL-500gP с прошивкой 1.9.2.7-8, взял устройство Rapsody RSH-250 - мультимедиа-проигрыватель, и, разумеется, внешний USB-диск. Выбор на последний пал не потому, разумеется, что он умеет проигрывать массу мультимедиа-файлы, а потому, что у него (в отличие от других моих USB-дисков) есть свой внешний блок питания. Кроме того, в нем установлен довольно быстрый 120-гигабайтный диск Hitachi, разбитый на два раздела - ~ 19 и 97 GB (помним о "меньшем" размере дисков из-за неверного и отличного от стандарта СИ общепринятого "значения" Терабайта.), отформатированные в FAT32.
    Запись производилась на первый раздел.
    Устройства соединялись надежным коротким USB 2.0 кабелем.

    Тестирование.
    После подключения внешнего диска они были успешно смонтированы как
    /tmp/harddisk и /tmp/harddisk/part1.
    Тестирование внутренней скорости записи производилось следующими командами:
    Code:
    date; dd if=/dev/zero of=/tmp/harddisk/testfile.bin bs=64k count=8192 ; sync ; date
    Т.к. реализация BusyBox команды dd не показывает итоговую статистику, пришлось прибегнуть к иному методу.
    Для измерения времени использовались вызовы `date`, т.к. команда time разделяет время на пользовательское и системное, и передавать ей в качестве аргумента цепочку команд некорректно.
    Команда sync нужна, чтобы сбросить буферы и исключить влияние кэширования (которое, к сожалению, не очень эффективно на стандартной памяти из-за малого размера буферов).
    Размер блока чтения/записи (bs=64k) в каждой серии экспериментов менялся для определения его влияния на итоговые результаты, число блоков (count=) устанавливалось так, чтобы итоговый файл имел размер 512Mb.
    Получается примерно это:
    Code:
    date; dd if=/dev/zero of=/tmp/harddisk/testfile.bin bs=64k count=8192 ; sync ; date
    Thu Jan  1 03:06:54 MSK 1970
    8192+0 records in
    8192+0 records out
    Thu Jan  1 03:08:18 MSK 1970
    Время не устанавливалось, т.к. устройство было включено во "внутреннюю" сеть, не имеющую выхода в Интернет. Между попытками (всего их было 3 в каждой серии) файл удалялся, устройство перегружалось, делалась пауза для завершения стартовых процессов.

    Табл. 1. Итог тестирования внутренней скорости записи на диск (через дробь попытки):
    Code:
    bs         Время,с          Скорость, МБ/сек
    256          90/90/91            5825.42 / 5825.42 / 5761.41
    16k          89/88/90            5890.88 / 5957.82 / 5825.42
    64k          84/80/81            6241.52 / 6553.60 / 6472.69
    256k         82/80/81            6393.76 / 6553.60 / 6472.69
    1M           80/80/79            6553.60 / 6553.60 / 6636.56
    Тестирование для bs > 1M не делалось, т.к. размер буферов для кэширования операций ввода/вывода в системе мал. Отдельные значения, сильно отличавшиеся от других в серии, не учитывались как ошибочные. Не забегая далеко вперед, можно заметить, что, начиная с некоторого значения, дальнейшее увеличение размера блока к ощутимому ускорению не приводит.

    После этого я протестировал скорость чтения с диска. Для чтения использовался ненулевой файл размером в 512МБ, полученный командой
    Code:
    dd if=/dev/urandom of=/tmp/harddisk/testfile.bin bs=1M count=512
    К слову, эта операция заняла более 29 минут (из-за генерации большого числа псевдослучайных чисел). Для сравнения (если тут можно сравнивать ), та же операция на "Большом Брате" (Celeron(R) CPU 2.40GHz) заняла менее 3.5 минут.

    Чтение производилось командой:

    Тут уже не нужно вызывать sync (т.к. при записи в /dev/null кэширования нет), равно как и не нужно рассчитывать число пересылаемых блоков.

    Табл. 2. Итог тестирования внутренней скорости чтения данных (через дробь попытки):
    Code:
    bs          Время,с         Скорость, МБ/сек
    256           69/69/69           7598.38 / 7598.38 / 7598.38
    16k           61/62/61           8594.88 / 8456.26 / 8594.88
    64k           60/60/61           8738.13 / 8738.13 / 8594.88
    256k          60/60/60		 8738.13 / 8738.13 / 8738.13
    1M            62/62/64           8456.26 / 8456.26 / 8192.00
    Как и ожидалось, скорость чтения выше скорости записи, и с некоторой величины блока дальнейшего более-менее значительного прироста скорости не наблюдается, более того, при bs=1M видим даже некоторое ухудшение.

    Следующим шагом стало тестирование скорости чтения того же файла по FTP. Тут уже пришлось довольствоваться простым замером средней скорости за передачу. Для этого использовался wget:
    Code:
    wget -nd -c ftp://192.168.1.1/testfile.bin
    Для LAN-интерфейса, включенного напрямую в компьютер, средняя скорость загрузки по FTP составила 3.26МБ/с.
    То же. но через WLAN-интерфейс с WPA-шифрованием - 2.02МБ/с.
    При этом, load average был больше 1, stupid-ftpd использовал до 85% времени CPU.

    Для NFS скорость чтения чуть выше: для LAN-соединения 4,7 МБ/с, для WLAN (все с тем же WPA) - 2.7МБ/с.
    Тестирование с dd и с изменением размера блока не делалось, т.к. скорость, в основном, ограничена другими факторами - протоколом, сетевым стеком, скоростью шифрования.

    Выводы.
    Мне приходилось читать, что у этого устройства низкая скорость чтения/записи обусловлена особенностями "железной" реализации USB-порта.
    Однако, первые же впечатления при работе с устройством дали почвы сомнениям. И результаты тестирования подтверждают: потенциала собственно USB в этом устройстве достаточно, однако, все упирается в общую производительность - ее недостаточно для того, чтобы сделать это устройство полноценным файл-сервером. Пересылки из user-space в kernel-space, файловые операции, шифрование, сетевой стек - все это требует ресурсов.

    И запас, как мне кажется, есть. Это не только аппаратная модернизация (увеличение памяти), но и оптимизация ПО для этого устройства, и, возможно, переход к ядру 2.6. Так же следует учитывать, что максимальная скорость при работе с USB-носителями достигается для проводного соединения, и работа с FAT32 в Linux значительно медленнее, чем с ext2/ext3 - и это сильно ощущается даже на "взрослых" компьютерах при работе с USB-HDD.

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


    Что дальше.
    А дальше - изучать, пробовать и оптимизировать.

    (c) 2007 ABATAPA

  2. #2
    Так на цифры посмотришь и подумаешь, откуда 5Мбайт при записи. У меня больше чем 1,5Mb при чтении через Самбу (беспроводное соединение) не получалось. По проводу на 20% получше, но в целом конечно ситуация удручающая. А с другой стороны, видео он сам качает и смотреть с него без проблем можно, так что это не является сильно ограничивающим фактором.

  3. #3
    Join Date
    Dec 2003
    Location
    Russian Federation
    Posts
    8,355
    для LAN-соединения 4,7 МБ/с
    Наверное 3,7 всё же.

  4. #4
    Quote Originally Posted by Oleg View Post
    Наверное 3,7 всё же.
    Нет. Все данные, что я написАл, я проверял лично, и не один раз. Все верно.

  5. #5
    День добрый !

    Вчера подключил диск от асуса к большому брату, чтобы быстро перелить большой объем скаченных файлов на винт ББ.
    Был сильно удивлен, что файлы, скаченные с торрентов (с использованием transmission) копируются даже в null (пробовал из виндов через драйвер ext2 и из-под linux (gparted live cd)) с скоростью всего 3.7Мбайт/c ! При этом этом файлы залитые через самбу скачанные по ftp, wget и т.п копируются с скоростью под 40Мбайт/с с этого же диска.
    Если это связано с фрагментацией файлов - есть ли какой-нибудь фоновый и легкий дефрагментатор, который можно было бы гонять на маршрутизаторе при низкой нагрузке ?

    Женя

  6. #6
    Quote Originally Posted by zheka_ppp View Post
    При этом этом файлы залитые через самбу скачанные по ftp, wget и т.п копируются с скоростью под 40Мбайт/с с этого же диска.
    Если это связано с фрагментацией файлов - есть ли какой-нибудь фоновый и легкий дефрагментатор, который можно было бы гонять на маршрутизаторе при низкой нагрузке ?
    ext2 в общих случаях не нуждается в дефрагментации.
    Не знаю, умеет ли transmission предварительно выделять (preallocate) место для всего размера файла, если нет, то в условиях малого места фрагментация могла иметь место, но чтобы так падала скорость.... Может, там просто большое количество мелких файлов?

  7. #7
    Quote Originally Posted by ABATAPA View Post
    ext2 в общих случаях не нуждается в дефрагментации.
    Не знаю, умеет ли transmission предварительно выделять (preallocate) место для всего размера файла, если нет, то в условиях малого места фрагментация могла иметь место, но чтобы так падала скорость.... Может, там просто большое количество мелких файлов?
    Нет, там один файлик 1.3Gb
    Диск 500Gb, занят на 50%. Почитал про ext2/ext3 - действительно фрагментации там быть не должно, дефрагментаторов для ext3 не сущетсвует в природе
    На счет preallocate - вроде не было такого ключика, пойду на форум разработчиков...

    Женя

  8. #8
    Join Date
    Mar 2007
    Location
    Russia, Ryazan
    Posts
    696
    Quote Originally Posted by zheka_ppp View Post
    Почитал про ext2/ext3 - действительно фрагментации там быть не должно, дефрагментаторов для ext3 не сущетсвует в природе
    Фрагментации быть не должно при наличии двух условий:
    1) Приложение говорит системе: "Щас создам файл размером 8736548 байт."
    2) Система быстренько ищет на диске свободное непрерывное место не менее указанного размера, и выделяет его под создаваемый файл. Приложение записывает/дописывает файл уже именно туда, куда указала система.
    Если же приложение говорит:"Создаю файл, а какого он будет размера - хз." (в очень большом количестве случаев действительно невозможно заранее определить конечный размер файла) и/или на диске нет непрерывного свободного пространства требуемого размера (диск заполнен процентов на 80 и более), то неизбежно произойдет фрагментация файла.
    И в ext2/ext3 и в NTFS этот механизм действует абсолютно одинаково, и они одинаково фрагментируются. И отсутствие дефрагментаторов под ext2/3 ни коим образом не говорит о том, что эта файловая система в дефрагментации совершенно не нуждается.

  9. #9
    Quote Originally Posted by Reyter View Post
    то неизбежно произойдет фрагментация файла.
    Нет, не неизбежно. Так как, на самом деле, НЕЛЬЗЯ указать системе размер вновь создаваемого файла. Нет такой возможности. И не только в Linux.
    И механизм работы ext2/3 (и даже 4) совсем иной, и непрерывность достигается иначе - в ext2/3 для файла выделяются области как можно ближе друг к другу, даже если нет возможности разместить их непрерывно.
    Читайте первоисточники.

    Quote Originally Posted by Reyter View Post
    И в ext2/ext3 и в NTFS этот механизм действует абсолютно одинаково, и они одинаково фрагментируются.
    Ну, незначительные различия есть, но существенного влияния они не оказывают.

    Quote Originally Posted by Reyter View Post
    И отсутствие дефрагментаторов под ext2/3 ни коим образом не говорит о том, что эта файловая система в дефрагментации совершенно не нуждается.
    Почему это - отсутствие?
    Вспомним e2compr, e2defrag, Shake, и т.д...
    Другое дело - они не нужны:
    Code:
    # e2fsck -vf  /dev/sda2 (раздел 147G)
    ...
    38147838 blocks used (97.64%)
    ..
      115771 regular files
       27986 directories
    # ./cdavl /dev/sda2 | head -n 12
    fstype ext3
    mount unmount
    f-per 0.04%
    blocks 39070080
    sblocks 628727
    fblocks 37486308
    frags 18414
    sfrags 117
    cfiles 140059
    ffiles 3707
    depth 10

    147G, заполненные на 97.64%, 115771 файлов, 27986 каталогов, процент фрагментации - 0.04% (использовалась старенькая, но актуальная davtools .

    Никто не говорит, что ext2/3/4 не подвержены фрагментации - но и делать из этого "страшилку" не надо.

    Делайте выводы, "учите матчасть"(с)

    И вообще, давайте не уклоняться от темы. А то как обычно - все сразу тут.

  10. #10

    Ограничение скорости HDD и все остальное

    Проблема вобщем-то такая - имеется винчестер самуснг 160Гиб, в коробке трансценд, запитаной от роутера Wl500gp по двухвостовому юсб. Файловая табличка - ехт3. Стуков, сбоев нет. Торенты качает исправно (проверял до 10 Гиб), эти же торренты сбрасывал на комп по сети, опять же тьфу, тьфу, тьфу....
    НО Скорость скачивания по сети - 2 мегабайта/сек, ладно, но если коробку снимаем и подключаем к обыному компу под винхп (драйвер на Ext2 Volume Manger в качестве службы), то скорость точно такая же. Подскажите, пжлста, где собака зарыта? Как поднять скорость хотя бы при подключении коробки не по сети, а напрямую. Хотя очень не хотелось бы дергать ее туда-сюда....

  11. #11
    Join Date
    Feb 2008
    Location
    Moscow, Tver
    Posts
    3,953
    Quote Originally Posted by fabii View Post
    Проблема вобщем-то такая - имеется винчестер самуснг 160Гиб, в коробке трансценд, запитаной от роутера Wl500gp по двухвостовому юсб. Файловая табличка - ехт3. Стуков, сбоев нет. Торенты качает исправно (проверял до 10 Гиб), эти же торренты сбрасывал на комп по сети, опять же тьфу, тьфу, тьфу....
    НО Скорость скачивания по сети - 2 мегабайта/сек, ладно, но если коробку снимаем и подключаем к обыному компу под винхп (драйвер на Ext2 Volume Manger в качестве службы), то скорость точно такая же. Подскажите, пжлста, где собака зарыта? Как поднять скорость хотя бы при подключении коробки не по сети, а напрямую. Хотя очень не хотелось бы дергать ее туда-сюда....
    По поводу скорости работы диска на роутере.
    Напрямую на компе плохая скорость, значит драйвер больше не тянет. Вопросы - к автору драйвера.

  12. #12
    А по другим портам коробка не подключается?

    Я торренты с диска сливаю через FireWire. Гигабайт секунд за 20 сливается.

  13. #13
    Quote Originally Posted by fabii View Post
    Как поднять скорость хотя бы при подключении коробки не по сети, а напрямую. Хотя очень не хотелось бы дергать ее туда-сюда....
    Используйте плагин http://wincmd.ru/plugring/ext2fsreiser.html для Total Commander - он позволяет только _читать_, но он быстр.
    © 2008-2013 ABATAPA WL-500gP/128M / Asus RT-N16 / USB Flash / VLAN / PPPoE / VoIP / nShaper / NAS: iStor is607, Sarotech NAS-20, QNap 109 Pro / NFS / Принтер / etc

  14. #14
    итак, снес старый драйвер полностью с перезагрузкой машины. поставил плагин к ТС, качает также - 2-3 МБ/сек ? Видимо причина не в драйвере. пробуем другую коробку Lacie (NTFS) с одним юсб (данные и питание по нему), подключаем в тот же порт на компьютере, 25-30 МБ/сек. Хочется хотябы половины......

    Дополнение: эти файлы созданы transmission 1.22
    Last edited by fabii; 12-07-2008 at 11:54.

  15. #15
    Join Date
    Feb 2008
    Location
    Moscow, Tver
    Posts
    3,953
    Quote Originally Posted by fabii View Post
    итак, снес старый драйвер полностью с перезагрузкой машины. поставил плагин к ТС, качает также - 2-3 МБ/сек ? Видимо причина не в драйвере. пробуем другую коробку Lacie (NTFS) с одним юсб (данные и питание по нему), подключаем в тот же порт на компьютере, 25-30 МБ/сек. Хочется хотябы половины......

    Дополнение: эти файлы созданы transmission 1.22
    Драйвер к поддержке файловой системы ext3, а не к коробке.
    NTFS же выдает много, а ext3 тормозит получается в ХР.
    попробуй винты махнуть в коробках и померять скорость, может реально коробка не поддерживает правильно Линуксовые ФС.

Page 1 of 6 123 ... LastLast

Similar Threads

  1. Изменение скорости WAN & LAN интерфейса роутера
    By MAV in forum Russian Discussion - РУССКИЙ (RU)
    Replies: 204
    Last Post: 16-03-2014, 09:08
  2. Разница в скорости через роутер и напрямую
    By Hotmax in forum Russian Discussion - РУССКИЙ (RU)
    Replies: 245
    Last Post: 03-02-2013, 14:00
  3. Владельцам RT-N13U: увеличение скорости PPTP
    By theMIROn in forum Russian Discussion - РУССКИЙ (RU)
    Replies: 104
    Last Post: 17-01-2013, 13:31
  4. Скрипт чтения СМС на 3G модеме (ussd)
    By dlukanidin in forum Russian Discussion - РУССКИЙ (RU)
    Replies: 113
    Last Post: 07-01-2013, 15:17

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •