Jump to content
Калькуляторы

freebsd dummynet большие задержки в пингах

Для шейпа абонов по vpn-pptp используем конструкцию dummynet

 

${IPFW} pipe 20 config bw ${BW_128}Kbit/s mask src-ip 0xffffffff  # bm=128kbit
${IPFW} pipe 22 config bw ${BW_256}Kbit/s mask src-ip 0xffffffff delay -100ms  queue 100  # bm=256kbit
${IPFW} pipe 24 config bw ${BW_512}Kbit/s mask src-ip 0xffffffff delay -100ms  queue 100  # bm=512kbit
${IPFW} pipe 28 config bw ${BW_2M}Kbit/s mask src-ip 0xffffffff delay -100ms  queue 100  # bm=2Mbit
${IPFW} pipe 30 config bw ${BW_4M}Kbit/s mask src-ip 0xffffffff delay -100ms  queue 100  # bm=4Mbit
${IPFW} pipe 32 config bw ${BW_8Mb}Mbit/s mask src-ip 0xffffffff delay -100ms queue 100   # bm=8Mbit

${IPFW} add pipe tablearg all from "table(3)" to any in via  ${VPN_IFACES}

${IPFW} pipe 21 config bw ${BW_128}Kbit/s mask dst-ip 0xffffffff  # bw=128kbit
${IPFW} pipe 23 config bw ${BW_256}Kbit/s mask dst-ip 0xffffffff delay -100ms queue 100  # bw=256kbit
${IPFW} pipe 25 config bw ${BW_512}Kbit/s mask dst-ip 0xffffffff delay -100ms  queue 100 # bw=512kbit
${IPFW} pipe 29 config bw ${BW_2M}Kbit/s mask dst-ip 0xffffffff delay -100ms  queue 100 # bw=2Mbit
${IPFW} pipe 31 config bw ${BW_4M}Kbit/s mask dst-ip 0xffffffff delay -100ms  queue 100 # bw=4Mbit
${IPFW} pipe 33 config bw ${BW_8Mb}Mbit/s mask dst-ip 0xffffffff delay -100ms queue 100  # bw=8Mbit

${IPFW} add pipe tablearg all from any to "table(2)" out via  ${VPN_IFACES}

 

сейчас неско

сейчас несколько абонов подкл непосредственно по ethernet, дописав правил

#vlan170
#${IPFW} add pipe  tablearg all from "table(9)"  to any in via ${eth_inet0_iface}
${IPFW} add  allow all from ${eth_inet0_net} to any in via  ${eth_inet0_iface}
${IPFW} add  allow all from ${eth_inet_net} to any out via  ${inet_if}

#in traffic
${IPFW} add  allow all from any  to ${eth_inet_net} in via ${inet_if}
#vlan170
${IPFW} add pipe tablearg all from any to "table(8)" out via  ${eth_inet0_iface}
${IPFW} add  allow all from any  to ${eth_inet0_net} out via ${eth_inet0_iface}

те используются теже конфиги pipe для шейпа по vlan, что и по vpn

 

но при допустим тарифе в 1мбит по впн - получаем стабильные пинги до 100мс, а по влану прыгующий пинг до 400-500мс

 

почему такое может происходить ?

может какие-нить настройки sysctl поправить ?

Edited by Mechanic

Share this post


Link to post
Share on other sites

${IPFW} pipe 20 config bw ${BW_128}Kbit/s mask src-ip 0xffffffff # bm=128kbit

${IPFW} pipe 22 config bw ${BW_256}Kbit/s mask src-ip 0xffffffff delay -100ms queue 100 # bm=256kbit

 

Длины очередей слишком большие, для таких малых скоростей нужно уменьшить хотя бы до 20 пакетов. Кроме того нужно установить net.inet.ip.dummynet.io_fast=1.

Edited by photon

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Вы случаем не пускаете трафик последовательно через несколько пайпов? Возможно проблемы с задержками возникают из-за этого. Также стоит избавиться от нагромождения конфигурации на одной машине: vpn-терминатор, вланы, шейпинг. Когда понаворочено много всего, определить источник проблемы гораздо труднее. Для простоты и надежности нужно разносить функционал по отдельным машинам.

Edited by photon

Share this post


Link to post
Share on other sites

