Перейти к содержимому
Калькуляторы

htb: суммарная скорость клиентов больше скорости родительского класса

Аплинк 120 мегабит, rate родительского класса htb - 100 мегабит, сумма rate клиентов во много раз больше rate родительского класса. Проблема в том, что при полной загрузке канала, клиенты в сумме получают все 120 мегабит. Пробовал ставить rate родителя 50 - ситуация не изменилась. Так и должно быть?

 

Структура фильтра:

tc qdisc del dev eth1 root

tc qdisc add dev eth1 root handle 1: htb default 100 r2q 90
tc class add dev eth1 parent 1: classid 1:1 htb rate 1000mbit burst 15k

tc class add dev eth1 parent 1:1 classid 1:10 htb rate 1mbit ceil 1000mbit burst 15k
tc class add dev eth1 parent 1:1 classid 1:20 htb rate 100mbit burst 15k
tc qdisc add dev eth1 parent 1:10 handle 10: sfq perturb 10
tc class add dev eth1 parent 1:1 classid 1:30 htb rate 10mbit burst 15k

tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match ip src 192.168.7.0/24 flowid 1:30
tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match ip dst 192.168.7.0/24 flowid 1:30
tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match ip src 10.0.0.1 flowid 1:10
tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match ip dst 10.0.0.1 flowid 1:10

tc class add dev eth1 parent 1:20 classid 1:100 htb rate 1mbit ceil 2621440 burst 15k

dir=/usr/scripts/billing/tc-rules/tc-rules

/usr/scripts/billing/tc-rules/10.0.10.10.sh
/usr/scripts/billing/tc-rules/10.0.10.2.sh
/usr/scripts/billing/tc-rules/10.0.11.43.sh
/usr/scripts/billing/tc-rules/10.0.15.2.sh
...

 

В файлах следующее:

tc class add dev eth1 parent 1:20 classid 1:197 htb rate 4194304 burst 15k
tc class add dev eth1 parent 1:197 classid 1:198 htb rate 4194304 prio 1
tc class add dev eth1 parent 1:197 classid 1:199 htb rate 4194304 prio 2
tc class add dev eth1 parent 1:197 classid 1:200 htb rate 4194304 prio 3
tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 match ip dst 10.0.10.5/32 match ip protocol 1 0xff flowid 1:198
tc filter add dev eth1 parent 1:0 protocol ip prio 3 u32 match ip dst 10.0.10.5/32 match ip sport 53 0xffff flowid 1:198
tc filter add dev eth1 parent 1:0 protocol ip prio 3 u32 match ip dst 10.0.10.5/32 match ip sport 5190 0xffff flowid 1:198
tc filter add dev eth1 parent 1:0 protocol ip prio 3 u32 match ip dst 10.0.10.5/32 match ip sport 5222 0xffff flowid 1:198
tc filter add dev eth1 parent 1:0 protocol ip prio 3 u32 match ip dst 10.0.10.5/32 match ip sport 5433 0xffff flowid 1:198
tc filter add dev eth1 parent 1:0 protocol ip prio 3 u32 match ip dst 10.0.10.5/32 match ip sport 80 0xffff flowid 1:199
tc filter add dev eth1 parent 1:0 protocol ip prio 3 u32 match ip dst 10.0.10.5/32 match ip sport 443 0xffff flowid 1:199
tc filter add dev eth1 parent 1:0 protocol ip prio 4 u32 match ip dst 10.0.10.5/32 flowid 1:200

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У корневого класса rate 1000mbit: tc class add dev eth1 parent 1: classid 1:1 htb rate 1000mbit burst 15k

Еще у одного из классов ceil на 1000mbit: tc class add dev eth1 parent 1:20 classid 1:100 htb rate 1mbit ceil 1000mbit burst 15k

Это значит, что если канал свободен, то будет использована вся доступная скорость.

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

photon, сделал так:

tc qdisc del dev eth1 root

tc qdisc add dev eth1 root handle 1: htb default 100 r2q 90
tc class add dev eth1 parent 1: classid 1:1 htb rate 80mbit burst 15k

