[XeonVs]

а можно ли нормально развернуть в ng_car такую конструкцию?

С ходу не сообразил :/

 

pipes="32 64 128 256 384 512 768 1000 2000 4000 8000 10000 etc"

 

users=12345

 

$fwcmd table $users flush

 

 

number=1

 

for pipe in $pipes; do

ipnum=`expr $number + 1000`

opnum=`expr $number + 2000`

$fwcmd add 700 pipe $ipnum ip from any to "table($users,$number)"

$fwcmd add 700 pipe $opnum ip from "table($users,$number)" to any

$fwcmd pipe $ipnum config bw ${pipe}kbit/s mask dst-ip 0xffffffff

$fwcmd pipe $opnum config bw ${pipe}kbit/s mask src-ip 0xffffffff

number=`expr $number + 1`

done

 

машина выполняет только функции шейпера.

Изменено 5 марта, 2009 пользователем XeonVs

[McLaut]

здесь.

[jab]

 

Там нет никакой статистики по производительности. Кроме того, есть сомнения, что автор тюнил dummynet.

[IvanI]

применительно к MPD - неправельно, MPD компелица с опцией NG_CAR и ему передаются данные о правилах + шейперах/лимитах через радиус, себе буду строить подобный описаному шейпер на бордер(для реальников)

[Dm1try]

Вообще-то, оригинал, по которому написанна данная статья - написал я. IPFW у меня не тюнится никак. Собственно, огромных нагрузок (pps и т.д.) /ната у нас нет (только реальные IP-адреса).

Постоянно активны:

ngctl list
There are 394 total nodes:

Можно создать до 4000 тысяч без проблем.

Железо:

em2@pci0:5:1:0:    class=0x020000 card=0x10018086 chip=0x10268086 rev=0x04 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82545GM Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet

Трафик:

# netstat -w 1 -I em2
            input          (em2)           output
   packets  errs      bytes    packets  errs      bytes colls
     33727     0   16359298      32960     0   15792744     0
     31920     0   14872219      30883     0   14157980     0
     32341     0   15575164      31364     0   14875144     0
     32346     0   15401046      31329     0   14665227     0
     31519     0   14920089      30553     0   14195906     0
     30755     0   14310397      29844     0   13648961     0

Нагрузка:

last pid: 33046;  load averages:  0.57,  0.69,  0.67                                                                                                                                   up 35+03:50:38  14:47:51
87 processes:  8 running, 64 sleeping, 15 waiting
CPU:  1.4% user,  0.0% nice, 12.7% system,  6.1% interrupt, 79.8% idle
Mem: 187M Active, 3139M Inact, 393M Wired, 185M Cache, 214M Buf, 8504K Free
Swap: 1024M Total, 11M Used, 1013M Free, 1% Inuse

  PID USERNAME  PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
   11 root      171 ki31     0K    16K RUN    3 794.6H 91.99% idle: cpu3
   12 root      171 ki31     0K    16K CPU2   2 787.2H 89.70% idle: cpu2
   13 root      171 ki31     0K    16K RUN    1 789.8H 85.79% idle: cpu1
   14 root      171 ki31     0K    16K CPU0   0 615.8H 58.15% idle: cpu0
   27 root      -68    -     0K    16K RUN    0 222.6H 42.68% em2 taskq
   17 root      -44    -     0K    16K CPU2   2  87.4H 20.65% swi1: net
3990 root       50    0 12604K  3192K CPU1   1 750:05 12.89% zebra
26137 flowtools  48    0   175M   162M select 1 204:39  7.47% flow-capture
   15 root      -32    -     0K    16K WAIT   0 282:01  0.29% swi4: clock sio

 

Собираюсь менять сетевую на PT Dual, сейчас слишком много прерываний.

А вообще идея не оригинальна, я взял ее с этого форума:

http://forum.nag.ru/forum/index.php?showto...mp;#entry353063

И просто дописал свои скрипты управления на perl.

Изменено 6 марта, 2009 пользователем Dm1try

[jab]

 

