Ограничение канала

man tc

если лень - google:// wondershaper

man tc
если лень - google:// wondershaper

Не лень, за tc спасибо, пичитаю man

Только не пытайтесь ограничивать входящий канал - это бессмысленно.

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

>Только не пытайтесь ограничивать входящий канал - это бессмысленно.

Бессмысленно пытаться или ограничивать? Помоему и то и другое имеет смысл.

распространнённое заблуждение. tcp-трафик отлично шейпится.

TCP-трафик, конечно, важен, но это далеко не весь трафик. Как там с другими видами трафика?

И о каком инструменте речь? IFB? Или IMQ? Какая политика ограничений — задержка в очередях или дроп?

ifb идеологически вернее. Шейпится любой трафик, другое дело можно на это смотреть с той стороны, что из сети на интерфейс этот трафик все равно прилетает c той же скоростью, если это не tcp, который уменьшит скорость. То есть если ваш клиент будет делать запросы UDP, и ответы ему будут приходить UDP, то ваш довнлоад будет зависить только от количества запросов, и хоть клиенту вы отшейпите сколько хочется, но ваш канал от шейпера до провайдера все равно будет загружен.

Если софт использует udp итп и не умеет масштабироваться по пропускной способности канала то никак, горбатого могила исправит. Но если, скажем, в udp завёрнут tcp(туннелирование) то этот механизм всё равно сработает нормально.

Я даже и не знаю что за не-tcp трафик может гулять в больших объёмах. Могу предположить что видео.

В остальных случаях хоть дропами хоть очередями проблема решается. Делал через очереди на pf, полёт нормальный.

А если не канал резать, а приоритеты расставлять? Как это с входящим трафиком работает?

тебе описание алгоритма нужно или впечатления от практического использования?

Впечатления :)

так не пробывал.