tc class add dev eth1 parent 1:1 classid 1:20 htb rate 80mbit burst 15k
tc class add dev eth1 parent 1:1 classid 1:30 htb rate 10mbit burst 15k

tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match ip src 192.168.7.0/24 flowid 1:30
tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match ip dst 192.168.7.0/24 flowid 1:30

tc class add dev eth1 parent 1:20 classid 1:100 htb rate 1mbit ceil 2621440 burst 15k
...

 

ничего не изменилось

Изменено пользователем asid2006

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Зачем нужен burst 15k и ceil 2621440? Следует убрать все ceil и burst, и присвоить quantum значение кратное MTU: 1500, 3000 и т.д.

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

сделал так:

tc qdisc del dev eth1 root

tc qdisc add dev eth1 root handle 1: htb default 100
tc class add dev eth1 parent 1: classid 1:1 htb rate 80mbit

tc class add dev eth1 parent 1:1 classid 1:20 htb rate 80mbit

tc class add dev eth1 parent 1:20 classid 1:100 htb rate 1mbit ceil 2621440

 

скорость не изменилась.

 

при применении скрипта в логах записи вроде

...
Jan 18 16:54:07 localhost kernel: HTB: quantum of class 11799 is small. Consider r2q change.
Jan 18 16:54:07 localhost kernel: HTB: quantum of class 11800 is small. Consider r2q change.
Jan 18 16:54:07 localhost kernel: HTB: quantum of class 11802 is small. Consider r2q change.
Jan 18 16:54:07 localhost kernel: HTB: quantum of class 11803 is small. Consider r2q change.
...

 

может быть дело в этом?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я уже сказал, нужно присвоить параметру quantum у дочерних классов значение кратное 1500.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

для всех дочерних это сделать проблематично, т.к. их около 1000 сделал так:

tc qdisc del dev eth1 root

tc qdisc add dev eth1 root handle 1: htb default 100
tc class add dev eth1 parent 1: classid 1:1 htb rate 80mbit

tc class add dev eth1 parent 1:1 classid 1:20 htb rate 80mbit quantum 3000

tc class add dev eth1 parent 1:20 classid 1:100 htb rate 1mbit ceil 2621440

 

не помогло

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А это что? tc class add dev eth1 parent 1:20 classid 1:100 htb rate 1mbit ceil 2621440

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сделал. Сейчас так:

tc qdisc del dev eth1 root

tc qdisc add dev eth1 root handle 1: htb default 100
tc class add dev eth1 parent 1: classid 1:1 htb rate 80mbit

tc class add dev eth1 parent 1:1 classid 1:20 htb rate 80mbit quantum 3000

tc class add dev eth1 parent 1:20 classid 1:100 htb rate 1mbit
...

 

Плюс куча классов, дочерних для 1:20 без прописанного квантума

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если ошибки вылезают, то придется у каждого.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А это что? tc class add dev eth1 parent 1:20 classid 1:100 htb rate 1mbit ceil 2621440

класс для трафика, который не попадает ни под один фильтр

 

Если ошибки вылезают, то придется у каждого.

Вылезают.

Чтобы лишний раз всё не переделывать, посоветуйте квантум.

Ситуация следующая: интерфейс 1 гигабит, аплинк 120, скорости клиентов 1-10 мегабит, доступ к фтп должен быть на максимальной скорости, к интернет - согласно тарифному плану.

А нельзя задать r2q у какого-то из родительских классов, чтобы решить проблему?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А это что? tc class add dev eth1 parent 1:20 classid 1:100 htb rate 1mbit ceil 2621440

класс для трафика, который не попадает ни под один фильтр

Я имею в виду, зачем здесь ceil да еще и в неуказанных единицах?

 

Вылезают.

Чтобы лишний раз всё не переделывать, посоветуйте квантум.

Ситуация следующая: интерфейс 1 гигабит, аплинк 120, скорости клиентов 1-10 мегабит, доступ к фтп должен быть на максимальной скорости, к интернет - согласно тарифному плану.

А нельзя задать r2q у какого-то из родительских классов, чтобы решить проблему?

