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

Question

Я использую 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 Мбит / с и 200 мс RTT, все работает. Я также попробовал ipfw + dummynet, который дает аналогичные результаты.

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

Answer 1

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

Answer 2

Думайте об этом так:

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

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

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