Давайте для простоты вопроса рассматривать трафик только в одну сторону: исходящий с точки зрения маршрутизатора, на котором настроены шейпинг или скорость интерфейса.
Эм. То есть, есть точка А и точка С, а точкой В между ними не подконтрольное нам узкое горло параметры линков с которым мы посмотреть не можем и требуется определить, это шейпер режет полосу или ограничение на уровне линка? В сфероконином случае однозначно не определить, ибо разнообразные аппаратные особенности железа и различия в алгоритмах ПО оборудования допускают слишком много трактовок. Опять же, шейпер можно настроить так, что он мало будет отличаться по внешним проявлениям от ограничения линка. В случае конкретных железок и ПО можно уже о чем-то более конкретном думать.
Хорошо, а еще по-другому спрошу. Если нужно ограничить скорость 10 Мбитами в секунду, лучше (для потребителя трафика) сделать это шейпером или установкой принудительной скорости интерфейса?
Шейпинг бывает разный, да и на сетевухах бывает несколько аппаратных очередей для демпфирования микробёрстов. В принципе, определить наличие высокоинтеллектуального шейпера можно по "grace window" в начале большой волны - обычно на несколько секунд (0.5-2с) дают больше, чем полоса (чтобы всякие короткие сессии быстро пролетали). Нативная скорость такого не даёт. Но определить это очень сложно, т.к. могут накладываться особенности всего промежуточного железа.
Если шейпинг совсем тупой, и на L2 с маленьким окном (коммутаторы джуника такое умеют), то определить можно по тому, что при шейпинге и вылете за полосу tcp сносит крышу в сусмерть, то есть всё плохо-плохо, даже если оверкоммит 5%, и только в пике.
Но правильно я понимаю, что принципиальной разницы быть не может? И в случае аппаратного ограничения и в случае программного шейпера мы можем а) начать ставить пакеты в очередь или несколько очередей б) и по заполнению очередей начать отбрасывать пакеты. Другого не дано! А всякий RED и прочий интеллект может быть как в программном шейпере, так и в аппаратной очереди.
Оригинальный RED вреден, к использованию годятся только модификации типа GRED. В интерфейсных очередях обычно нет столько памяти, чтобы реализовывать умный шейпинг - там полисер, которому вообще не нужна дополнительная память, он просто замеряет количество пробегающих пакетов за дельта-t и при превышении порога начинает дропать.
В первом случае работает только интерфейсная очередь FIFO с традиционно небольшим размером буфера на отправку и алгоритмом tail-drop, то есть при темпе поступления пакетов выше, чем успевает принять физика, всегда отбрасываются вновь поступающие пакеты. За счет небольшой длины FIFO задержка, вносимая очередью, минимальна
( ... )
Ага, спасибо за подробный ответ. При тупом rate-limit IMHO будет еще хуже, чем при ограничении скорости физическим линком, т.к. rate-limit не предполагает вообще никакой очереди, а в аппаратном интерфейсе она всё-таки есть.
Ну и помнится, что и на интерфейсах без сконфигурированной class based queuing бывает что-то отличное от FIFO, например на Serial можно было поставить fair-queue.
> rate-limit не предполагает вообще никакой очереди, а в аппаратном интерфейсе она всё-таки есть.
Интерфейсная очередь в любом случае никуда не девается, и при rate-limit тоже - трафик после любой программной обработки в интерфейс попадает через интерфейсную FIFO.
Comments 15
Reply
Reply
Reply
Reply
Если шейпинг совсем тупой, и на L2 с маленьким окном (коммутаторы джуника такое умеют), то определить можно по тому, что при шейпинге и вылете за полосу tcp сносит крышу в сусмерть, то есть всё плохо-плохо, даже если оверкоммит 5%, и только в пике.
Reply
Reply
Reply
Reply
Reply
Ну и помнится, что и на интерфейсах без сконфигурированной class based queuing бывает что-то отличное от FIFO, например на Serial можно было поставить fair-queue.
Reply
Интерфейсная очередь в любом случае никуда не девается, и при rate-limit тоже - трафик после любой программной обработки в интерфейс попадает через интерфейсную FIFO.
Reply
Leave a comment