нет, тут же явно видно, что траф идет через разные интерфейсы

подсети для впн использованы серые, и одна /24 белая

для влан используются другие белые /24

попробую отделить вланы от впн

Share this post


Link to post
Share on other sites

Данная проблема тут уже обсуждалась - поищите.

Share this post


Link to post
Share on other sites

помнится читал, никак не думал, что сам столкнусь

сейчас попробую найти

если у кого есть закладка- запостите адрес плиз

 

вот нашел http://forum.nag.ru/forum/index.php?showto...46103&st=40

кстати Вы задавали такой вопрос по задержке, но что-то решения я так и не увидел в посте.

Как Вы разрешили ситуацию с пингами ?

Edited by Mechanic

Share this post


Link to post
Share on other sites

Еще можно HZ в конфиге ядра попробовать увеличить и пересобрать. Максимум до 4000, больше не надо. По идее, уменьшение гранулярности должно приводить к меньшим задержкам при проходе пакетов через token bucket.

Edited by photon

Share this post


Link to post
Share on other sites

Ну вот мне и ответили

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

Ну ладно:

 

Гранулярность времени в 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.

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

Для себя я решил проблему переходом на ng_car.

Share this post


Link to post
Share on other sites

перечитывал несколько раз это абзац!

почему при vpn-pptp такой проблемы -нет ?

Используете ng_car+ipfw ,на каждого абона создается нода ?

 

Share this post


Link to post
Share on other sites
перечитывал несколько раз это абзац!

почему при vpn-pptp такой проблемы -нет ?

Используете ng_car+ipfw ,на каждого абона создается нода ?

Мы не используем VPN и прочие PPxxx. Статические внешние IP-адреса.

Да на каждого абонента создается нода, самописные скрипты на perl.

Share this post


Link to post
Share on other sites
Мы не используем VPN и прочие PPxxx. Статические внешние IP-адреса.

Да на каждого абонента создается нода, самописные скрипты на perl.

И трафик классифицируется наверняка с помощью netgraph tablearg. Скажите, а какие пакетрейты/сколько юзеров в этом случае можно обсчитать на одной машине? Интересно сравнить с dummynet. По сути ng_car -- это очередная реализация token bucket, но в виде ноды Netgraph.
Edited by photon

Share this post


Link to post
Share on other sites
перечитывал несколько раз это абзац!

почему при vpn-pptp такой проблемы -нет ?

Используете ng_car+ipfw ,на каждого абона создается нода ?

Мы не используем VPN и прочие PPxxx. Статические внешние IP-адреса.

Да на каждого абонента создается нода, самописные скрипты на perl.

к такой же схеме и пытаемся привести, но проблемы с шейпером

буду пробовать нарезать полосу через ng_car

Share this post


Link to post
Share on other sites

подскажите плиз, как реализовывали переход с тарифа на тариф ?

удаляли ноду или переконфигурировали ?

Если возможно покажите пожалуйста скрипт.

Share this post


Link to post
Share on other sites
И трафик классифицируется наверняка с помощью netgraph tablearg. Скажите, а какие пакетрейты/сколько юзеров в этом случае можно обсчитать на одной машине? Интересно сравнить с dummynet. По сути ng_car -- это очередная реализация token bucket, но в виде ноды Netgraph.

 

В самой плохой конфигурации примерно ~150Kpps

 

Вот эта конфигурация - 7.0-RELEASE-p12

# ngctl list
There are 635 total nodes:

 

#ipfw show
02300   netgraph tablearg ip from table(11) to any out via vlan5
02400   netgraph tablearg ip from any to table(10) in via vlan5
02500   netgraph tablearg ip from table(16) to any out via vlan5
02600   netgraph tablearg ip from any to table(15) in via vlan5
02700   netgraph tablearg ip from table(21) to any out via vlan5
02800   netgraph tablearg ip from any to table(20) in via vlan5
02900   netgraph tablearg ip from table(26) to any out via vlan5
03000   netgraph tablearg ip from any to table(25) in via vlan5
03100   netgraph tablearg ip from table(31) to any out via vlan5
03200   netgraph tablearg ip from any to table(30) in via vlan5
03300   netgraph tablearg ip from table(36) to any out via vlan5
03400   netgraph tablearg ip from any to table(35) in via vlan5
03500   netgraph tablearg ip from table(41) to any out via vlan5
03600   netgraph tablearg ip from any to table(40) in via vlan5
03700   netgraph tablearg ip from table(45) to any out via vlan5
03800   netgraph tablearg ip from any to table(46) in via vlan5
65535 328167268897 165734160073033 allow ip from any to any

 

