Собственно для tc есть queue discipline DRR(Dificite Round Robin) .Вкратце - умеет то же, что HTB, но вместо того, чтобы заполнять корзины токенами с определённой скоростью, потом их оттуда вынимать и т. д., просто присваивает каждой каждой очереди некоторый Dificit Counter, при отправке пакета - уменьшает его на размер пакета. Если DC меньше размера пакета, увеличивает размер DC на заданный для очереди quantum и переходит к следующей. Таким образом, можно делить исходящий траффик в некотором отношении, не зная заранее ширину канала(что требуется для HTB). Подробнее: http://www.unix.com/man-page/linux/8/tc-drr/
Setup: две машины, 172.16.1.1 и 172.16.1.2.
На первой - слушаем траффик:
nc -l 8111
nc -l 8112На второй - проверяем скорость:
pv /dev/zero | nc 172.16.1.1 8111
pv /dev/zero | nc 172.16.1.1 8112Пока скорость равная(pv - позволяет мерить скорость через pipeline). Добавляем на второй машине шейпер(сверху присобачен HTB для имитации ограничения скорости канала):
tc qdisc add dev eth0 root handle 1: htb
tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit ceil 100mbit
tc qdisc add dev eth0 parent 1:1 handle 2: drr
tc class add dev eth0 parent 2: classid 2:1 drr quantum 600
tc class add dev eth0 parent 2: classid 2:2 drr quantum 1400
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dport 8111 0xffff classid 2:1
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dport 8112 0xffff classid 2:2Скорость остаётся равной :( Куда копать?
Насколько я помню из опыта для u32 надо указать dport в 16-ричной системе (как маску).
Т.е. у вас просто filter не срабатывает из-за этого.
> Насколько я помню из опыта для u32 надо указать dport в 16-ричной
> системе (как маску).Сделал:
dport 0x1faf
dport 0x1fb0
Не помогло :( Но косвенная проверка показывает, что фильтры работают: у drr нет default class, так что все остальные пакеты режутся. Проверил с портом 8000 - правда режутся.
М.б. из-за маленького quantum (меньше MTU - у вас же Ethernet?) и не очень большой разницы между quantum в классах разница в скорости невелика и вы её не наблюдаете?
Попробуйте quantum в нексолько раз больший чем MTU.
200 и 60000 - то же самое, одинаковые скорости. Чего-то я в этом DRR не понимаю
http://users.ece.gatech.edu/~siva/ECE4607/presentations/DRR.pdf
Насколько я сейчас это понимаю, DRR не рашает задачу так, как вы описали в начале (не аналог HTB).
DRR позволяет решить задачу честного распределения пропускной способности между потоками, аналогично SFQ, но используя меньшие вычислительные ресурсы + возможность явной классификация потоков.
Из описания алгоритма я так и не смог понять зачем нуже quantum и как quantum влияет на поведение трафика.
> http://users.ece.gatech.edu/~siva/ECE4607/presentations/DRR.pdfВ этом документе действительно про quantum ничего не написано. Я читал man tc-drr(http://www.unix.com/man-page/linux/8/tc-drr/):
ALGORITHM
Each class is assigned a deficit counter, initialized to quantum.DRR maintains an (internal) ''active'' list of classes whose qdiscs are
non-empty. This list is used for dequeuing. A packet is dequeued from
the class at the head of the list if the packet size is smaller or
equal to the deficit counter. If the counter is too small, it is
increased by quantum and the scheduler moves on to the next class in
the active list.PARAMETERS
quantum
Amount of bytes a flow is allowed to dequeue before the sched-
uler moves to the next class. Defaults to the MTU of the inter-
face. The minimum value is 1.Но, похоже, это почему-то не обеспечивает требуемого поведения. Странно, по идее должно получаться, что при полной загрузке пакеты из класса с quantum 750 должны отправляться в два раза реже, чем из класса с quantum 1500. Пичаль :(
http://www.cisco.com/en/US/products/hw/routers/ps167/product...
Да, похоже что поведение, которое вы ожидаете в данном случае, должно реализовываться.
Вы трафик генерируете на второй машине и там же измеряете?
М.б. кажущееся отсутствие результата из-за неправильного измерения?
Логичнее (чтобы исключить все если) измерять скорость на первой машине, т.е. делать честный download.
А у вас возможно так получается:
на второй машине генерируете трафик, измереяете скорость *генерации* еще до исходящей очереди, далее DRR и трафик попадает на первую машину - *но вы там скорость не измеряете*.
Т.е. не думаю что конструкция 'pv /dev/zero | nc 172.16.1.1 8111' показывает вам скорость *с котрой трафик отдается в сеть, после всех очередей уже на выходе из интерфейса*
> Логичнее (чтобы исключить все если) измерять скорость на первой машине, т.е. делать
> честный download.Попробовал считать скорость на принимающем хосте - тот же результат.
Зато, неожиданно, реальный большой файл передаётся быстрее, чем /dev/zero.
Вобщем пойду HTB настраивать с индивидуальным выставлением скорости для каждого филиала, красивое решение с DRR не прокатило :(
>[оверквотинг удален]
> Amount of bytes
> a flow is allowed to dequeue before the sched-
> uler moves to the next
> class. Defaults to the MTU of the inter-
> face. The minimum value is
> 1.
> Но, похоже, это почему-то не обеспечивает требуемого поведения. Странно, по идее должно
> получаться, что при полной загрузке пакеты из класса с quantum 750
> должны отправляться в два раза реже, чем из класса с quantum
> 1500. Пичаль :(нет, прочитай ещё раз,при полной загрузке если mtu=1500 то отправляться будут также, попробуй числа кратные mtu (только для полной загрузки) там quantum к сдлиной пакета связан, если он меньше длины пакета то все равно какое значение (это судя по описанию)
>[оверквотинг удален]
> tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit
> ceil 100mbit
> tc qdisc add dev eth0 parent 1:1 handle 2: drr
> tc class add dev eth0 parent 2: classid 2:1 drr quantum 600
> tc class add dev eth0 parent 2: classid 2:2 drr quantum 1400
> tc filter add dev eth0 parent 1: protocol ip prio 1 u32
> match ip dport 8111 0xffff classid 2:1
> tc filter add dev eth0 parent 1: protocol ip prio 1 u32
> match ip dport 8112 0xffff classid 2:2
> Скорость остаётся равной :( Куда копать?как насчет http://people.netfilter.org/hawk/shaper-example/qos-DRR-example ??
> как насчет http://people.netfilter.org/hawk/shaper-example/qos-DRR-example ??У них там DRR без quantum в классах, это что-то типа эмуляции SFQ.
Pinkbyte с ЛОРа нашёл решение: http://www.linux.org.ru/forum/admin/9585325?lastmod=13796263...DRR не дропает пакеты. Поэтому достаточно повесить на концы pfifo limit 50 и всё работает как положено :)