[Deac]

Вы мне еще на лиссяру ссылки пришлите... За опеннет в приличных местах и в морду могут дать. :-)

 

Тут пол-форума забито плясками с mpd + ng_car.

Ну пока есть такие люди, как lavr, например - опеннет сам кому хош в морду даст! ;-)

а что - lavr и jab разные люди? :)

Судя по стилистике - да, а там - х.з.(м.б. раздвоение личности?) ;-)

 

[photon]

НО думинет уже вылизан и работает как часы - по ng_car пока такого сказать не получится ....

чего бы я смотрел в сторону ng_car тогда?

Вот, полюбуйтесь

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

http://forum.lissyara.su/viewtopic.php?f=4&t=24332

Наверное у пайпов размеры очередей слишком малы, поэтому ограничение скорости может быть достигнуто, только если dummynet будет отбрасывать пакеты. Надо для начала поднять размеры очередей для юзеров с большими полосами, а если не поможет, выключить io_fast. Еще можно шейпить на Linux, там таких проблем вроде нет.

Изменено 28 мая, 2010 пользователем photon

[Deac]

Еще можно шейпить на Linux, там таких проблем вроде нет.

Аналог BSD-шного GRED на линуксе существует?

 

[AFCrio]

Еще можно шейпить на Linux, там таких проблем вроде нет.

Аналог BSD-шного GRED на линуксе существует?

"Аналог BSD-шного GRED на линуксе " называется ... gred

 

[Deac]

Вот именно, что "называется", сравни "Gentle RED" на BSD vs "Generic RED" на линуксе, кот. аналог простого RED на BSD.

[photon]

А зачем провайдеру тратить ресурсы оборудования на RED или GRED? Достаточно FIFO и больших очередей.

[Deac]

А за тем, чтобы "имея не слишком много, продать достаточно" и GRED этому способствует.

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

Изменено 28 мая, 2010 пользователем Deac

[photon]

А за тем, чтобы "имея не слишком много, продать достаточно" и GRED этому способствует.

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

А что, gentle RED работает намного лучше RED? Ну подумаешь, другая функция для вычисления вероятности отбрасывания пакета. Можно в исходник залезть и поправить несколько строчек кода, если что. А в Linux кстати и реализации WF2Q+ нет. И не надо, т.к. SFQ нормально справляется.

Изменено 1 июня, 2010 пользователем photon

[Mechanic]

подскажите по конфигу для безлимов 10мбит ?

msg user376: setconf { upstream={ cbs=1310720 ebs=1310720 cir=10485760 greenAction=1 yellowAction=1 redAction=2 mode=3 } downstream={ cbs=1310720 ebs=1310720 cir=10485760 greenAction=1 yellowAction=1 redAction=2 mode=3} }

не отдается 10мбит абону, максимум 4-5мбит

[mikevlz]

а в много потоков?

[Mechanic]

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

[burn]

Использую связку FreeBSD + ipfw + ng_car - устраивает всем, загрузка cpu на 15-20% ниже чем при работе с dummynet .

Основной мотивацией перейти с dummynet на ng_car было возможность шейпить несколько ip-адресов одному клиенту и при этом используя всего два правила в ipfw на всех !!!

Все бы хорошо, но есть проблема с "ipfw table" - иногда возникает "глюк" и ipfw начинает игнорировать некоторые ip из table и пропускает их без "заворота" на шейп или наоборот не пропускает те ip которым разрешено правилами. Очистить table не получается, помогает только перезагрузка.

Находил похожее в PR:

http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/143474

http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/127209

[photon]

Использую связку FreeBSD + ipfw + ng_car - устраивает всем, загрузка cpu на 15-20% ниже чем при работе с dummynet .

Основной мотивацией перейти с dummynet на ng_car было возможность шейпить несколько ip-адресов одному клиенту и при этом используя всего два правила в ipfw на всех !!!

А как выглядят эти правила?

[burn]

Использую связку FreeBSD + ipfw + ng_car - устраивает всем, загрузка cpu на 15-20% ниже чем при работе с dummynet .