Я и говорю, спор о нагрузках безпредметен, могу показать десятикратно большую нагрузку на dummynet.

[Dm1try]

Я и не спорю, просто использую ng_car и все - мне так удобнее :)

[[GP]Villi]

ipfw pipe show | grep queues | wc -l
2034

 

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

при этом

 

   23 root          1 -68 -187     0K     8K WAIT   0 819.1H 46.14% irq257: em1
   22 root          1 -68 -187     0K     8K RUN    3 683.3H 38.43% irq256: em0
   10 root          1 171   52     0K     8K RUN    3 1232.0 30.76% idle: cpu3
   13 root          1 171   52     0K     8K RUN    0 1069.2 30.76% idle: cpu0
   33 root          1 -68    0     0K     8K CPU0   0 122.2H  0.00% dummynet

 

netstat -w1 -I em1
            input          (em1)           output
   packets  errs      bytes    packets  errs      bytes colls
     37712     0   35782334      31316     0   16704763     0
     36787     0   34811242      30792     0   16398721     0
     37151     0   34089465      31532     0   17864329     0
     40428     0   36155407      35092     0   22683580     0
     38633     0   34725004      33464     0   20162830     0

 

ipfw show
00200  95485682608  62946864332871 pipe tablearg ip from any to table(20) out via em1
00201 103576342836  88106682190668 pipe tablearg ip from table(21) to any in via em1
65000 522158341682 397282637605173 allow ip from any to any
65535        10422          904982 allow ip from any to any

 

правило 200 и 201 это соответственно входящий и исходящий. правило 65000 те кто не шейпится.

 

6.3-STABLE FreeBSD

net.inet.ip.fw.one_pass: 1
net.inet.ip.dummynet.io_fast: 1

dev.em.1.%desc: Intel(R) PRO/1000 Network Connection Version - 6.7.3
dev.em.1.rx_int_delay: 600
dev.em.1.tx_int_delay: 600
dev.em.1.rx_abs_int_delay: 1000
dev.em.1.tx_abs_int_delay: 1000

em1@pci1:0:1:   class=0x020000 card=0x125f8086 chip=0x105f8086 rev=0x06 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'PRO/1000 PF'
    class      = network
    subclass   = ethernet

 

 

 

 

Изменено 6 марта, 2009 пользователем [GP]Villi

[XeonVs]

здесь.

это я уже читал...

 

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

 

остается вопрос о производительности, как все это будет на SMP паралелится.

[McLaut]

остается вопрос о производительности, как все это будет на SMP паралелится.

Насколько я понимаю - на уровне ядра.

[jab]

остается вопрос о производительности, как все это будет на SMP паралелится.

Насколько я понимаю - на уровне ядра.

Какого еще ядра ? Прошлогодний мартовский патч Мотина в 7.1-RELEASE вошел или нет ? И не он ли породил всю эту кучу воплей про mpd netgraph panic на 7.1 ?

[McLaut]

остается вопрос о производительности, как все это будет на SMP паралелится.

Насколько я понимаю - на уровне ядра.

Какого еще ядра ? Прошлогодний мартовский патч Мотина в 7.1-RELEASE вошел или нет ? И не он ли породил всю эту кучу воплей про mpd netgraph panic на 7.1 ?

Если я правильно понял - мы говорили об ng_car...

[jab]

Какого еще ядра ? Прошлогодний мартовский патч Мотина в 7.1-RELEASE вошел или нет ? И не он ли породил всю эту кучу воплей про mpd netgraph panic на 7.1 ?

Если я правильно понял - мы говорили об ng_car...

А с каких пор ng_car параллелится отдельно от netgraph ?

[XeonVs]

А я тут на мини-стенде потестировал... Распаралеливается оно конечно поболее чем dummynet, но сильного эффекта не заметил на стендовой машинке.

Переодически ловится паника во время перезагрузки правил фаервола под нагрузкой при исспользовани ng_ipfw + ng_car.

 

Подробно расписано в http://groups.google.com/group/fido7.ru.un...07d1ba4e76675d#

 

если у кого есть мысли, буду рад.

