nicol@s Опубликовано 17 июня, 2010 (изменено) · Жалоба Добрый день! Есть машина - 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 - там любая скорость шейпится нормально (конфиг такой же как указан выше). В чем может быть проблема? Изменено 18 июня, 2010 пользователем nicol@s Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
windows_NT Опубликовано 21 июня, 2010 · Жалоба Проведите эксперимент на каренте результат должен отличатся Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
YuryD Опубликовано 22 июня, 2010 · Жалоба Может HZ побольше поставить ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapa Опубликовано 22 июня, 2010 (изменено) · Жалоба Может HZ побольше поставить ?Это врядли. Точность шейпера можно повысить, но тут, похоже, пакеты в pipe не попадают. Можно ipfw show посмотреть? Изменено 22 июня, 2010 пользователем kapa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[GP]Villi Опубликовано 23 июня, 2010 (изменено) · Жалоба столкнулся с тем же самым, но предел оказался 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, точнее уже не помню, там все отрабатывалось корректно. Изменено 23 июня, 2010 пользователем [GP]Villi Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nicol@s Опубликовано 23 июня, 2010 · Жалоба Вообще мистика какая-то: тоже обновился до FreeBSD 8.1. При этом 12Mbit шейпит без проблем, а вот все, что > 24Mbit - не шейпится. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nicol@s Опубликовано 23 июня, 2010 · Жалоба Тестировали-тестировали...Трафик попадал под правила, но скорость не резалась.... Решили поменять HZ с 2000 на 4000 все заработало!!! Получил нужные нам 24 МБит и больше!!!! В итоге выявили такую зависимость: HZ=1000 максимальная скорость, которую шейпит 12МБит; HZ=2000 максимальная скорость, которую шейпит 24Мбит; HZ=4000 максимальная скорость, которую шейпит 44Мбит. На что, кроме точности шейпера в FreeBSD 8 влияет HZ и как высчитывается значение скорости - осталось непонятным... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mikevlz Опубликовано 24 июня, 2010 · Жалоба Похоже на какое-то забавное переполнение, при котором система считает, что очередь пуста и длина пакетов не попадает под планку шейпирования. Как со счетчиками на свичах, когда 115Мбит за 5 минут переполняют 32-х разрядный счетчик октетов. Граница переносится или использованием счетчиков с бОльшей разрядностью, или увеличением частоты опроса. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapa Опубликовано 24 июня, 2010 · Жалоба ...В итоге выявили такую зависимость: 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 ... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[GP]Villi Опубликовано 24 июня, 2010 · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapa Опубликовано 24 июня, 2010 · Жалоба kapa ну уж поверьте не вру я вам )я верю, просто не понимаю... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
RussianE39 Опубликовано 24 июля, 2010 · Жалоба Вот в той же теме из 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. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Baneff Опубликовано 30 июля, 2010 · Жалоба У меня тоже не шейпило больше 12мбит/с при HZ=1000 пока не поставил net.inet.ip.dummynet.io_fast=0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
napTu Опубликовано 10 августа, 2010 · Жалоба несколько месяцев как столкнулся с этой проблемой, она действительно присутствует везде(во всех версиях фри), просто не у всех 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 ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
napTu Опубликовано 11 августа, 2010 · Жалоба Ха, прикол, по моим наблюдениям восьмерка не реагирует на отключение net.inet.ip.dummynet.io_fast увеличением нагрузки на проц., а возможно даже реагирует падением нагрузки ))) Так что жизнь вполне налаживается, осталось перевести основной роутер с семерки. Однако второй описанный мной глюк dummynet не уходит пропускание трафика сверх лимита пайпа, когда торент качает по udp с разных источников на один и тотже адрес и порт. Что происходит в общем то повсеместно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
carleone Опубликовано 8 октября, 2010 · Жалоба Они зафиксили эту проблему. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/147245. Я поправил ip_dn_io.c, скорость шейпится правильно при HZ=1000. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
miver Опубликовано 14 декабря, 2010 · Жалоба Поймал данный глюк еще в 7.0-STABLE осенью 2008-го года http://community.livejournal.com/ru_freebsd/169951.html тогда вылечилось апдейтом до 7.1-RC1 на прошлой неделе обновился до 8.1-RELEASE-p1 и глюк вылез опять, но теперь ключевая скорость не 11999Kbit/s, а 12111Kbit/s: все что больше - не шейпится. пропатчился патчем из предыдущего сообщения - все стало ок Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
medj Опубликовано 7 февраля, 2011 · Жалоба Объясните, что делаю не так. Пытаюсь применить патч $ 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) -Ребут Эффекта нет. Можно, конечно, мир пересобрать, но хочется всё же разобраться. Заранее спасибо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
220B Опубликовано 6 февраля, 2012 · Жалоба nicol@s, в итоге как решили проблему? Поставил порт ipfw+dummynet под Ubuntu 10.10 2.6.35-32-server (default HZ=100) и заметил что до 50 Мбит/с шейпится всё верно, а со значениями выше не понятная зависимость, т.е. ставлю например 100Мбит, а реально шейпится в 65-70Мбит и чем выше цифра, тем не понятнее зависимость. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mechanic Опубликовано 7 февраля, 2012 · Жалоба 100 зажимается до 65-70 ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
220B Опубликовано 8 февраля, 2012 · Жалоба 100 зажимается до 65-70 ? Да, вместо "скомандованных" 100 Мбит/с, получаю реально порядка 65-70Мбит/с Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 8 февраля, 2012 · Жалоба Да, вместо "скомандованных" 100 Мбит/с, получаю реально порядка 65-70Мбит/с 100 Mbps напрашивается ограничивать на порту. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
220B Опубликовано 8 февраля, 2012 (изменено) · Жалоба Да, вместо "скомандованных" 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 Изменено 8 февраля, 2012 пользователем 220B Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
220B Опубликовано 15 февраля, 2012 · Жалоба Светлые мысли закончились? :) Может кто ещё наткнется на подобное, я пока решил эту проблему использованием burst. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lagman Опубликовано 15 февраля, 2012 · Жалоба Судя по Drp 0 - проблема совсем не в dummynet Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...