Intro
Есть беспроводная сеть. Но скорость передачи файлов бывает падает до 700 кБ/с и ниже. Так что захотелось выяснить, в чем дело: где узкое место и кого давит жаба.
Вероятные источники проблемы:
- Интерференция
- Другой трафик
- Ноутбук или точка ASUS WL-500W: неудачаная реализация/драйверы/система
Для проверки этих гипотезы подойдет iPerf - открытый и бесплатный инструмент для тестирования пропускной способности сети. Работает под Linux и Windows (здесь), интерфейс - командная строка (отмечу, что есть еще jPerf - переписан на Java и с графическим интерфейсом).
В Debian устанавливается через:
apt-get install iperf
Запуск
Одна сторона - сервер: iperf -s
Другая сторона - клиент: iperf -c Server_IP
При этом iperf замеряет пропускную способность по TCP от клиента к серверу. Для полудуплексной беспроводной сети это и нужно, трафик идет от беспроводного клиента (ноутбук) через точку доступа к компьютеру в обычной сети.
В других случаях может быть полезной опция -d (Do a bidirectional test simultaneously).
В ходе тестов удалось посмотреть как ведет себя сеть и убедиться, что действительно в разное время пропускная способность разная.
Нормальное поведение
sk@hal:~$ iperf -i 5 -t 20 -c 192.168.0.65
------------------------------------------------------------
Client connecting to 192.168.0.65, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.0.63 port 33344 connected with 192.168.0.65 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 5.0 sec 13.2 MBytes 22.1 Mbits/sec
[ 3] 5.0-10.0 sec 12.9 MBytes 21.7 Mbits/sec
[ 3] 10.0-15.0 sec 13.2 MBytes 22.1 Mbits/sec
[ 3] 15.0-20.0 sec 13.3 MBytes 22.3 Mbits/sec
[ 3] 0.0-20.0 sec 52.5 MBytes 22.0 Mbits/sec
Как видно, при теоретическом пороге для полудуплексного 802.11g в 27 Мбит/c мы получаем приемлемое значение около 22-23 Мбит/c. Передача файла по SMB с линукс-станции на виндовую шару в такое время выдает 2 Мбайт/c = 16 Мбит/с, что кажется приемлемым, учитывая болтливость протокола SMB.
Аномальное поведение
sk@hal:~$ iperf -i 5 -t 20 -c 192.168.0.65
------------------------------------------------------------
Client connecting to 192.168.0.65, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.0.63 port 37460 connected with 192.168.0.65 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 5.0 sec 12.7 MBytes 21.3 Mbits/sec
[ 3] 5.0-10.0 sec 10.1 MBytes 16.9 Mbits/sec
[ 3] 10.0-15.0 sec 6.71 MBytes 11.3 Mbits/sec
[ 3] 15.0-20.0 sec 2.33 MBytes 3.91 Mbits/sec
[ 3] 0.0-20.5 sec 31.8 MBytes 13.0 Mbits/sec
Что-то происходит и скорость начинает падать. Вот продолжение:
[ 3] 0.0- 5.0 sec 4.71 MBytes 7.90 Mbits/sec
[ 3] 5.0-10.0 sec 5.09 MBytes 8.53 Mbits/sec
[ 3] 10.0-15.0 sec 3.92 MBytes 6.58 Mbits/sec
[ 3] 15.0-20.0 sec 6.41 MBytes 10.7 Mbits/sec
Отключение домашней сети (плоская сеть с сотней компьютеров) ситуацию не меняет.
Остаются варианты:
а) интерференция - микроволновки и т.п.
б) левый трафик в беспроводной сети: нужно при случае перевести карточку в monitor mode и посмотреть, что там бегает.
Диагностика в режиме UDP
А пока я успел перевести iperf в режим работы через UDP и пронаблюдал следующую интересную картину.
sk@hal:~$ iperf -i 5 -t 300 -c 192.168.0.65 -u -b 25m
------------------------------------------------------------
Client connecting to 192.168.0.65, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 110 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.0.63 port 35797 connected with 192.168.0.65 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 5.0 sec 9.81 MBytes 16.5 Mbits/sec
[ 3] 5.0-10.0 sec 14.7 MBytes 24.7 Mbits/sec
[ 3] 10.0-15.0 sec 6.57 MBytes 11.0 Mbits/sec
[ 3] 15.0-20.0 sec 14.9 MBytes 25.0 Mbits/sec
[ 3] 20.0-25.0 sec 14.9 MBytes 25.0 Mbits/sec
Т.е. удалось запечатлеть момент когда закончилась "яма" и скорость снова вышла на нормальный уровень.
На самом деле тестирование по UDP в случае беспроводной сети позволяет заглянуть еще дальше и точнее понять происходящее. Вот выходные данные на стороне сервера:
H:\soft\Network\iPerf, jPerf>iperf -s -i 5 -u
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 8.00 KByte (default)
------------------------------------------------------------
[1928] local 192.168.0.65 port 5001 connected with 192.168.0.63 port 35797
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[1928] 0.0- 5.0 sec 9.84 MBytes 16.5 Mbits/sec 0.602 ms 0/ 7022 (0%)
[1928] 5.0-10.0 sec 14.7 MBytes 24.7 Mbits/sec 0.600 ms 0/10521 (0%)
[1928] 10.0-15.0 sec 6.57 MBytes 11.0 Mbits/sec 0.591 ms 0/ 4684 (0%)
[1928] 15.0-20.0 sec 14.9 MBytes 25.0 Mbits/sec 0.590 ms 0/10609 (0%)
[1928] 20.0-25.0 sec 14.9 MBytes 25.0 Mbits/sec 0.586 ms 0/10638 (0%)
Видно что потерь пакетов нет. UDP, как известно, протокол без потверждения доставки; в отличии от TCP он не может адаптироваться к заторам в сети; UDP-клиент (в нашем случае iperf) отсылает трафик с возможной для него скоростью (для iperf выставлено 25 Мбит/c).
Но мы видим, что в "яме" скорость отправки составляла 16.5 Мбит/с и даже 11.0 Мбит/с. Вместе с тем, нет сброшенных пакетов и ошибок, в сети ничего не потерялось. Значит, что-то не давало клиенту возможности отправлять трафик в сеть с большей скоростью. Что это?
Это - механизм контроля доступа к беспроводной среде - CSMA/CA (Carrier sense multiple access with collision avoidance). Он мониторит среду и обнаруживает, что какая-то станция уже передает трафик, и не позволяет отправить фрейм в этот момент.
Т.е. тест показывает, что в беспроводной сети присутствует некий "левый" (с моей точки зрения) трафик; остается его идентифицировать и принять меры по лечению...
Что касается iPerf, он снова хорошо показал себя: легкий, удобный и удивительно полезный инструмент.