Изменено 9 марта, 2009 пользователем XeonVs

[sid1333]

А я тут на мини-стенде потестировал... Распаралеливается оно конечно поболее чем dummynet, но сильного эффекта не заметил на стендовой машинке.

Переодически ловится паника во время перезагрузки правил фаервола под нагрузкой при исспользовани ng_ipfw + ng_car.

 

Подробно расписано в http://groups.google.com/group/fido7.ru.un...07d1ba4e76675d#

 

если у кого есть мысли, буду рад.

На 7.0 и 7.1 машинка обнаружил непонятный глюк в ng_car - полностью прекращает выполнять свою задачу :)

То есть нода ng_car не ограничивает скорость абонента до приписанных ему xxМбит - выдаёт почти полною сотню. Причины сего непонятны. Попытка пересоздать ноду приводит к краху и перезагрузке тачки, даже если сначала доступ абоненту закрыть. Ядро без дебага, так что проверить нечего.

 

Машинка держит сейчас около 900 юзеров, на каждого безлимитчика по ноде. Лимитчики гонятся в обход netgraph.

[make.kernel]

А не подскажут ли знающие, что значит acpi_task в приведенной ниже ситуации

last pid: 76812;  load averages:  1.68,  1.97,  2.03                                                                                                                                   up 0+01:37:40  21:06:44
231 processes: 5 running, 215 sleeping, 11 waiting
CPU 0:  1.5% user,  0.0% nice, 60.2% system,  2.3% interrupt, 36.1% idle
CPU 1:  0.8% user,  0.0% nice, 19.5% system, 59.4% interrupt, 20.3% idle
CPU 2:  0.8% user,  0.0% nice, 45.1% system,  0.0% interrupt, 54.1% idle
CPU 3:  3.8% user,  0.0% nice, 41.4% system,  0.8% interrupt, 54.1% idle
Mem: 186M Active, 78M Inact, 141M Wired, 32K Cache, 199M Buf, 1595M Free
Swap: 4096M Total, 4096M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
   22 root          1 -52    -     0K     8K WAIT   1  66:18 68.99% irq9: acpi0
   11 root          1 171 ki31     0K     8K RUN    3  54:11 52.78% idle: cpu3
   12 root          1 171 ki31     0K     8K CPU2   2  48:37 46.88% idle: cpu2
   14 root          1 171 ki31     0K     8K RUN    0  39:17 39.26% idle: cpu0
    7 root          1   8    -     0K     8K -      0  21:05 21.97% acpi_task_1
    8 root          1   8    -     0K     8K -      2  20:55 20.90% acpi_task_2
    6 root          1   8    -     0K     8K -      0  20:37 19.87% acpi_task_0
   13 root          1 171 ki31     0K     8K RUN    1  20:17 19.29% idle: cpu1
  152 root          1  43    -     0K     8K WAIT   3  10:22 11.28% em0_rx_kthread_2
  153 root          1  43    -     0K     8K WAIT   0  10:21 11.18% em0_rx_kthread_3
   29 root          1  43    -     0K     8K WAIT   2   9:19 11.08% em1_rx_kthread_0
   25 root          1  43    -     0K     8K WAIT   3  10:21 10.99% em0_rx_kthread_0
  157 root          1  43    -     0K     8K WAIT   1   9:18 10.99% em1_rx_kthread_3
  156 root          1  43    -     0K     8K WAIT   2   9:18 10.79% em1_rx_kthread_2
   26 root          1  43    -     0K     8K WAIT   2  10:22 10.60% em0_rx_kthread_1
   30 root          1  43    -     0K     8K WAIT   0   9:18 10.60% em1_rx_kthread_1
3102 root          2   4    0 75516K 24188K select 2   0:00  3.27% mpd5

Жалко столько проца ему отдавать. А в то-же время на соседнем тазике

