Надо почитать... Интересно, входящий она может шейпить? ;-)

Входящий откуда? С клиентов? Тогда глупый вопрос.

Интересно-интересно. Как же это она может шейпить "исключая" потерю пакетов?Это как минимум требует управление потоком, что отсутствует в базовом IP. Соответственно при шейпинге UDP хоть ты тресни, но потери будут. У TCP тоже будут потери пакетов, хотя потери данных естественно не будет.Единственное исключение - шейпинг собственных пакетов машины. Но это так малоинтересно, что даже писать не стоило. Кстати, у них самих ничего про "исключающего потерю пакетов" не написано.

Ничего не пишут про то, какой ценой достигается такая точность. А цена
явно есть.

> Входящий откуда? С клиентов? Тогда глупый вопрос.

почему же глупый? иногда и это надо.

> Ничего не пишут про то, какой ценой достигается такая точность. А цена
явно есть.

из их FAQ:
The processor itself may have enough performance if it is Pentium 4 or above.

> Интересно, входящий она может шейпить?

Не помню, как называется такой проект. Вот только не пойму, кому это надо. Нет денег на первопень в качестве файрволла с шейпером?

> Нет денег на первопень в качестве файрволла с шейпером

у меня firewall на 1м пне cbq не потянул (точнее тянул только 2 активных соединения, если больше, то все вырождались в ноль)

Скажите, уважаемые, какой ещё входящий шейпинг?

Шейпинг через дроп? Толку от него на входящем как от мёртвому припарки.

Насколько я могу судить, нормальной реализации шейпинга TCP через window scaling - единственной более-менее корректной возможной реализации входящего шейпинга без использования дополнительных протоколов - до сих пор не существует.

Или я ошибаюсь?

Regards, KdF

> какой ещё входящий шейпинг?

Грубо говоря, теоретически, если _задерживать_ отправку подтверждения о приёме пакета, то отправитель будет слать пакеты реже (он должен получить подтверждение о приёме tcp-пакета перед посылкой следующего). На практике, однако, толку от этого обычно мало.

Я почему и предложил сразу машинку с двумя сетевухами втыкать. Касаемо первопня, возможно, и погорячился (ибо всегда можно наворотить такие правила, что и P-III захлебнётся). Просто по опыту, tbrconfig (100 мбит от "провайдера" -> 192 кбит на всю контору, как приходилось резать на прошлой работе) на P-133 и OpenBSD не грузил камень вообще (la около 0,02 ... 0,1).

> Шейпинг через дроп? Толку от него на входящем как от мёртвому припарки.

Логично. Ибо трафик провайдером уже посчитан. ;-)

>Грубо говоря, теоретически, если _задерживать_ отправку подтверждения о приёме пакета, то отправитель будет слать пакеты реже (он должен получить подтверждение о приёме tcp-пакета перед посылкой следующего). На практике, однако, толку от этого обычно мало.

Естественно. Потому что подтверждается получение ОКНА, а не каждого пакета в отдельности. А окно может быть и 100 пакетов и больше.

yea but мозг

> Входящий откуда? С клиентов?
иногда очень надо -например када клиент подцепил вирус и от него пакеты валятся со всей дури по 100 мбитам.:(

> Потому что подтверждается получение ОКНА
Да быть такого не может :-)