[Giga-Byte]

Далее - по поводу net.inet.ip.dummynet.io_fast=1.

При моем трафике через pipe в 1s - 5 пакетов по 1480byte ~59Kbit/s - dummynet должен пропускать трафик без задержек, но такого не происходит. Почему мне не понятно.

А вот Вам информация к размышленю: 59Kbit/s это 59 * 86400 ~ 5Gbit/сутки. По Вашей логике получается, что пока Вы не пошлете 5Gbit трафика задержек быть не должно ;)

имхо не то, всмысле неправильное сопоставление.

"нормальный" трафик так не ходит.

 

да и вообще увидеть бы реальные тесты хорошо разбирающегося человека, что будет менее нагружать серверы (WFQ или WF2Q+) и не создавать неудобства абонетам

имхо, не вижу смысла использовать WF2Q+ на pppoe/pptp концентраторе

Изменено 25 декабря, 2008 пользователем Giga-Byte

[Dm1try]

А вот Вам информация к размышленю: 59Kbit/s это 59 * 86400 ~ 5Gbit/сутки. По Вашей логике получается, что пока Вы не пошлете 5Gbit трафика задержек быть не должно ;)

Неверно. Сколько трафика пройдет через pipe здесь абсолютно не причем.

There are two modes of dummynet operation: ``normal'' and ``fast''. The

``normal'' mode tries to emulate a real link: the dummynet scheduler

ensures that the packet will not leave the pipe faster than it would on

the real link with a given bandwidth. The ``fast'' mode allows certain

packets to bypass the dummynet scheduler (if packet flow does not exceed

pipe's bandwidth). This is the reason why the ``fast'' mode requires

less CPU cycles per packet (on average) and packet latency can be signif-

icantly lower in comparison to a real link with the same bandwidth. The

default mode is ``normal''. The ``fast'' mode can be enabled by setting

the net.inet.ip.dummynet.io_fast sysctl(8) variable to a non-zero value.

И во всем этом меня очень смущает фраза: ... certain packets to bypass the dummynet scheduler.

Изменено 26 декабря, 2008 пользователем Dm1try

[z18]

А вот Вам информация к размышленю: 59Kbit/s это 59 * 86400 ~ 5Gbit/сутки. По Вашей логике получается, что пока Вы не пошлете 5Gbit трафика задержек быть не должно ;)

Неверно. Сколько трафика пройдет через pipe здесь абсолютно не причем.

There are two modes of dummynet operation: ``normal'' and ``fast''. The

``normal'' mode tries to emulate a real link: the dummynet scheduler

ensures that the packet will not leave the pipe faster than it would on

the real link with a given bandwidth. The ``fast'' mode allows certain

packets to bypass the dummynet scheduler (if packet flow does not exceed

pipe's bandwidth). This is the reason why the ``fast'' mode requires

less CPU cycles per packet (on average) and packet latency can be signif-

icantly lower in comparison to a real link with the same bandwidth. The

default mode is ``normal''. The ``fast'' mode can be enabled by setting

the net.inet.ip.dummynet.io_fast sysctl(8) variable to a non-zero value.

И во всем этом меня очень смущает фраза: ... certain packets to bypass the dummynet scheduler.

*sigh* Объясню: эти самые "certain packets" - это которые "does not exceed pipe's bandwidth".

В вашем случае bandwidth превышается, поэтому Вы наблюдаете задержки.

 

[Dm1try]

Bandwidth у меня 64Kbit/s.

При моем трафике через pipe в 1s - 5 пакетов по 1480byte ~59Kbit/s - dummynet должен пропускать трафик без задержек, но такого не происходит. Почему мне не понятно.

Где превышение?

[z18]

Bandwidth у меня 64Kbit/s.

При моем трафике через pipe в 1s - 5 пакетов по 1480byte ~59Kbit/s - dummynet должен пропускать трафик без задержек, но такого не происходит. Почему мне не понятно.

Где превышение?

Я же Вам предлагал поразмышлять...

Ну ладно:

 

Гранулярность времени в dummynet'е при стандартном ядре (HZ=1000) 1ms, т.е. 64Kbit/s это 64Bit/ms. В Вашем примере размер пакета 1500 байт

(1472 + 8 + 20 = 1500, a не 1480, как Вы полагаете, но это здесь не Важно), т.е. 1500*8=12Kbit. 12Kbit через трубу с пропускной способностью 64Bit/tick без задержек проехать никак не могут.

 

Можно посчитать, какая должна быть задержка: 12000/64 = 187.5ms в одну сторону. В Вашем примере есть и обратная труба, т.е. задержка

на Ваши пинги должна быть 187.5 * 2 = 375ms.

Знакомая цифра? ;)

[Dm1try]

Да, спасибо. Действительно очень похоже на правду. Пойду читать дальше.

[sdkikilo]

По моему личному опыту эксплуатации сервера доступа на базе построенного на FreeBSD 7.0-RELEASE + mpd5, могу сказать, что за почти год эксплуатации подобных проблем не наблюдалось. Клиентов правда немного было (150-200 в онлайне), и не pptp использовался (ума не приложу, зачем его для этих целей вообще применять...), а pppoe.

Попробуйте для начала выкинуть весь тот огород из фаерволов, который у вас там есть, и взять один, например pf, и использовать только его. Функционала вам хватит с головой. Дополнительно можно добавить polling.

 

З.Ы. А вообже, я согласен с господином Jab-ом... Вот только убийство, это грех. :-)

З.Ы.Ы. Резать скорость в "точке доступа клиента" не всегда правильно, поскольку вы можете продавать клиенту интернет анлимом, а внутренние ресурсы отгружать помегабайтно и без лимитирования трафика. Если вводить подобные ограничения в точке доступа при помощи фаервола, получится огород из правил.

Изменено 29 декабря, 2008 пользователем sdkikilo

[tankistua]

на ipfw мир клином сошелся ? есть еще pf - очень неплох.

Ну это была лирика:)

 

Может проверить догадки по-поводу двойного шейпа - предлагаю нарезать скорость в 2 раза больше чем надо.

[snark]

mikrotik умеет Change-Of-Authorization

умеет, но только для хотспота, а для всего остального - нет!

[Giga-Byte]

mikrotik умеет Change-Of-Authorization

умеет, но только для хотспота, а для всего остального - нет!

в какой версии микротика?

[snark]

ЕМНИМС во всех более-менее новых ...

насчет СоА почитайте тут, там коротко и ясно ...