Там для автоматического вычисления quantum используется устаревшая формула, расчитанная на килобитные скорости. Поэтому надо везде его ставить вручную.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Значит, придётся искать время, чтобы написать скрипт для добавления квантума. Спасибо за помощь, по результатам отпишу.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поправил квантумы для всех подклассов 1:20, в логах ошибок больше нет, но проблема осталась.

 

Сейчас верхушка дерева выглядит так:

tc qdisc del dev eth1 root

tc qdisc add dev eth1 root handle 1: htb default 100
tc class add dev eth1 parent 1: classid 1:1 htb rate 1000mbit

tc class add dev eth1 parent 1:1 classid 1:10 htb rate 870mbit
tc class add dev eth1 parent 1:1 classid 1:20 htb rate 120mbit
tc class add dev eth1 parent 1:1 classid 1:30 htb rate 10mbit

tc qdisc add dev eth1 parent 1:10 handle 10: sfq perturb 10

tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match ip src 192.168.7.0/24 flowid 1:30
tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match ip dst 192.168.7.0/24 flowid 1:30
tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match ip src 10.0.0.1 flowid 1:10
tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match ip dst 10.0.0.1 flowid 1:10

tc class add dev eth1 parent 1:20 classid 1:100 htb rate 1mbit ceil 10mbit quantum 2000

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Так и должно быть. rate - фиксированная скорость. ceil - макс. скорость, обрезаемая при необходимости вышестоящим классом.

Далее, r2q - важный параметр, меняющий quantum от 1500 до 64к пропорционально скорости канала (rate). При этом трафик при упирании в вышестоящий класс делится пропорционально квантуму. Если тупо вбить quantum=1500 - скорость всем будет зарезаться в равной мере, независимо от пакета. Т.е. есть 2 класса с rate=1 и 2 мбит, и ceil 100 мбит, есть родительский класс с rate 100 мбит. Если quantum фиксированный - при 100% утилизации каналов оба класса получат по 50 мбит. Если не фиксированный - соответственно 33 и 66 мбит.

Далее, делайте запас порядка 5-10% от ширины внешнего канала. Т.к. траффик может вылазить за рамки ограничений на несколько %.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если хочется, чтобы суммарно было всегда ровно 100 Мбит/с, то лучше совсем убрать ceil из всех классов. При oversubscription (суммарные скорости дочерних классов превышают скорость родителя) будет использоваться вся свободная полоса.

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

При oversubscription (суммарные скорости дочерних классов превышают скорость родителя) будет использоваться вся свободная полоса.

Так вроде как это и не устраивает ТС... Ему надо все зажать в 120 мбит.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

сумма rate клиентов во много раз больше rate родительского класса.

Так в этом и ошибка.

Что бы сумма скоростей дочерних классов не выходила за пределы rate родительского класса нужно что бы суммы rate-тов всех дочерних были меньше rate родительского.

Т.е. rate у дочерних делаете значительно (зависит от количество дочерних) меньше скорости их тарифа.

А вот ceil дочерних делаете равным скорости тарифа.

Что-то типа этого

 

tc class add dev eth1 parent 1:20 classid 1:100 htb rate 128Kbit ceil 10mbit quantum 2000

 

Рассчитать "безопасную" rate можно примерно так: rate_родительского/(кол-во дочерних * коэф-т безопасности), где коэф-т безопасности > 1 !

Изменено пользователем Susanin

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Susanin

С точностью до наоборот. Дочерним классам можно ставить что угодно, за пределы родительского они не выйдут. А у ТС просто не прописан ceil у родителя, он ставится равным корневому - 1000mbit и вся раздача идет исходя из этого значения.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

kayot

Неправда Ваша.

http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm

4. Rate ceiling

The ceil argument specifies the maximum bandwidth that a class can use. This limits how much bandwidth that class can borrow. The default ceil is the same as the rate.

И проблема у TC как раз из-за того, что я описал выше.

По той-же ссылке:

3. Sharing hierarchy

......

The rate supplied for a parent should be the sum of the rates of its children.

Это граничный случай - rate родительского равна сумме rate дочерних.

