[t0ly]

у меня более 50% продаваемой полосы занимают юрики с тарифами от 10-ти и у каждого своя сетка раельных адрессов.

ставить под каждого отдельный шейпер? :)

В случае ng_car параллельно какая у абонента сетка. Заворачиваешь в нужную ноду все нужные сети и все.

хм

запустил на тестовом стенде (Celeron 2Ghz) 1024 ноды по 1mbit/s

и пустил тестовый траффик в 128 потоков с разных адресов

 

получил 20 мбит/с и недоступность роутера по ssh

 

тоже самое на dummynet вылилось в 100мбит как и должно было .

 

хз, пробывал на 6.3 попробую 7.2 может что то изменится.

 

[photon]

Мне думается, что у решения с ng_car оверхед повыше будет, чем у динамических пайпов. Да и работать с ним неудобно. Небось еще и лишние копии данных в кернеле создает. Зачем городить Netgraph на примитивном шейпере?

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

[jab]

Мне думается, что у решения с ng_car оверхед повыше будет, чем у динамических пайпов. Да и работать с ним неудобно. Зачем городить Netgraph на примитивном шейпере?

ng_car по определению гибче... как и весь netgraph. Но вот со стабильностью там проблемы. Кроме того, я сомневаюсь что его тюнили через sysctl.

И кроме того, среди нетграфоманов не принято делать ветвление по аналогии с ipfw skipto. Хотя казалось бы...

[photon]

Чисто теоретически это интересно, да. Но вся эта гибкость не нужна в большинстве случаев практического применения. Разве что для инкапсуляций каких-то особо извращенных. Другое дело, что нетграфомания поразила большинство разработчиков, хотят весь стек под него перестроить, GEOM слепили по его подобию. А пользователю в результате приходится юзать Netgraph даже для простых, казалось бы, вещей типа сбора Netflow в ядре. Кстати вопрос, чем ng_car гибче каких-нибудь классовых дисциплин, типа CBQ или HFSC?

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

[t0ly]

Чисто теоретически это интересно, да. Но вся эта гибкость не нужна в большинстве случаев практического применения. Разве что для инкапсуляций каких-то особо извращенных. Другое дело, что нетграфомания поразила большинство разработчиков, хотят весь стек под него перестроить, GEOM слепили по его подобию. А пользователю в результате приходится юзать Netgraph даже для простых, казалось бы, вещей типа сбора Netflow в ядре. Кстати вопрос, чем ng_car гибче каких-нибудь классовых дисциплин, типа CBQ или HFSC?

нупример как завернуть 1к клиентов каждого в свою дисциплину?

буз линейного поиска при матчинге сетки?

[jab]

Эта гибкость не нужна в большинстве случаев его применения. Ну разве что для инкапсуляций каких-то особо извращенных. Другое дело, что нетграфомания поразила большинство разработчиков, хотят весь стек под него перестроить, GEOM слепили по его подобию. А пользователю в результате приходится юзать Netgraph даже для простых, казалось бы, вещей типа сбора Netflow в ядре. Кстати, чем там ng_car гибче каких-нибудь классовых дисциплин, типа CBQ или HFSC?

Ну я могу агитировать как за, так и против. Если бы ng_car был стабилен, и не было столько жалоб. Дело в том, что такую гибкость как в нетграфе не найти больше нигде.

Гигабитные скорости, кстати, тоже не нужны в большинстве случаев применения. Считать netflow v5 простой вещью - можно разве что в сравнении с чем-то другим.

Я netflow нетграфом не собираю, собираю ipcad'ом через libpcap на port-mirror'е. Истессно в юзерспейсе. Дорого, но хоть считает точно. А гибче классовых дисциплин сам нетграф,

а не конкретно ng_car. Думаю тут и обсуждать нечего. Множественная вложенность потоков, ветвления, инкапсуляции/декапсуляции, и можно самому дописать все что хочется.

 

нупример как завернуть 1к клиентов каждого в свою дисциплину?

буз линейного поиска при матчинге сетки?

А на кой это вообще нужно ? Тут надо в консерватории править.

[photon]

нупример как завернуть 1к клиентов каждого в свою дисциплину?

буз линейного поиска при матчинге сетки?

Дисциплина -- это алгоритм работы с пакетами, которые стоят в очереди. Если имеется в виду предоставить каждому гарантированную полосу пропускания и сделать классификацию на основе IP-адреса, то средствами dummynet это делается так. Создаем таблицы с адресами, у которых одинаковый тариф, и пропускаем их через динамические пайпы:

