Формирование исходящего трафика в Linux для канала с неизвестной шириной

Вы проверяли эту ссылку?

http://www.tldp.org/HOWTO/html_single/Traffic-Control-HOWTO/#r-unknown-bandwidth

>     8.2. Handling a link with a known bandwidth
>     
>     HTB is an ideal qdisc to use on a link with a known bandwidth, because the innermost (root-most) class can be set to the maximum
> bandwidth available on a given link. Flows can be further subdivided
> into children classes, allowing either guaranteed bandwidth to
> particular classes of traffic or allowing preference to specific kinds
> of traffic

Я думал, что это поможет, но, если у него нет какого-либо механизма, контролирующего его отток, очередь опустошается слишком быстро и никогда не показывает веса drr (не совсем уверен, почему это является). Однако, как только возникает давление выбора, он работает именно так, как должен.

tc qdisc add dev eth0 handle 1 root drr
tc class add dev eth0 parent 1: classid 1:1 drr quantum 600  # 30%
tc class add dev eth0 parent 1: classid 1:2 drr quantum 1400 # 70%
tc class add dev eth0 parent 1: classid 1:3 drr # everything else....

tc qdisc add dev eth0 parent 1:1 handle 10: sfq perturb 120 limit 1024
tc qdisc add dev eth0 parent 1:2 handle 20: sfq perturb 120 limit 1024
tc qdisc add dev eth0 parent 1:3 handle 30: sfq perturb 120 limit 1024

# outgoing to port 8111 will go to 30% queue, 8112 will go to 70% queue...
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 8111 0xffff classid 1:1
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 8112 0xffff classid 1:2
# a default so my connection doesn't die when doing this.
tc filter add dev eth0 protocol all parent 1:0 prio 2 u32 match u8 0x00 0x00 at 0 classid 1:3 

Если вы оберните все это в HTB со скоростью потока 800 кбит / с, вы получите хорошее разделение 70 КБ / 30 КБ, протестированное параллельным запуском pv -ar / dev / zero | nc differenthost port .

Между прочим, не пытайтесь проверить это с удаленного компьютера на линейной скорости без механизмов внеполосного управления. (упс)

Может быть, этот ответ все равно поможет.

---

Правка : При поиске в Интернете выясняется, что нет другого примера qdisc с циклическим перебором (DRR) linux, кроме примера, включенного в справочную страницу, который мне показался неполным, без правил фильтрации (и предостережений) из этого) и, как правило, неочевидны.

Что такое DRR

Круговой алгоритм дефицита - это алгоритм планирования, который можно представить в виде ряда параллельных очередей. Планировщик последовательно выполняет итерацию этих очередей. Каждый раз при появлении очереди, если она не пуста, он проверяет размер следующего пакета в очереди по числу, которое отслеживает для каждой очереди, называемого счетчиком дефицита . Если размер пакета меньше, чем счетчик дефицита, DRR удаляет пакет из очереди и отправляет его для передачи по сети и вычитает его размер из счетчика дефицита (отсюда и дефицит). Затем он повторяется со следующим пакетом в очереди, пока либо пакет не станет больше, чем счетчик дефицита, либо очередь не станет пустой. Если очередь не пуста по окончании цикла, зависящее от очереди значение квант добавляется к счетчику дефицита перед переходом к следующей очереди.

На самом деле это не так уж и отличается от HTB, за исключением того, что HTB ограничивает максимальную сумму, добавляемую к заданной очереди в любом конкретном временном интервале (почти уверен, что Linux измеряет это в байтах на один миг, хотя это может быть неверно с тиком без тиков), а также имеет счетчик дефицита для всех объединенных очередей (который также заполняется некоторым количеством байтов за интервал времени)

Пример описания использования

Таким образом, в приведенном выше примере создается диск drr qdisc в качестве корневого и добавляются к нему 3 очереди, одна с квантом 600 байт на проход, вторая с 1400 байтами на проход , и третий, который по умолчанию соответствует размеру MTU. По причинам, которые я немного объясню, не имеет большого значения, каковы значения, а только каково соотношение.

Поскольку мне нравится быть справедливым, я добавил несколько sfq-файлов к листьям; в этом нет необходимости, потому что, если вы этого не сделаете, он должен по умолчанию использовать pfifo fast (или, как мне кажется, ваш планировщик по умолчанию. Чтобы быть уверенным на 100%, мне нужно было бы прочитать исходный код sch_drr.c). Это также не меняет мои тесты, так как я использовал одно TCP-соединение для каждого порта.

tc filter rules for testing description

