Шейпинг трафика tc

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

А можно ссылку на такую статью?

здесь в разделе 3 (и на англиском) и здесь

Понятно :). Навскидку, если у пользователей разные приоритеты, то трафик сначала пойдет пользователям с приоритетам выше. Т.е., если rate у родительского класса 10 Мбит/с, и есть 3 пользователя с приоритетами 1, 2 и 3 и rate по 4 Мбит/с, то при захвате канала двумя первыми пользователями третьему достанется только 2 Мбит/с. Но если приоритеты у них одинаковые, то неизвестно (мне, по крайней мере), как поведет себя шейпер. Поэтому, для гарантированной доставки пропускной способности необходимо, чтобы сумма рейтов (rate) пользователей не превышала рейт родительского класса. Для ceil'ов аналогично, учитывая то, что ceil - максимальная пропускная способность данного класса.

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

Поэтому могу предложить тебе два варианта действий:

1) уменьшать рейты пользователей при добавлении новых пользователей с тем, чтобы их сумма была меньше рейта родительского класса;

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

Ну или, если некоторая погрешность допустима, можно сделать всем классам одинаковый приоритет, и пускай сумма их рейтов будет больше рейта родительского класса. У тебя не будет точного контроля за их траффиком, но это обойдется для тебя меньшей кровью. Хотя в данном случае, все-таки, лучше будет сделать вариант 1), но это уже зависит от твоей лени :)

Спасибо за объяснение. Первой ситуации я и опасался, но пытаюсь найти метод распределения канала с более контролируемыми параметрами, по аналогии с weight в cbq где в случае выхода рейса за пределы пропускной способности канала скорость пользователей перерасчитывается в соответствии с их весом. Хотелось бы найти подтверждение аналогичного поведения htb но по рейту или способа заставить его так обрабатывать эти ситуации.