ipfw pipe 1 config mask src-ip 0xffffffff bw 1Mbit/s

ipfw add 10 pipe 1 ip from table(1) to any out via $ext_if

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

 

В Linux нужно использовать HTB с кучей дочерних классов, а эффективную классификацию по IP можно сделать одним из следующих способов: фильтр flow, u32 hashing filters, модуль IPMARK или IPCLASSIFY в iptables. Кроме того, в этом случае нет ограничений по значениям полосы пропускания, как при использовании динамических пайпов. Можно иметь хоть столько же тарифов, сколько и юзеров. И как-то обходятся люди совсем без Netgraph, позвольте заметить.

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

[jab]

Дисциплина -- это алгоритм работы с пакетами, которые стоят в очереди. Если имеется в виду предоставить каждому гарантированную полосу пропускания и сделать классификацию на основе IP-адреса, то средствами dummynet это делается так. Создаем таблицы с адресами, у которых одинаковый тариф, и пропускаем их через динамические пайпы:

ipfw pipe 1 config mask src-ip 0xffffffff bw 1Mbit/s

ipfw add 10 pipe 1 ip from table(1) to any out via $ext_if

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

Подозреваю, что имелось в виду 1к тарифов на 1к клиентов. То есть - 2к статических пайпов и 1к skipto.

[sid1333]

Есть ли разница в производительности dummynet при работе со статическими и динамическими pipe'ами?

У меня например всё статиком - на каждый логин своя труба. Около 5000 таких труб уже.

 

При динамическом создании видимо меньше памяти под dummynet отдаётся из-за того, что не все абоны в онлайне, да и хэш таблицы я так думаю забиваются по мере надобности, а не сразу, как при статике.

[mikevlz]

тебе надо заворачивать каждого абонента в свой пайп. Это делается правилом на каждое направление. Каждое правило в ipfw увеличивает нагрузку на сетевую подсистему.

Если не заниматься онанизмом(как это описано у photon, а тем более сделано у тебя), то динамические пайпы делаются всего двумя правилами. В таблицу заносятся не только адрес клиента, но еще и номер пайпа.

Итого на ограничения на всех тарифах нужно всего два правила

ipfw add 100 pipe tablearg ip from table(1) to any out xmit $inetif

ipfw add 200 pipe tablearg ip from any to table(2) in recv $inetif

 

[t0ly]

нупример как завернуть 1к клиентов каждого в свою дисциплину?

буз линейного поиска при матчинге сетки?

Дисциплина -- это алгоритм работы с пакетами, которые стоят в очереди. Если имеется в виду предоставить каждому гарантированную полосу пропускания и сделать классификацию на основе IP-адреса, то средствами dummynet это делается так. Создаем таблицы с адресами, у которых одинаковый тариф, и пропускаем их через динамические пайпы:

ipfw pipe 1 config mask src-ip 0xffffffff bw 1Mbit/s

ipfw add 10 pipe 1 ip from table(1) to any out via $ext_if

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

 

В Linux нужно использовать HTB с кучей дочерних классов, а эффективную классификацию по IP можно сделать одним из следующих способов: фильтр flow, u32 hashing filters, модуль IPMARK или IPCLASSIFY в iptables. Кроме того, в этом случае нет ограничений по значениям полосы пропускания, как при использовании динамических пайпов. Можно иметь хоть столько же тарифов, сколько и юзеров. И как-то обходятся люди совсем без Netgraph, позвольте заметить.

freebsd если у клиента сетка адрессов то tablearg?

как по мне tablearg должен отрабатывать быстрее ведь идёт матчинг таблицы и сразу в даминет, а не матчинг тарифа, а затем ещё посик в даминет хеше,

 

 

Дисциплина -- это алгоритм работы с пакетами, которые стоят в очереди. Если имеется в виду предоставить каждому гарантированную полосу пропускания и сделать классификацию на основе IP-адреса, то средствами dummynet это делается так. Создаем таблицы с адресами, у которых одинаковый тариф, и пропускаем их через динамические пайпы:

ipfw pipe 1 config mask src-ip 0xffffffff bw 1Mbit/s

ipfw add 10 pipe 1 ip from table(1) to any out via $ext_if

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

Подозреваю, что имелось в виду 1к тарифов на 1к клиентов. То есть - 2к статических пайпов и 1к skipto.