Но нельзя что бы суммарный рейт дочерних был больше родительского - тогда они смело за него выйдут - ибо каждый из них всего лишь взял себе гарантированное. Поэтому рост до скорости по тарифу нужно закладывать в ceil - т.е. получить по тарифу можно только если есть свободная полоса. А она свободна до тех пор, пока родительский не уперся в свой rate. Что и нужно TC.

Изменено пользователем Susanin

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Susanin

А вы не читайте странные мануалы, читайте лучше lartc. Ибо эти постулаты бред, HTB как раз и применяют из-за возможности плавного и честного обмена токенами(динамического распределения полос по классам).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

kayot

???

 

У меня этот бред (с ваших слов) подтвержден практикой. Ибо по первой тоже натыкался на то, что выставил rate=тарифу и суммарно клиенты вылазили за родительский класс.

 

У Вас есть какое-то основательное подтверждение ваших слов, что бы они не были похожи на бред ?

 

kayot

 

http://lartc.org/manpages/tc-htb.html

 

CLASSES

...................

ceil rate

 

 

Maximum rate at which a class can send, if its parent has bandwidth to spare. Defaults to the configured rate, which implies no borrowing

 

ЧТД :))

Изменено пользователем Susanin

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Susanin

У меня шейпер так работает, задан rate=ceil= максимальной скорости на весь сервер. Дальше несколько тысяч клиентских классов(ceil=тариф, rate=2/3 ceil), сумма их rate и ceil в десятки раз превосходит родителя.

Ну и у каждого клиента может быть несколько хостов, каждому хосту выделяется тарифная скорость.

Все работает как и должно, хосты клиента делят его тарифную скорость, все клиенты делят ограничение сервера - никто никогда и никуда не вылезал.

 

P.S. а свою же цитату перевести можете?

if its parent has bandwidth to spare.

может использовать если у предка есть резерв полосы. Ни о каких превышениях над родителем речи не идет.

 

P.S.S. я понял о чем вы хотели сказать. Для корректной работы действительно сумма rate потомков должна быть <= rate родителя. Иначе токены у родителя будут заканчиваться и деление справедливое(с гарантированным rate) не сработает - пойдут потери. Но превысить родительский все равно невозможно :)

Изменено пользователем kayot

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

kayot

Переведу, только полностью:

Maximum rate at which a class can send, if its parent has bandwidth to spare. Defaults to the configured rate, which implies no borrowing

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

 

Т.е. так как ТС не указал ceil для класса который является родительским для всех абонентских классов, то ceil этого класса равен rate, т.е 120 Mbit (в данном случае):

tc class add dev eth1 parent 1:1 classid 1:20 htb rate 120mbit

 

Но никак не:

А у ТС просто не прописан ceil у родителя, он ставится равным корневому - 1000mbit

 

Так что Ваше первое высказывание неверно, а значит и весь пост неверен.

 

Повторю еще раз - проблема у ТС из-за того, что сумма rate дочерних классов внутри класса 1:20 больше 120 Mbit, то из-за этого их суммарная скорость не ограничивается классом 1:20 на 120Mbit.

Нужно каждому клиентскому классу дать минимальное значение rate и установить возможность роста до скорости тарифа = ceil.

Тогда (если суммарная полоса меньше 120 Mbit) у родительского класса появится свободные токены, которые он и распределит между дочерними классами. Как только суммарная скорость дойдет до 120 свободные токены закончатся и рост суммарной полосы прекратится.

 

Но превысить родительский все равно невозможно :)

Возможно!

Это и наблюдает ТС.

 

 

Ну и у каждого клиента может быть несколько хостов, каждому хосту выделяется тарифная скорость.

А мы для клиента делает один класс. А фильтрами (через хеш-таблицы) загоняем все его хосты в этот класс. Т.о. раз учетка одна, но много хостов (а платит-то тока за одну учетку) то и канал один на все хосты - считаю это более справедливым :)

Изменено пользователем Susanin

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А если прописать всем одинаковый rate в 1 мегабит, а ceil по тарифу, при полной загрузке канала скорости будут делиться пропорционально квантуму?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.