Так это нормально, со стороны провайдера в твою сторону приориетеы не ставит. А товй конфиг гаранитрует что приоритетеные пакеты первыми уйдут с твоего внешнего интерфейса.
Первый вариант - забивается буфер у провайдера. Попробуй поставить меньшую скорость в classid 1: и соотвественно для подклассов и затем посмотреть пинг.
Если первое не поможет то используй prio вместо root htb qdisc, а уже на prio навешать htb qdisc-и.
> /sbin/tc qdisc add dev eth1 parent 1:200 esfq perturb 5 hash fwmark
Дисциплина очереди для "Украины". hash fwmark из readme esfq:
=============HASH TYPES==============
classic
This is original SFQ hash. Traffic is separated by flow (TCP connection, UDP
stream, etc.).
src, dst, fwmark
Hash by the packet's source IP, destination IP, or iptables mark,
respectively. The hashing algorithm is well suited for a large range of
diverse input values. Collisions will happen occasionally; see the "perturb"
parameter. If the range of values to be hashed is less than 2^14 (16384),
consider using the direct hash methods listed below.
...
>Опять же 350+500+250 !=1000,
Спасибо. Арифметика подвела.
>(1000+1000+128) != 2Mbit
Тут, наверное, Вы ошиблись. Это потомки 12-Мбитного класса, а не 2-мбитного.
Попробую понизить скорости, как Вы советуете.
> Дисциплина очереди для "Украины". hash fwmark из readme esfq:
> =============HASH TYPES==============
Это я знаю. Еще раз подробно
/sbin/tc class add dev eth1 parent 1:2 classid 1:200 htb rate 1000Kbit ceil 1300Kbit prio 0
>>>> /sbin/tc qdisc add dev eth1 parent 1:200 esfq perturb 5 hash fwmark
Это зачем?
#---Games+Short---#
/sbin/tc class add dev eth1 parent 1:200 classid 1:210 htb rate 500Kbit ceil 1000Kbit prio 1
/sbin/tc qdisc add dev eth1 parent 1:210 esfq perturb 5 hash dst
/sbin/tc filter add dev eth1 parent 1: protocol ip prio 1 handle 3 fw flowid 1:210
Или наоборот это зачем?
+ Ещё есть вариант увеличть r2q - но тут он не поможет - только если переписать по другому.
Идея в том что пучть есть два подкласса класса 1000bit/s - 200kbit/s prio 0 800kbit/s prio 1. htb шлет кусками (quantum) = rate/r2q. r2q по умолчанию 10, т. е. Htb сначала пошлет 800/10 = 80 kbit из низкоприоритетного, затем 200/10 из высокопприоритетного - т. е. задержка на htb для высокоприоритетного - 80-100ms.
Т. е. можно увеличить r2q - но quantum должен быть > mtu, а в правилах есть rate=16kbit - т. е. наоборот надо уменшать r2q до 1 - чтобы это правило нормально работало (чтобы было ровно 16).
И второй вариант как я сказал - использовать prio - там высокоприоритетный сразу шлётся.
> Не совсем понял. Почему htb сначала пошлет низкоприоритетный, а только потом высокоприоритетный
Ну считай по-другому - сначала высокоприоритетный, потом низкоприоритетный, потом снова высокоприоритетный, и т. д. - все равно задержка 80-100мс.
> ведь смысл приоритета тогда в чем?
В том как распределяется избыток канала. В вышеприоритетном примере 1000bit/s - 200kbit/s prio 0 800kbit/s prio 1 значения prio не играют абсолютно никакой роли.
>Ну считай по-другому - сначала высокоприоритетный, потом низкоприоритетный, потом снова высокоприоритетный, и т. д. - все равно задержка 80-100мс.
Понял. Т.е. если уменьшим quantum, то уменьшится и задержка за счет дробления этих сессий. В таком случае в чем мы проиграем, если quantum всегда выставлять = mtu (т.е. минимум)?
> Понял. Т.е. если уменьшим quantum, то уменьшится и задержка за счет дробления
> этих сессий. В таком случае в чем мы проиграем, если quantum
> всегда выставлять = mtu (т.е. минимум)?
В принципе так автор htb и рекомендует изредка так делать. Но по-моему (хотя не уверен),
если мы выставим одинаковый quantum для классов с разными rate, то
скорости распределятся пропроционально quantum - т. е. будут одинаковыми.
Лучше в данном случае по-моему использовать несколько qdisc-ов и выставить
локально r2q - что-то типа:
# r2q = 128000/(1500*8) = 10
tc qdisc add dev eth1 root handle 1: htb r2q 10
tc class add dev eth1 parent 1:0 classid 1:2 htb rate 3128kbit
tc class add dev eth1 parent 1:2 classid 1:100 htb rate 2000kbit
tc class add dev eth1 parent 1:2 classid 1:200 htb rate 1000Kbit
tc class add dev eth1 parent 1:2 classid 1:300 htb rate 128Kbit
# Добавляем следующий qdisc
# r2q = 300000/(1500*8) = 25
tc qdisc add dev eth1 parent 1:100 handle 2: htb r2q 25
tc class add dev eth1 parent 2:0 classid 2:2 htb rate 2000kbit
tc class add dev eth1 parent 2:2 classid 2:110 htb rate 1000Kbit ceil 2000Kbit prio 0
tc class add dev eth1 parent 2:2 classid 2:120 htb rate 700Kbit ceil 2000Kbit prio 1
tc class add dev eth1 parent 2:2 classid 2:130 htb rate 300Kbit ceil 2000Kbit prio 2
# Аналогично r2q = 150000/(1500*8) = 12
tc qdisc add dev eth1 parent 1:200 handle 3: htb r2q 12
tc class add dev eth1 parent 3:0 classid 3:2 htb rate 1000kbit
tc class add dev eth1 parent 3:2 classid 3:210 htb rate 500Kbit ceil 1000Kbit prio 0
tc class add dev eth1 parent 3:2 classid 3:220 htb rate 350Kbit ceil 1000Kbit prio 1
tc class add dev eth1 parent 3:2 classid 3:230 htb rate 150Kbit ceil 1000Kbit prio 2
# Аналогично r2q = 19000/(1500*8) = 1
tc qdisc add dev eth1 parent 1:300 handle 4: htb r2q 1
tc class add dev eth1 parent 4:0 classid 4:2 htb rate 128kbit
tc class add dev eth1 parent 4:2 classid 4:310 htb rate 64Kbit ceil 128Kbit prio 0
tc class add dev eth1 parent 4:2 classid 4:320 htb rate 45Kbit ceil 128Kbit prio 1
tc class add dev eth1 parent 4:2 classid 4:330 htb rate 19Kbit ceil 128Kbit prio 2
Хотя тоже будет задержка - из-за классов 1:100, 1:200, 1:300, но зато уменьшится
задержка при обработке классов присединенных к 2:2, 3:2, 4:2.
Визможно ещё можно попробовать поменять burst, cburst -
смотри http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm - там всё подробно расписано.
По-поводу prio - см. tc-prio(8). Примеры - http://www.google.com/search?q=prio+tbf+qdisc+voip
Опять по-моему будет задержка из-за классов 1:100, 1:200, 1:300.
Лучше сразу пускать на prio без подклассов htb.
Что-то типа:
/sbin/tc qdisc add dev eth1 root handle 1: htb
/sbin/tc class add dev eth1 parent 1: classid 1:2 htb rate 3128kbit
/sbin/tc qdisc add dev eth1 parent 1:2 handle 2:0 prio bands 2 priomap 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
Или даже:
/sbin/tc qdisc add dev eth1 root handle 1:0 tbf rate 3128kbit burst 1500 latency 2s
/sbin/tc qdisc add dev eth1 parent 1:0 handle 2:0 prio bands 2 priomap 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
И уже на prio навешать htb qdisc-и, class-ы.
И соответсвенно весь высокоприоритетный пустить через 2:1, norm и low - 2:2.
Но зато никак не сделаешь чтобы на например на украину всегда было не
больше 1mbit. Короче чем-то придётся жертвовать - или пингом, или
точностью деления и заёмом классов друг у друга.
> Думаю, так еще меньше задержек. Только мне не нравится немного, что весь приоритет валится в один класс без контроля скорости. Хоть он и приоритет, но может возникнуть ситуация, когда туда пойдет значительная часть полосы и тогда классы 2:ххх будут некорректны мне кажется..
Так оно и есть.
Во первых так как везде используется esfq, то и для handle 100: лучше использовать esfq вместо prio.
Во-вторых может имеет смысл повесить на handle 100: htb или tbf (с условно говоря к примеру rate=200kbit). Только не ясно как на это среагирует prio. В принципе prio не шлёт через 1:2 когда что-то есть для 1:1.
Т. е. не ясно что произойдет если скорость через 1:1 превысит 200kbit - закупорится трафик через 1:2 или будет нормально слаться. В любом случае можно попробовать проверить.
>Во первых так как везде используется esfq, то и для handle 100: лучше использовать esfq вместо prio.
Наверное, вы имеете ввиду pfifo. Просто esfq, насколько я понимаю, нужен, чтобы делить канал между потребителями по ip - это критично при скачке с ftp и http, а тут мне показалось, что быстрее будет просто pfifo (хотя я не знаю создает ли какие-то весомые задержки esfq).
>Т. е. не ясно что произойдет если скорость через 1:1 превысит 200kbit - закупорится трафик через 1:2 или будет нормально слаться. В любом случае можно попробовать проверить.
Учитывая то, что в 1:2 оно точно не пойдет (фильтры), то мне кажется, что все лишнее просто будет дропаться, чего не хотелось бы.
>И во-вторых лучше не делать prio root-ом. А сделать root-ом tbf, а к нему подвесить prio - как написанно выше.
Не совсем понимаю зачем. Кроме как ограничить интерфейс в скорости я преимуществ не вижу, подскажите.
Сейчас очень интересуют такие параметры на burst и cburst. В http://remizov.pp.ru/ru/trn/doc/manuals/htb-manual#uskorenija сказано, что с помощью этого можно улучшить такой трафик, как WEB. Вопрос в том сколько именно стоит ставить burst, чтобы выиграть в WEB и не проиграть в остальном?
>>И во-вторых лучше не делать prio root-ом. А сделать root-ом tbf, а к нему подвесить prio - как написанно выше.
>Не совсем понимаю зачем. Кроме как ограничить интерфейс в скорости я преимуществ не вижу, подскажите.
Чтобы освободить send buffer у провайдера. Может произойти ситуация когда 1:2 будет полностью забит и когда 1:1 будет слать - будет заполняться буфер у провайдера - пинг резко возрастёт.
Вообще скорость на tbf надо сделать меньше реальной на 5-15% - чем меньше будет скорость - чем меньше заполненен буфер у провайдера - тем лучше пинг.
Проблема в том, что сложно сказать какая скорость реальная. Для мира - это 128 кбит, для Украины 1 мбит, для локальной сети провайдера 2 мбит. Поэтому если я ограничу скорость на 3 мбит, то это не освободит, насколько я понимаю, send bufefer у провайдера, если допустим будет забит под завязку только "украинский" мегабитный канал.
Выходит, что тут нужна не одна root очередь, а целых 3. Может есть такая возможность, а я не знаю?
После нескольких дней теста конфигурации выше я пришел к выводу, что prio в таких условиях мне не помогает обеспечить приоритет для интерактивного трафика. Все что помогает это просто грубо отрезать кусок, например, украинского трафика и зарезервировать его за интерактивным. По сути это можно было сделать и без prio.
Люди в соседнем форуме говорят, что для этих целей можно бы воспользоваться HFSC, который партирован из BSD и поддерживается моим ядром и iproute2, но разобраться в нем очень сложно.