skipto нету, идёт сразу ipfw add pipe tablerag ip from any to table(n) out

[jab]

ipfw add 100 pipe tablearg ip from table(1) to any out xmit $inetif

ipfw add 200 pipe tablearg ip from any to table(2) in recv $inetif

Тогда бы мне понадобилось раза в четыре больше труб чем есть сейчас. Дело в том, что юзеры _все_одновременно_ не работают. И на кой мне держать под них трубу ?

[Ilya Evseev]

...

довольно часто на короткое время процесс dummynet выжирает до 85-90% проца.

...

В фаерволе вроде как всё оптимизированно по максимуму, если нет, подскажите что и где?

00500 pipe tablearg ip from any to table(11) out via em1

Процессорная загрузка собирается в dummynet из-за "ipfw add 500 pipe tablearg".

Если для каждой скорости сделать отдельную таблицу и отдельное правило

"ipfw add 501 pipe 501 from any to table(51)", тогда нагрузка переедет в прерывания от сетевых карт.

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

 

[z18]

...

довольно часто на короткое время процесс dummynet выжирает до 85-90% проца.

...

В фаерволе вроде как всё оптимизированно по максимуму, если нет, подскажите что и где?

00500 pipe tablearg ip from any to table(11) out via em1

Процессорная загрузка собирается в dummynet из-за "ipfw add 500 pipe tablearg".

Если для каждой скорости сделать отдельную таблицу и отдельное правило

"ipfw add 501 pipe 501 from any to table(51)", тогда нагрузка переедет в прерывания от сетевых карт.

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

Теорию знаю - это не так.

[jab]

"ipfw add 501 pipe 501 from any to table(51)", тогда нагрузка переедет в прерывания от сетевых карт.

Подразумевается перенос нагрузки на taskq ?

[t0ly]

ipfw add 100 pipe tablearg ip from table(1) to any out xmit $inetif

ipfw add 200 pipe tablearg ip from any to table(2) in recv $inetif

Тогда бы мне понадобилось раза в четыре больше труб чем есть сейчас. Дело в том, что юзеры _все_одновременно_ не работают. И на кой мне держать под них трубу ?

у тебя может и да.

но если у клиента сетка из 256 или 512 адрессов то динамическим шейпером его в одну трубу не загониш

[t0ly]

или загониш?

[jab]

у тебя может и да.

но если у клиента сетка из 256 или 512 адрессов то динамическим шейпером его в одну трубу не загониш

Зато можно загнать всех клиентов с /24 в одну трубу, а всех с /23 в другую. Там вариантов-то не так уж и много.

[t0ly]

у тебя может и да.

но если у клиента сетка из 256 или 512 адрессов то динамическим шейпером его в одну трубу не загониш

Зато можно загнать всех клиентов с /24 в одну трубу, а всех с /23 в другую. Там вариантов-то не так уж и много.

ага, берём обычного юрика у которого несколько точек, например 3.

дано:

В каджой точке интерфейсный ip, В каждой точке сетка /27 или /28 или /24 (может быть что в кадой точке разные маски и разные префиксы).

 

как тут быть с динамическими пайпами?

 

как тут быть с динамическими пайпами если таких клиентов 10, 20, 40, 100?

 

 

 

[jab]

как тут быть с динамическими пайпами если таких клиентов 10, 20, 40, 100?

Да никак тут не быть. Я меньше 10000 юзеров и не рассматриваю. Не нужны вам динамические пайпы. Тем более с детской нагрузкой.

skipto в зубы и на баррикады.

[t0ly]

как тут быть с динамическими пайпами если таких клиентов 10, 20, 40, 100?

Да никак тут не быть. Я меньше 10000 юзеров и не рассматриваю. Не нужны вам динамические пайпы. Тем более с детской нагрузкой.

skipto в зубы и на баррикады.

skipto распааралелит нагрузку по CPU?

 

[jab]

skipto распааралелит нагрузку по CPU?

Нет.

[t0ly]

skipto распааралелит нагрузку по CPU?

Нет.

он будет работать быстрее чем tablearg pipe?

[jab]

он будет работать быстрее чем tablearg pipe?

В определенных условиях да, в определенных - нет. Надо брать и тестировать под конкретную инсталляцию.

[IvanI]

подсказка - с помощью skipto можно и нужно строить дерево где только возможно (похоже и skipto tablearg работает)