last pid:  6325;  load averages:  0.76,  0.77,  0.69                                                                                                                                   up 0+01:42:06  21:13:27
163 processes: 5 running, 146 sleeping, 12 waiting
CPU 0:  1.5% user,  0.0% nice,  6.0% system,  1.5% interrupt, 91.0% idle
CPU 1:  2.2% user,  0.0% nice, 25.4% system,  6.0% interrupt, 66.4% idle
CPU 2:  0.7% user,  0.0% nice,  6.7% system,  0.0% interrupt, 92.5% idle
CPU 3:  0.0% user,  0.0% nice, 35.1% system,  1.5% interrupt, 63.4% idle
Mem: 313M Active, 88M Inact, 110M Wired, 96K Cache, 112M Buf, 1489M Free
Swap: 2048M Total, 2048M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
   12 root          1 171 ki31     0K     8K CPU2   2  97:36 93.65% idle: cpu2
   14 root          1 171 ki31     0K     8K RUN    0  95:06 92.53% idle: cpu0
   13 root          1 171 ki31     0K     8K RUN    1  77:35 66.46% idle: cpu1
   11 root          1 171 ki31     0K     8K CPU3   3  73:13 62.30% idle: cpu3
   23 root          1 -68    -     0K     8K -      3  26:49 33.98% em0 taskq
   24 root          1 -68    -     0K     8K -      0  15:34 19.87% em1 taskq
   15 root          1 -44    -     0K     8K WAIT   2   7:40  9.57% swi1: net
2573 root          2   4    0 26328K 18056K select 0   0:00  2.54% mpd5

Процессоры и материнка одинаковые. На первой машине ядро 7.1-STABLE с драйвером яндекса, на второй 7.1-RELEASE с родным. Это 2 рррое-наса нагрузка +-10Кппс одинаковая.

Изменено 10 марта, 2009 пользователем make.kernel

[IvanI]

Таймер?

sysctl -a | grep kern.timecounter.hardware

Одинаковые?

[make.kernel]

kern.timecounter.hardware: ACPI-fast на обоих

 

Извините, протормозил, acpi_task решилось обновлением БИОСа, давно такого не видел. Но вылез другой прикол:

 

   packets  errs      bytes    packets  errs      bytes colls
    102737     0   52509060     101377     0   56863514     0
    104262     0   52448651     102943     0   56822812     0
    106238     0   55123343     103235     0   57243318     0
    108201     0   56336784     106728     0   58530469     0
    111987     0   58451369     111049     0   61492794     0
    175798     1   61642073     168761     0  100777583     0
    105600     0   53906894     104183     0   57477022     0
    104290     1   53871796     102437     0   58296290     0
    106930     5   57998758     104092     0   59736757     0
    101461     1   52865858      99315     0   56326309     0
     89485 4294967290   44776623      87829     0   48080196     0
     88958     3   43280210      86568     0   44787257     0
Read from remote host ***.**.**.*: No route to host

На драйверах яндекса, аптайм часов 12 у машины был.

[IvanI]

Возвращаясь к своим тестам.

С тестом ната решил немутить, а вот шейпер хочу протестить, пока ненашел ничего существенного по тюнингу DUMMINET под большие потоки (10-100 Мбит), подскажите пожалуста, кто как тюнит?

[jab]

Возвращаясь к своим тестам.

С тестом ната решил немутить, а вот шейпер хочу протестить, пока ненашел ничего существенного по тюнингу DUMMINET под большие потоки (10-100 Мбит), подскажите пожалуста, кто как тюнит?

для мелких ( 100Mbits/100kpps ) потоков на современном железе никакой тюнинг не нужен. Главное не допускать прохождение пакетов через

кучу правил.

[[GP]Villi]

net.inet.ip.dummynet.io_fast: 1

 

а больше там и нечего тюнить вроде

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

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

 

PS интересно кстати на сколько увеличивается загрузка машины предположим при просто перекидывании пакетов с интерфейса на интерфейс, или то же самое уже с ipfw и три правила:

шейп исхода - шейп входа - default accept (шейп на одном интерфейсе) или шейп исхода - шейп входа - default accept (вход на одном исход на другом) или просто три любых правила.

Изменено 25 марта, 2009 пользователем [GP]Villi

[jab]