Ну и top:

last pid: 56714;  load averages:  0.55,  0.38,  0.27                                                                                                                                     up 77+00:00:30  08:52:47
83 processes:  5 running, 62 sleeping, 16 waiting
CPU states:  0.0% user,  0.0% nice,  7.7% system,  0.4% interrupt, 91.9% idle
Mem: 26M Active, 234M Inact, 283M Wired, 56K Cache, 214M Buf, 3372M Free
Swap: 2048M Total, 2048M Free

  PID USERNAME  PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
   12 root      171 ki31     0K    16K CPU2   2 1818.6 100.00% idle: cpu2
   13 root      171 ki31     0K    16K CPU1   1 1793.9 100.00% idle: cpu1
   14 root      171 ki31     0K    16K RUN    0 1789.2 99.56% idle: cpu0
   11 root      171 ki31     0K    16K CPU3   3 1195.4 54.94% idle: cpu3
   27 root      -68    -     0K    16K -      3 612.1H 45.06% em2 taskq
   15 root      -44    -     0K    16K WAIT   3 159.2H  1.46% swi1: net

 

Иногда em2 tasq - поднимается до 60%, но я вообще не слежу что там за трафик и прочее.

Если случится em2 tasq - 100%, то:

развести IN/OUT по разным vlan-ам c различными физическими интерфейсами, шейпить out;

Если снова случится em2 tasq - 100%, то:

перезагрузиться с яндекс драйверами по два потока на ядро.

 

Максимально мне удавалось содать 4000 нод.

Вообще есть идея уйти даже ipfw и переписать на ng_bpf + ng_car - но это не скоро будет, знаний пока маловато.

 

Сравнивать с dummynet - ИМХО не стоит в dummynet, там динамические pipe-ы.

Share this post


Link to post
Share on other sites
подскажите плиз, как реализовывали переход с тарифа на тариф ?

удаляли ноду или переконфигурировали ?

Если возможно покажите пожалуйста скрипт.

Очевидно, что не стоит пересоздавать ноду, если ее можно переконфигурировать.

Скрипт выкладывать смысла нет - поверьте.

Есть модуль самописный Ratelimit.pm и четыре утилиты его использующие, по типу выполняемого действия create/delete/modify/on-boot.

Скрипты писал я - поэтому они написаны из рук вон плохо :)

 

Но если - прям надо, отправлю по почте.

Edited by Dm1try

Share this post


Link to post
Share on other sites

Сравнивать с dummynet - ИМХО не стоит в dummynet, там динамические pipe-ы.

Можно насоздавать кучу статических пайпов, а классифицировать с помощью правил pipe tablearg.

Edited by photon

Share this post


Link to post
Share on other sites

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

to Dm1try: тк нода создается непосредственно на юзера,соответственно конфигурится скорость по тарифу, по какой причине у вас используется несколько tablearg с разными таблицами и все на 1м интерфейсе ?

 

 

Share this post


Link to post
Share on other sites

По 2-е таблицы (входящий/исходящий) на ТП.

На одном интерфейсе потому, что так смаршрутизированно.

Share this post


Link to post
Share on other sites

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

С чего это вдруг статические пайпы должны приводить к тормозам? Тормоза не из-за того что в памяти какие-то лишние пайпы висят. Кстати, постоянное создание/удаление динамических пайпов при недостаточном размере хэша -- тоже одна из причин возникновения задержек. Следует убедиться, что net.inet.ip.dummynet.hash_size превышает число пользователей и увеличить эту переменную до нужного значения.

Edited by photon

Share this post


Link to post
Share on other sites

по 2 пайпа на юзера, у меня на насе до 1000 абонов крутится, итого получаем 2000 правил в ipfw, тут уже лучше юзать tablearg с динамич правилами

Share this post


Link to post
Share on other sites
по 2 пайпа на юзера, у меня на насе до 1000 абонов крутится, итого получаем 2000 правил в ipfw, тут уже лучше юзать tablearg с динамич правилами

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this