Добрый день.

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

Сделал две трубы in/out под общий канал по 480 кбит (подключение 521 кбит, т.е. минимум 512кбит он выдает 100% времени). Через него пропускаю 2 трубы, заточеные под in и out трафик, генерируемый игрой. У этого трафика приоритет 7 и полоса 96 кбит, что более чем достаточно для 3-4-х игроков. Мониторинг труб показывает, что все нормально - трафик распределяется как надо, но если загрузить основной канал под завязку, то в игре катастрофически растет задержка, при этом полоса, занятая игрой вроде бы и не меняется, т.е. свои 96кбит игроки получают.

Вопрос: это нормальное поведение устройства когда при включении шейпинга увеличиваются задержки прохождения пакетов или же у меня принципиально неправильное понимание того, что и как нужно делать для достижения поставленной цели?

Спасибо

Посмотрите пожалуйста внимательнее построение примеров. Для определения гарантированой полосы пропускания приложению или IP адресу нужно:
1. Создать правило для с общей полосой пропускания Fwd - out Ret - in
2. Создать правило для выделенной полосы и включить туда общую. Fwd - Game_out; out Ret - in; in_game.
Маленький момент ... в описанном выше примере нумерация правил должна быть 2.1 сотвественно, т.е. гарантированная полоса, потом общая полоса.

Хм.. Интересно... Моя начальная конфигурация отличалась от Вашей только вот чем - у меня было Ret - in_game; in. После применения того, что предложили Вы, в игре пинг какое-то время держался на приемлемом уровне, а потом потихонечку уполз вверх, но не до 5-6 сек, а где-то 1-1.5сек, при том что на свободном канале он составляет около 200мс.

Выглядит это приблизительно так

DFL-210:/>
Configured pipes:
Name Grouping Bits/s Pkts/s Precedence
--------------- --------------- ------ ------ --------
pipe-std-down None 480 K 0 0 7
Current: 299 K 46.0
pipe-std-up None 480 K 0 0 7
Current: 169 K 59.0
pipe-WoW-down None 96.0 K 0 7 7
Current: 38.8 K 4.00
pipe-WoW-up None 96.0 K 0 7 7
Current: 960 2.00

Есть подозрение, что почему-то не весь неигровой трафик проходит через основные трубы, поэтому и пинг потихоньку уползает вверх. Показанные выше значения загрузки основного канала не совсем соответствуют тому, что показывает MRTG, а MRTG показывает ровненькую загрузку входящего канала почти на 100% на протяжении всего времени тестов. Если бы реально были колебания 100-480, то средние показатели по загрузке входящего канала были бы ниже 100%

И еще, возвращаясь к последовательности труб в цепочке - объясните плиз на пальцах отличие между Ret - in; in_game и Ret - in_game; in. Правильно ли я понимаю, что в предложеном Вами варианте входящий трафик сначала пройдет через общую трубу (in, 480 kbitps), а потом уже из общего потока вырежется игровой трафик? или наоборот?

Подчёркиваю, что нужно именно два правила!
первое для определения _всей_ полосы, второе для _ограничения_ из всей полосы, _гарантированную_
1. С двумя цепочками, то чему нужно выделить полосу и общую полосу
2. Общяя полоса.
Обращяю внимание, на то что нужно продумать фильтр к которому будет применятся правило.

После того, как получилось 100% трафика запихать в общую трубу, заработала и гарантированная полоса. Оказалось, что lan->pppoe это не единственный маршрут, по которому идет интернетовский трафик
Спасибо за подсказки, Станислав.