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