HTB: о сумме rate внутренних классов и родительского класса.

На мой малоопытный взгляд:

=====Напрашивает вывод, что если parent == root class, который никому ничего отдать не может, то сумма rate внутренних классов простой схемы, когда есть только root и набор leaf-классов, значения не имеет, так?
И еще, что будет, если не сложилось? Допустим, parent rate=10, inner1=7, inner2=7. В сумме = 14. Но оба класса производят трафика в сумме только на 5.


Если эта сумма меньше, то максимально возможный трафик в канале будет недостижим даже при максимальной загрузке внутренних классов. Т.е. имеем недоиспользование канала. Если сумма превышает, то при попытке получить максимальный rate в каждом классе возникает неопределенность и, очевидно, что макс. rate в классе будет недостижим. Зачем планировать недостижимый rate?


=====В любом случае, вне зависимосли от rate классов, остаток, если он есть, отдается наверх (если нет - то отдавать нечего), правильно?

"HTB does not shape in any class except the leaf class". Я так понимаю, что как раз наоборот, никуда он не отдается.

>Если сумма превышает, то при попытке получить максимальный rate в каждом классе возникает неопределенность и, очевидно, что макс. rate в классе будет недостижим.

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

Например, сделав rate у высокоприоритетных классов $[$devRate/2], причем эта величина в идеале _никогда_ не достигается.

А все остальные n классов делят канал поровну, соответственно, сумма rate может быть гораздо выше самого$devRate.

Вот мне и интересно, наскольно это критично (да и критично ли?).

>"HTB does not shape in any class except the leaf class". Я так понимаю, что как раз наоборот, никуда он не отдается.

а где в цитате речь об этом? :) Отдается, это точно (если мы говорим об одном и том же)

Извиняюсь если не в тему, но у меня возникал такой же вопрос. Я не нашел ответа в доках и стал использовать cbq, который по идее должен при нехватке канала разделять полосу пропорционально weight

ИМХО, htb при указаном вами примере будет делить так.

1-й класс от 3 до 7
2-й класс от 3 до 7
но в сумме не более 10

возможно пропорционально количеству пакетов TCP-сессий или чего еще, без каких либо гарантий

К предыдущему сообщению...

ИМХО, тема вообще требует отдельного обсуждения на отдельном форуме... 8)

мне, например, не удалось вообще поделить полосу так как обещано в документации (в том же самом хау-ту). Т.е. я смог только ограничить полосу пакетам подходищим под определенное правило(а). Классовые примочки у меня не заработали. Причем примеры я копировал 1:1 из хау-ту.

>ИМХО, htb при указаном вами примере будет делить так.

Да нет, оба должны получить по 5.

>мне, например, не удалось вообще поделить полосу так как обещано в документации

и как ты думаешь, к чему бы это?.. ;)

>и как ты думаешь, к чему бы это?.. ;)

софт кривой...

неа - руки.

http://www.docum.org/docum.org/docs/htb/

rate

The rate of a class is the guaranteed bandwidth the class will get. If you add more then 1 subclass, make sure that the sum of the rates of the child class is equal or smaller then the rate of the parent.

You don't have to follow this rule, but it's easier to understand what will happen if you do so.

Значитли это, что внутренним структурам сумма of rates вообщем-то не важна, просто когда rates_вложенных_классов == parent rate, то не так у админа крыша едет при попытке понять, как же оно работает? %)

>Значитли это, что внутренним структурам сумма of rates вообщем-то не >важна, просто когда rates_вложенных_классов == parent rate, то не >так у админа крыша едет при попытке понять, как же оно работает? %)

Я про cbq! Пример в хау-ту явно говорит о суммарном ограничении через парент класс! цитировать лень...

еще у меня не работает заем полосы, так как надо!

к предыдущему сообщению:
примеры я проверял копи-пастом, менял только фильтры (там тяжело ошибиться!)

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

>Я про cbq!

Про CBQ, или cbq.init? В любом случае, я - про HTB, поскольку CBQ - пережиток прошлого.

>что-то я уже слишком долго с этим парюсь

Это сколько? :) Я тут недавно нашел свои первые вопросы по теме, так уже года два как.

И досих пор ковыряю :) Хотя, возможно я просто туповат, не исключено...

>Про CBQ, или cbq.init? В любом случае, я - про HTB, поскольку CBQ - пережиток прошлого.

не про cbq.init точно! его функциональность не выше HTB. Я готов отказаться от чего угодно как от пережитка прошлого (только не от ядра 2.4) если найду более-менее разумное решение

такой задачи:
1. Есть общее ограничение скорости по некоторому правилу (например родительский класс, например 10Мбит)
2. Есть частные случаи предыдущего класса (например подклассы, например с 1 по 10, каждый 2Мбит максимум)
3. При нехватке канала класс 1 и 2 берут по 40% полосы, а остальные по 2,5%

и такой задачи:
1. Есть класс "1" - 2Мбит
2. Есть класс "2" - 5Мбит
Когда класс "1" простаивает, класс 2 может использовать эти 2 Мбит и иметь скорость 7 Мбит, но только при простое. Класс 1 не может занимать полосу у класса2.

предыдущее сообщение
задача 1 пункт 2 читать как
"2. Есть частные случаи предыдущего класса (например подклассы, например с 1 по 10, каждый 5Мбит максимум)"

>не про cbq.init точно! его функциональность не выше HTB

Ты разницу между cbq.init и HTB чувствуешь? Кажется нет. Вот сначала прочувствуй :)

У тебя простая задача.

Да чуствую я.
Я все утилитой tc делаю, если ты об этом, и параметры НТВ я видел...

Если задача простая - черкани строчки для классов и очередей (можно без фильтров).

И чем тебе cbq не угодил?

И вообще, я не понял сравнения скрипта с очередью? это что как килобиты с милиметрами, что ли?

>И вообще, я не понял сравнения скрипта с очередью?

вот и я тоже :)

>>И вообще, я не понял сравнения скрипта с очередью?
>вот и я тоже :)

не надо придираться, понятно что имелось в виду то, что всю функциональность cbq не получиться использовать с помощью cbq.init