Перейти к содержимому
Калькуляторы

ipfw3 pipe больше 24Мбит

Добрый день!

Есть машина - if_bridge1.

uname -a

FreeBSD 8.0-STABLE FreeBSD 8.0-STABLE #4: Thu May 13 13:08:53 MSD 2010     /usr/src/sys/amd64/compile/MYKERNEL  amd64

На ней крутится ipfw шейпер. IPFW обновлено до версии 3 от Луиджи для настройки приоритезации.

Параметры ядра для IPFW:

# IPFW
options         IPFIREWALL
options         IPFIREWALL_VERBOSE
options         IPFIREWALL_VERBOSE_LIMIT=10
options         IPFIREWALL_DEFAULT_TO_ACCEPT
options         DUMMYNET
options         HZ=2000

 

Проблема в том, что отказывается шейпить скорость больше 24Мбит/сек.

Часть конфига:

$IPFW pipe 27 config bw 32000Kbit/s mask dst-ip 0xffffffff
$IPFW pipe 28 config bw 34000Kbit/s mask src-ip 0xffffffff

$IPFW add pipe 27 ip from any to table\(112\) via igb0 out
$IPFW add pipe 28 ip from table\(113\) to any via igb1 out
$IPFW add pipe 27 ip from any to table\(112\) via igb2 out
$IPFW add pipe 28 ip from table\(113\) to any via igb3 out
$IPFW add allow ip from any to table\(112\)
$IPFW add allow ip from table\(113\) to any

Если bw поставить 24000Kbit/s или меньше - шейпит нормально. Если поставить значение больше, то скорость не режется.

 

P.S. есть еще машина if_bridge2:

uname -a:

FreeBSD 7.2-STABLE-200906 FreeBSD 7.2-STABLE-200906 #1: Tue Oct  6 10:26:41 MSD 2009     /usr/src/sys/amd64/compile/MYKERNEL  amd64

с обычным ipfw - там любая скорость шейпится нормально (конфиг такой же как указан выше).

 

В чем может быть проблема?

Изменено пользователем nicol@s

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Проведите эксперимент на каренте

 

результат должен отличатся

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Может HZ побольше поставить ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Может HZ побольше поставить ?
Это врядли. Точность шейпера можно повысить, но тут, похоже, пакеты в pipe не попадают.

 

Можно

ipfw show

посмотреть?

Изменено пользователем kapa

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

столкнулся с тем же самым, но предел оказался 12Mbit.

 

8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #8: Wed May 19 04:15:12 MSD 2010, amd64, HZ стандартное, т.е. 1000.

 

Пакеты попадают, но ограничение банально не срабатывает по каким-то причинам. Т.е. меняешь на лету, скорость pipe ставишь 11999 - ограничение работает, ставишь 12000 - перестает работать совсем, ну и при цифрах больше тоже соответсвенно.

 

До обновления была 8.0, точнее уже не помню, там все отрабатывалось корректно.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вообще мистика какая-то: тоже обновился до FreeBSD 8.1. При этом 12Mbit шейпит без проблем, а вот все, что > 24Mbit - не шейпится.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тестировали-тестировали...Трафик попадал под правила, но скорость не резалась....

Решили поменять HZ с 2000 на 4000 все заработало!!! Получил нужные нам 24 МБит и больше!!!!

В итоге выявили такую зависимость:

HZ=1000 максимальная скорость, которую шейпит 12МБит;

HZ=2000 максимальная скорость, которую шейпит 24Мбит;

HZ=4000 максимальная скорость, которую шейпит 44Мбит.

 

На что, кроме точности шейпера в FreeBSD 8 влияет HZ и как высчитывается значение скорости - осталось непонятным...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Как со счетчиками на свичах, когда 115Мбит за 5 минут переполняют 32-х разрядный счетчик октетов. Граница переносится или использованием счетчиков с бОльшей разрядностью, или увеличением частоты опроса.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

...

В итоге выявили такую зависимость:

HZ=1000 максимальная скорость, которую шейпит 12МБит;

HZ=2000 максимальная скорость, которую шейпит 24Мбит;

HZ=4000 максимальная скорость, которую шейпит 44Мбит.

...

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

Как со счетчиками на свичах, когда 115Мбит за 5 минут переполняют 32-х разрядный счетчик октетов. Граница переносится или использованием счетчиков с бОльшей разрядностью, или увеличением частоты опроса.

Особенно странно в свете вот этой переписки с Луиджи: http://lists.freebsd.org/pipermail/freebsd...une/004263.html

...

this was the result:

