Формирование трафика с помощью tc неточно из-за высокой пропускной способности и задержки

Я использую tc с ядром 2.6.38.8 для формирования трафика. Ограничение полосы пропускания работает, добавление задержки работает, но при формировании обеих полос пропускания с задержкой достигнутая пропускная способность всегда намного ниже предела, если предел> 1,5 Мбит / с или около того.

Пример:

tc qdisc del dev usb0 root
tc qdisc add dev usb0 root handle 1: tbf rate 2Mbit burst 100kb latency 300ms
tc qdisc add dev usb0 parent 1:1 handle 10: netem limit 2000 delay 200ms

Дает задержку (от ping) 201 мс, но пропускная способность всего 1,66 Мбит / с (от iperf). Если я устраню задержку, полоса пропускания будет ровно 2 Мбит / с. Если я укажу пропускную способность 1 Мбит / с и RTT 200 мс, все будет работать. Я также пробовал ipfw + dummynet, который дает аналогичные результаты.

Я пробовал использовать пересборку ядра с HZ=1000 в Kconfig - это не устранило проблему. Другие идеи?


linux network-programming trafficshaping ipfw
person Community    schedule 23.03.2012    source источник

Ответы (2)


arrow_upward
6
arrow_downward

На самом деле это не проблема, он ведет себя так, как должен. Поскольку вы добавили задержку в 200 мс, полный канал 2 Мбит / с не используется в полной мере. Я бы посоветовал вам изучить протокол TCP / IP более подробно, но вот краткое изложение того, что происходит с iperf: ваш размер окна по умолчанию составляет, возможно, 3 пакета (вероятно, 1500 байтов каждый). Вы заполняете свой канал 3 пакетами, но теперь должны ждать, пока вы не получите ответное подтверждение (это часть механизма контроля перегрузки). Поскольку вы задерживаете отправку на 200 мс, это займет некоторое время. Теперь размер вашего окна увеличится вдвое, и вы сможете отправить 6 пакетов, но снова придется ждать 200 мс. Затем размер окна снова удваивается, но к тому времени, когда ваше окно полностью откроется, 10-секундный тест iperf по умолчанию близок к завершению, и ваша средняя пропускная способность, очевидно, будет меньше.

person Alex    schedule 11.11.2012

arrow_upward
0
arrow_downward

Подумайте об этом так:

Предположим, вы установили задержку на 1 час, а скорость на 2 Мбит / с.

2 Мбит / с требует (например) 50 Кбит / с для TCP ACK. Поскольку для получения ACK требуется более часа, источник не может продолжить отправку со скоростью 2 Мбит / с, потому что окно TCP все еще застревает в ожидании первого подтверждения.

Задержка и пропускная способность больше связаны, чем вы думаете (по крайней мере, в TCP. UDP - это совсем другая история)

person Kal    schedule 18.08.2015