Предыстория.
После приобретения 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