with hz=1 (default) between 200MBytes/s and 300MBytes/s

with hz=1000 between 200MBytes/s and 300MBytes/s

with hz=4000 between 350MBytes/s and 450MBytes/s

with hz=8000 between 250MBytes/s and 550MBytes/s

...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

kapa ну уж поверьте не вру я вам )

 

sysctl:

monster# sysctl -a | grep dummynet
net.inet.ip.dummynet.io_pkt_drop: 26208457
net.inet.ip.dummynet.io_pkt_fast: 12542136306
net.inet.ip.dummynet.io_pkt: 13388066932
net.inet.ip.dummynet.queue_count: 0
net.inet.ip.dummynet.fsk_count: 3072
net.inet.ip.dummynet.si_count: 208
net.inet.ip.dummynet.schk_count: 6144
net.inet.ip.dummynet.tick_lost: 0
net.inet.ip.dummynet.tick_diff: 1127169
net.inet.ip.dummynet.tick_adjustment: 218667
net.inet.ip.dummynet.tick_delta_sum: 375
net.inet.ip.dummynet.tick_delta: 0
net.inet.ip.dummynet.red_max_pkt_size: 1500
net.inet.ip.dummynet.red_avg_pkt_size: 512
net.inet.ip.dummynet.red_lookup_depth: 256
net.inet.ip.dummynet.expire_cycle: 0
net.inet.ip.dummynet.expire: 1
net.inet.ip.dummynet.debug: 0
net.inet.ip.dummynet.io_fast: 1
net.inet.ip.dummynet.pipe_byte_limit: 1048576
net.inet.ip.dummynet.pipe_slot_limit: 100
net.inet.ip.dummynet.hash_size: 64

monster# sysctl -a | grep hz
kern.clockrate: { hz = 1000, tick = 1000, profhz = 2000, stathz = 133 }
kern.hz: 1000

 

pipe выглядит так (взят произвольный для примера):

11034:  25.000 Mbit/s    0 ms burst 0
q142106  50 sl. 0 flows (1 buckets) sched 76570 weight 0 lmax 0 pri 0 droptail
sched 76570 type FIFO flags 0x0 0 buckets 1 active
  0 ip           0.0.0.0/0             0.0.0.0/0        2      120  0    0   0

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

kapa ну уж поверьте не вру я вам )

я верю, просто не понимаю...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вот в той же теме из ML lugi прокомментировал все эти проблемы:

Setting the burst size should have no practical effects,

whereas setting the queue size e.g.

o

ipfw pipe 10 config bw 800Mbit/s queue 200kbytes

 

should help a lot, but check your configuration with 'ipfw pipe show'

because if you supply an invalid parameter ipfw silently uses

a default or something different.

As an example, you said you used 80-90 Mbytes but the max queue

size is 100 packets or 1023Kbytes and larger values do not produce

the desired effect.

 

As a rule of thumb, to make sure that drops are not caused

by short queues, you should set the queue size to 1/HZ seconds

worth of data -- at HZ=1000 and 1Gbit/s this means 128Kbytes.

Note that after the dummynet queue, there might be some other

queue that saturates. As an example, when using the box as a router,

packets go in bursts to the output interface, and the burst can

be as large as 1500 packets per tick on a fully saturated Gig-E

(the interface's queue ranges normally between 128 and 1024 slots).

The only fix for this is probably using higher values of HZ.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня тоже не шейпило больше 12мбит/с при HZ=1000 пока не поставил net.inet.ip.dummynet.io_fast=0

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

несколько месяцев как столкнулся с этой проблемой,

она действительно присутствует везде(во всех версиях фри), просто не у всех net.inet.ip.dummynet.io_fast=1, как только ставишь в 0, все проблемы уходят.

Открыл соответствующий pr http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/147245 , где описано две проблемы, вышеуказанная и еще одно пропускание трафика, когда торент качает с разных источников на один и тотже адрес и порт.

 

Без net.inet.ip.dummynet.io_fast=1 естественно жить невозможно.

Испытал ng_car - грузит систему сильнее раза в два, сделал коммент тут http://www.opennet.ru/base/net/ng_car_ipfw.txt.html

PF ALTQ не подходит, т.к. не умеет простым образом нарезать очень много полос динамически, или хотябы изменением конфигурации с прямым указанием (нужно перезапускать весь конфиг).

 

Спасибо что хоть подсказали способ с HZ=

 

Интересная цитата ML lugi , но до конца не понятно.

Получается что при 12000Кбит/c, мы, с 1/1000сек тиками можем обрабатывать 12000/1000 = 12Кбит. за один тик = 1,5КБайта за тик, что есть максимальный размер пакета.

Что это значит я не знаю, но истина где то тут.

Нифига не пойму откуда разговор о скоростях 400-1000мбит, може всё таки он работал с net.inet.ip.dummynet.io_fast=0 ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ха, прикол, по моим наблюдениям восьмерка не реагирует на отключение net.inet.ip.dummynet.io_fast увеличением нагрузки на проц., а возможно даже реагирует падением нагрузки )))

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

 