Когда я тестировал вышеуказанное, у меня возникли некоторые проблемы с правилами фильтрации. drr не имеет потока по умолчанию, как у многих других qdiscs, и не позволяет вам назначать его в качестве параметра qdisc (о чем я знаю, если это так, отредактируйте этот ответ). Так что это довольно забавно в некоторой степени, когда он начинает сбрасывать ваши пакеты на пол, потому что он не может ставить в очередь такие вещи, как запросы или ответы arp, и это не так. Я говорю, почему ваш интерфейс самопроизвольно отключается.

Итак, первые два правила выполняют тестовое действие, сопоставляют порт tcp / udp (он находится в одном месте) с 8111 и 8112, помещая совпадения в соответствующую очередь, останавливая сопоставление, если найдено соответствующее правило.

Третье правило гласит: «Сопоставьте любой протокол, в котором первый байт (смещение 0) совпадает с 0x0 с маской 0», и поместите его в третью очередь. Приоритет 2 оценивается после первого прохода и затем перехватывает все несогласованные пакеты. Если вы знаете лучший способ сделать classid по умолчанию, я бы обязательно хотел знать.

Квантовый выбор

Как я упоминал ранее, фактические значения не имеют такого большого значения, как соотношение, хотя, вероятно, это будет сделать очереди более прерывистыми (под этим я подразумеваю вставку в одну очередь для X пакетов за проход), если они больше, чем должны быть, и используйте больше процессорного времени, если они меньше. По этой причине я выбрал значения, близкие к тому же порядку величины, что и MTU, отношение которых к целевому соотношению 30/70 очевидно. Поскольку квант определяет скорость заполнения за проход и, таким образом, количество байтов за проход, соотношение квантов будет отношением байтов за проход относительно друг друга. Если одна очередь пуста, другие не столько поглощают ее пропускную способность, сколько просто тратят больше времени, пропуская пустую очередь и заполняя себя.

Относительная нехватка документации по сравнению с HTB или CBQ подсказывает мне, что DRR не особенно популярный qdisc, поэтому, к сожалению, если вы все же решите пойти по этому пути, я ожидаю, что поддержка будет довольно скудной, поэтому его трудно рекомендовать для использования.

Я выбрал значения, близкие к тому же порядку величины, что и MTU, отношение которых к целевому соотношению 30/70 очевидно. Поскольку квант определяет скорость заполнения за проход и, следовательно, количество байтов за проход, соотношение квантов будет отношением байтов за проход относительно друг друга. Если одна очередь пуста, другие не столько поглощают ее пропускную способность, сколько просто тратят больше времени, пропуская пустую очередь и заполняя себя.

Относительная нехватка документации по сравнению с HTB или CBQ подсказывает мне, что DRR не особенно популярный qdisc, поэтому, к сожалению, если вы все же решите пойти по этому пути, я ожидаю, что поддержка будет довольно скудной, поэтому его трудно рекомендовать для использования.

Я выбрал значения, близкие к тому же порядку величины, что и MTU, связь которого с целевым соотношением 30/70 видна. Поскольку квант определяет скорость заполнения за проход и, следовательно, количество байтов за проход, соотношение квантов будет отношением байтов за проход относительно друг друга. Если одна очередь пуста, другие не столько поглощают ее пропускную способность, сколько просто тратят больше времени, пропуская пустую очередь и заполняя себя.

Относительная нехватка документации по сравнению с HTB или CBQ подсказывает мне, что DRR не особенно популярный qdisc, поэтому, к сожалению, если вы все же решите пойти по этому пути, я ожидаю, что поддержка будет довольно скудной, поэтому его трудно рекомендовать для использования.

соотношение квантов будет отношением байтов за проход друг к другу. Если одна очередь пуста, другие не столько поглощают ее пропускную способность, сколько просто тратят больше времени, пропуская пустую очередь и заполняя себя.

Относительная нехватка документации по сравнению с HTB или CBQ подсказывает мне, что DRR не особенно популярный qdisc, поэтому, к сожалению, если вы все же решите пойти по этому пути, я ожидаю, что поддержка будет довольно скудной, поэтому его трудно рекомендовать для использования.

соотношение квантов будет отношением байтов за проход друг к другу. Если одна очередь пуста, другие не столько поглощают ее пропускную способность, сколько просто тратят больше времени, пропуская пустую очередь и заполняя себя.

Относительная нехватка документации по сравнению с HTB или CBQ подсказывает мне, что DRR не особенно популярный qdisc, поэтому, к сожалению, если вы все же решите пойти по этому пути, я ожидаю, что поддержка будет довольно скудной, поэтому его трудно рекомендовать для использования.