Giga-Byte Опубликовано 25 декабря, 2008 (изменено) · Жалоба Далее - по поводу 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dm1try Опубликовано 26 декабря, 2008 (изменено) · Жалоба А вот Вам информация к размышленю: 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
z18 Опубликовано 26 декабря, 2008 · Жалоба А вот Вам информация к размышленю: 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 превышается, поэтому Вы наблюдаете задержки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dm1try Опубликовано 27 декабря, 2008 · Жалоба Bandwidth у меня 64Kbit/s. При моем трафике через pipe в 1s - 5 пакетов по 1480byte ~59Kbit/s - dummynet должен пропускать трафик без задержек, но такого не происходит. Почему мне не понятно. Где превышение? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
z18 Опубликовано 27 декабря, 2008 · Жалоба 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. Знакомая цифра? ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dm1try Опубликовано 27 декабря, 2008 · Жалоба Да, спасибо. Действительно очень похоже на правду. Пойду читать дальше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdkikilo Опубликовано 29 декабря, 2008 (изменено) · Жалоба По моему личному опыту эксплуатации сервера доступа на базе построенного на FreeBSD 7.0-RELEASE + mpd5, могу сказать, что за почти год эксплуатации подобных проблем не наблюдалось. Клиентов правда немного было (150-200 в онлайне), и не pptp использовался (ума не приложу, зачем его для этих целей вообще применять...), а pppoe. Попробуйте для начала выкинуть весь тот огород из фаерволов, который у вас там есть, и взять один, например pf, и использовать только его. Функционала вам хватит с головой. Дополнительно можно добавить polling. З.Ы. А вообже, я согласен с господином Jab-ом... Вот только убийство, это грех. :-) З.Ы.Ы. Резать скорость в "точке доступа клиента" не всегда правильно, поскольку вы можете продавать клиенту интернет анлимом, а внутренние ресурсы отгружать помегабайтно и без лимитирования трафика. Если вводить подобные ограничения в точке доступа при помощи фаервола, получится огород из правил. Изменено 29 декабря, 2008 пользователем sdkikilo Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tankistua Опубликовано 2 января, 2009 · Жалоба на ipfw мир клином сошелся ? есть еще pf - очень неплох. Ну это была лирика:) Может проверить догадки по-поводу двойного шейпа - предлагаю нарезать скорость в 2 раза больше чем надо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snark Опубликовано 3 января, 2009 · Жалоба mikrotik умеет Change-Of-Authorization умеет, но только для хотспота, а для всего остального - нет! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 3 января, 2009 · Жалоба mikrotik умеет Change-Of-Authorizationумеет, но только для хотспота, а для всего остального - нет! в какой версии микротика? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snark Опубликовано 4 января, 2009 · Жалоба ЕМНИМС во всех более-менее новых ... насчет СоА почитайте тут, там коротко и ясно ... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...