Однако второй описанный мной глюк dummynet не уходит

пропускание трафика сверх лимита пайпа, когда торент качает по udp с разных источников на один и тотже адрес и порт.
Что происходит в общем то повсеместно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Они зафиксили эту проблему. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/147245. Я поправил ip_dn_io.c, скорость шейпится правильно при HZ=1000.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поймал данный глюк еще в 7.0-STABLE осенью 2008-го года

http://community.livejournal.com/ru_freebsd/169951.html

 

тогда вылечилось апдейтом до 7.1-RC1

 

на прошлой неделе обновился до 8.1-RELEASE-p1 и глюк вылез опять, но теперь ключевая скорость не 11999Kbit/s, а 12111Kbit/s: все что больше - не шейпится.

пропатчился патчем из предыдущего сообщения - все стало ок

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Объясните, что делаю не так. Пытаюсь применить патч

$ uname -a

FreeBSD gw1 8.2-PRERELEASE. Обновить систему сейчас нет возможности.

 

Открываю файл sys/netinet/ipfw/ip_dn_io.c

 

-Удаляю строки отмеченные (-), добавляю с плюсом.

-Пересобираю ядро, пресобираю IPFW (cd /usr/src/sbin/ipfw && make && make install && make clean)

-Ребут

 

Эффекта нет. Можно, конечно, мир пересобрать, но хочется всё же разобраться.

 

Заранее спасибо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

nicol@s, в итоге как решили проблему?

Поставил порт ipfw+dummynet под Ubuntu 10.10 2.6.35-32-server (default HZ=100) и заметил что до 50 Мбит/с шейпится всё верно, а со значениями выше не понятная зависимость, т.е. ставлю например 100Мбит, а реально шейпится в 65-70Мбит и чем выше цифра, тем не понятнее зависимость.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

100 зажимается до 65-70 ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

100 зажимается до 65-70 ?

Да, вместо "скомандованных" 100 Мбит/с, получаю реально порядка 65-70Мбит/с

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да, вместо "скомандованных" 100 Мбит/с, получаю реально порядка 65-70Мбит/с

100 Mbps напрашивается ограничивать на порту.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да, вместо "скомандованных" 100 Мбит/с, получаю реально порядка 65-70Мбит/с

100 Mbps напрашивается ограничивать на порту.

Ограничений на порту нет, т.к. физика порта 1Гиг и без ipfw отлично все прокачивается, упираясь именно в физику.

 

Раньше на этой же самой аппаратной платформе и с этим-же портом всё работало, но ядро было младше (тюнинг ядра прежний).

Модуль порта гружу с параметрами: insmod ipfw_mod.ko io_fast=1 hash_size=16384

Это бесклассовый примитивный шейп без маневров с шэдулерами и очередеями.

ipfw list
01000 pipe tablearg ip from any to table(1) in
01001 pipe tablearg ip from table(2) to any out

ipfw table all list
---table(1)---
192.168.1.1/32 102
---table(2)---
192.168.1.1/32 101

ipfw pipe list
00101: 100.000 Mbit/s    0 ms burst 0
q139385  50 sl. 0 flows (1 buckets) sched 73849 weight 0 lmax 0 pri 0 droptail
sched 73849 type FIFO flags 0x1 16384 buckets 1 active
   mask:  0x00 0xffffffff/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
 1 ip     192.168.1.1/0             0.0.0.0/0     8582   743862  0    0   0
01002: 100.000 Mbit/s    0 ms burst 0
q139384  50 sl. 0 flows (1 buckets) sched 73848 weight 0 lmax 0 pri 0 droptail
sched 73848 type FIFO flags 0x1 16384 buckets 1 active
   mask:  0x00 0x00000000/0x0000 -> 0xffffffff/0x0000
 2 ip           0.0.0.0/0       192.168.1.1/0      106     7466  0    0   0

Изменено пользователем 220B

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Светлые мысли закончились? :)

 

 

Может кто ещё наткнется на подобное, я пока решил эту проблему использованием burst.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Судя по Drp 0 - проблема совсем не в dummynet

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.