Основной мотивацией перейти с dummynet на ng_car было возможность шейпить несколько ip-адресов одному клиенту и при этом используя всего два правила в ipfw на всех !!!

А как выглядят эти правила?

Примерно так:

${fwcmd} add 1311 netgraph tablearg ip from any to "table(2)" in via ${if_isp}
${fwcmd} add 1350 netgraph tablearg ip from "table(3)" to any out via ${if_isp}

[photon]

Не думаю, что это много лучше аналогичных правил с pipe tablearg. А когда вы сравнивали нагрузку, вы dummynet прибивали к какому-то одному процессору с помощью cpuset?

Изменено 22 июня, 2010 пользователем photon

[burn]

Не думаю, что это много лучше аналогичных правил с pipe tablearg. А когда вы сравнивали нагрузку, вы dummynet прибивали к какому-то одному процессору с помощью cpuset?

Нет, dummynet к процессору не прибивал, на тот момент этого не требовалось

Сомневаюсь что с pipe tablearg можно организовать нарезку трафика для нескольких тарифов и несколько ip у клиента всего двумя правилами.

Если есть пример покажите.

[photon]

Сомневаюсь что с pipe tablearg можно организовать нарезку трафика для нескольких тарифов и несколько ip у клиента всего двумя правилами.

Если есть пример покажите.

Правила почти те же самые, но с pipe tablearg вместо netgraph tablearg:

ipfw pipe 100 config bw 1000Kbyte/s
ipfw pipe 101 config bw 2000Kbyte/s
...
ipfw table 1 add 192.168.2.1 100
ipfw table 1 add 192.168.2.2 100
ipfw table 1 add 192.168.2.3 100
ipfw table 1 add 192.168.2.4 101
ipfw table 1 add 192.168.2.5 101
...
ipfw add pipe tablearg ip from table(1) to any out via $ext_if

Для входящего трафика нужен еще один набор пайпов, аналогичная таблица и одно правило для классификации. Правда на практике я это дело не обкатывал, т.к. достаточно и динамических пайпов с одним юзером на канал. Минусом этого решения по сравнению с динамическими правилами является то, что пайпы для каждого клиента надо создавать явным образом. Но все равно, правила с tablearg в ipfw получаются намного проще, чем километровые правила для tc в Linux.

Изменено 22 июня, 2010 пользователем photon

[burn]

Сомневаюсь что с pipe tablearg можно организовать нарезку трафика для нескольких тарифов и несколько ip у клиента всего двумя правилами.

Если есть пример покажите.

Правила почти те же самые, но с pipe tablearg вместо netgraph tablearg:

ipfw pipe 100 config bw 1000Kbyte/s
ipfw pipe 101 config bw 2000Kbyte/s
...
ipfw table 1 add 192.168.2.1 100
ipfw table 1 add 192.168.2.2 100
ipfw table 1 add 192.168.2.3 100
ipfw table 1 add 192.168.2.4 101
ipfw table 1 add 192.168.2.5 101
...
ipfw add pipe tablearg ip from table(1) to any out via $ext_if

Для входящего трафика нужен еще один набор пайпов, аналогичная таблица и одно правило для классификации. Правда на практике я это дело не обкатывал, т.к. достаточно и динамических пайпов с одним юзером на канал. Минусом этого решения по сравнению с динамическими правилами является то, что пайпы для каждого клиента надо создавать явным образом. Но все равно, правила с tablearg в ipfw получаются намного проще, чем километровые правила для tc в Linux.

А если еще одному клиенту нужно зарезать или еще один тариф создать - это еще pipe создавать ?

Вот от этого и уходили.

Сделали один раз два правила и забыли. Далее все автоматом при выборе тарифа из биллинга.

[photon]

А если еще одному клиенту нужно зарезать или еще один тариф создать - это еще pipe создавать ?

Вот от этого и уходили.

Сделали один раз два правила и забыли. Далее все автоматом при выборе тарифа из биллинга.

Два правила -- это только в ipfw, а нетграфовские ноды для клиентов разве не нужно создавать? Возни столько же. Хотя если там с fine-grained locking лучше, чем в dummynet, то оно и стоит того.

Изменено 23 июня, 2010 пользователем photon