Jump to content

Recommended Posts

Posted

Из релиз нотесов:

The dummynet(4) subsystem now supports fast mode operation which allows certain packets to bypass the dummynet scheduler. This can achieve lower latency and lower overhead when the packet flow is under the pipe bandwidth, and eliminate recursion in the subsystem. The new sysctl variable net.inet.ip.dummynet.io_fast has been added to enable this feature.

 

Как это работает кто-нить разбирался?

Posted
А что не понятно-то? Идея в том, чтобы пакеты проходящие через dummynet могли fastforward'ится.
Как-то первая фраза более похожа на "Думминет теперь поддерживает режим быстрой обработки при которой определенные пакеты не задерживаютя для обработки думминетом".

Хотя мож мы об одном и том же говорим. Но меня интересует не риторика, а технические данные и реализация.

 

Типа при правилах

---

---

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

Posted

when the packet flow is under the pipe bandwidth

 

Написано же. Если поток не доходит до потолка, механизм шейпирования вобще не применяется. Я так понял.

Posted

Угу, похоже на правду. Ток тогда получается что фенька работает если "клиент" свой канал недогружает, что встречается редко, но игрокам самое то.

 

Posted

У нас с четырьмя мегабитами частенько недогружают. Поработать бы сутки с нулевым значением и сутки с единичкой, сравнить статистику.

  • 4 months later...
  • 9 months later...
Posted

Поставь яндеховые дрова наконец. Уже ж в другой теме тебе писали.

У тебя на каждую сетевуху по одному ядру и они на 100% нагружены, а остальные ядра и до 50% недобирают.

Какие там еще пинги при перегруженом проце ??

Posted
Поставь яндеховые дрова наконец. Уже ж в другой теме тебе писали.

У тебя на каждую сетевуху по одному ядру и они на 100% нагружены, а остальные ядра и до 50% недобирают.

Какие там еще пинги при перегруженом проце ??

А яндексовые дрова под 7.2|8.0 есть?

  • 7 months later...
Posted

У меня на 8.0-STABLE-201005 amd64 при:

net.inet.ip.dummynet.io_fast: 1

Счётчики показывают:

net.inet.ip.dummynet.io_pkt_drop: 106886552

net.inet.ip.dummynet.io_pkt_fast: 0

net.inet.ip.dummynet.io_pkt: 5210146253

Получается у меня вообще никто мимо шейпера не бегает ? Полосы от 1 Мбита и до 16 Мбит. Не думаю, что все полосы забиты до краёв. Параметр применяем ещё с 7.0, если не изменяет память, и никогда счётчик не был равен 0.

 

upd: на другом шейпере с FreeBSD 7.2-STABLE-200906 точно такая же петрушка :(

Posted
upd: на другом шейпере с FreeBSD 7.2-STABLE-200906 точно такая же петрушка :(

 

FreeBSD 7.3-STABLE #0:

net.inet.ip.dummynet.io_pkt_drop: 14558307

net.inet.ip.dummynet.io_pkt_fast: 139517436

net.inet.ip.dummynet.io_pkt: 923458709

Posted
upd: на другом шейпере с FreeBSD 7.2-STABLE-200906 точно такая же петрушка :(

 

FreeBSD 7.3-STABLE #0:

net.inet.ip.dummynet.io_pkt_drop: 14558307

net.inet.ip.dummynet.io_pkt_fast: 139517436

net.inet.ip.dummynet.io_pkt: 923458709

Хм... может мы где в правилах запутались :(

Если не сложно, киньте кусочек правил для одной трубы ?

Posted

Если я правильно понял, то fast = ip_fastfwd - оно гонит пакеты прямиком в if_output, не заворачивая в netisr очередь и короче говоря много доп/лишней работы не делая, но пакеты не все могут идти через фаст, оно не работает для пакетов с опциями, броадкаста, мультикаста, пакетов от/к этому хосту.

Для все этих случаев пакеты уходят на ip_input, откуда после обработки уходит в netisr, который видимо вызывает ip_output и уже он отправляет в if_output.

 

 

net.inet.ip.dummynet.io_fast: 1
Полагаю кроме этого нужно в принципе включить фастфорвадинг:

net.inet.ip.fastforwarding: 1

Posted

А почему бы тогда не сделать шейпер мостом, чтобы не было необходимости в маршрутизации?

И как производительность в варианте с мостом??

Posted (edited)

Должна быть выше, по идее, т.к. нет маршрутизации. Видел у знакомого мост-шейпер на 8-процессорной машине с FreeBSD, держит по 450 Мбит/с в обе стороны, пакетрейт около 100 kpps, загруженность процессоров менее 20%.

Edited by photon
Posted

Должна быть выше, по идее, т.к. нет маршрутизации. Видел у знакомого мост-шейпер на 8-процессорной машине с FreeBSD, держит по 450 Мбит/с в обе стороны, пакетрейт около 100 kpps, загруженность процессоров менее 20%.

А правда, что аналог на линуксе меньше ресурсов требует (tc htb) ?

Posted

А правда, что аналог на линуксе меньше ресурсов требует (tc htb) ?

Я бы так не сказал. При должном умении и правильном железе, везде можно добиться шейпинга на аппаратных скоростях. Однако, dummynet умеет решать лишь несколько определенных задач, в то время как QoS-подсистему в Linux можно настроить как угодно. Недостаток линуксового решения в том, что для него намного сложнее генерировать правила.

Join the conversation

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

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.