PS интересно кстати на сколько увеличивается загрузка машины предположим при просто перекидывании пакетов с интерфейса на интерфейс, или то же самое уже с ipfw и три правила:

шейп исхода - шейп входа - default accept (шейп на одном интерфейсе) или шейп исхода - шейп входа - default accept (вход на одном исход на другом) или просто три любых правила.

Что мешает взять машину и измерить ?

[[GP]Villi]

отсутствие машины, и наверное еще нужного количества знаний)

[IvanI]

Примерно составил программу тестов, но остались некотрые вопросы.

 

1 тесты с думинет с

net.inet.ip.dummynet.io_pkt_fast: 0
net.inet.ip.dummynet.io_fast: 0

 

2 тесты с думинет с

net.inet.ip.dummynet.io_pkt_fast: 1
net.inet.ip.dummynet.io_fast: 1

 

3 тесты с NG_CAR mode=2

 

4 тесты с NG_CAR mode=3

 

Примерные конфиги:

ipfw pipe 1 config bw 500Mbit/s
ipfw pipe 2 config bw 500Mbit/s
ipfw pipe 3 config bw 500Mbit/s
ipfw pipe 4 config bw 500Mbit/s
ipfw pipe 5 config bw 500Mbit/s
ipfw pipe 6 config bw 500Mbit/s

ipfw add 100 allow all from any to any out

ipfw add 200 pipe 1 all from aaa to any
ipfw add 300 pipe 2 all from bbb to any
ipfw add 400 pipe 3 all from ccc to any
ipfw add 500 pipe 4 all from ddd to any
ipfw add 600 pipe 5 all from eee to any
ipfw add 700 pipe 6 all from fff to any

 

ngctl mkpeer ipfw: car 1 upper
ngctl name ipfw:1 car_1
ngctl connect car_1: ipfw: lower 2
ngctl msg car_1: setconf { upstream= { cbs=100000 ebs=100000 cir=500000000 greenAction=1 yellowAction=1 redAction=2 mode=2 } downstream= { cbs=100000 ebs=100000 cir=500000000 greenAction=1 yellowAction=1 redAction=2 mode=2 } }

ngctl mkpeer ipfw: car 3 upper
ngctl name ipfw:3 car_3
ngctl connect car_3: ipfw: lower 4
ngctl msg car_3: setconf { upstream={ cbs=100000 ebs=100000 cir= 500000000 greenAction=1 yellowAction=1 redAction=2 mode=2 } downstream= { cbs=100000 ebs=100000 cir=500000000 greenAction=1 yellowAction=1 redAction=2 mode=2 } }

ngctl mkpeer ipfw: car 5 upper
ngctl name ipfw:5 car_5
ngctl connect car_5: ipfw: lower 6
ngctl msg car_5: setconf { upstream= { cbs=100000 ebs=100000 cir=500000000 greenAction=1 yellowAction=1 redAction=2 mode=2 } downstream= { cbs=100000 ebs=100000 cir=500000000 greenAction=1 yellowAction=1 redAction=2 mode=2 } }

ipfw add 100 allow all from any to any out

ipfw add 200 netgraf 1 all from aaa to any
ipfw add 300 netgraf 2 all from bbb to any
ipfw add 400 netgraf 3 all from ccc to any
ipfw add 500 netgraf 4 all from ddd to any
ipfw add 600 netgraf 5 all from eee to any
ipfw add 700 netgraf 6 all from fff to any

всегда net.inet.ip.fw.one_pass: 1

HZ=1000

 

Возникли вопросы по NG_CAR - правельноли выбраны cbs и ebs для mode=2 как настраивать длинну очереди шейпера в mode=3?

 

 

 

 

[make.kernel]

В исходниках mpd (если я правильно помню) формула для дефолтов такая: ebs=cir/8 cbs=ebs/2

 

После 7.1-RELEASE иногда (!) ng_car не шейпит трафик. может у меня руки кривые, но getconf показывает правильный конфиг, getstat весь трафик показывает green. Не часто, но на 1000 сессий mpd раз-два в сутки выскакивает, ng_car там вешается на клиентские тунели.