backport
Locked
12
12
 
|
Hello Openbsd,
Может быть кто-то может сделать backport altq с netbsd. Дело в том что в нэтке altq сделан таким образом что одновременно работает и с pf и altqd. Кто-то может сделать патч чтобы этот кусок кода можно было запихнуть в OPenBSD и в опёнке в довесок к pf(altq) можно было ещё скомпилить altqd и его использовать ? -- Best regards, irix mailto:[hidden email] |
|
|
On Tue, 12 May 2009 11:17:56 +0300
irix <[hidden email]> wrote: > Hello Openbsd, > > Может быть кто-то может сделать backport altq с netbsd. > > Дело в том что в нэтке altq сделан таким образом что одновременно > работает и с pf и altqd. Кто-то может сделать патч чтобы этот кусок > кода можно было запихнуть в OPenBSD и в опёнке в довесок к pf(altq) > можно было ещё скомпилить altqd и его использовать ? > А зачем? -- Динар Талыпов |
|
|
Hello Dinar,
Tuesday, May 12, 2009, 1:37:23 PM, you wrote: DT> On Tue, 12 May 2009 11:17:56 +0300 DT> irix <[hidden email]> wrote: >> Hello Openbsd, >> >> Может быть кто-то может сделать backport altq с netbsd. >> >> Дело в том что в нэтке altq сделан таким образом что одновременно >> работает и с pf и altqd. Кто-то может сделать патч чтобы этот кусок >> кода можно было запихнуть в OPenBSD и в опёнке в довесок к pf(altq) >> можно было ещё скомпилить altqd и его использовать ? >> DT> А зачем? Чтобы можнло было шейпить входящий поток и создавать динамические очереди -- Best regards, irix mailto:[hidden email] |
|
|
On Tue, 12 May 2009 15:16:38 +0300
irix <[hidden email]> wrote: > Hello Dinar, > > Tuesday, May 12, 2009, 1:37:23 PM, you wrote: > > DT> On Tue, 12 May 2009 11:17:56 +0300 > DT> irix <[hidden email]> wrote: > > >> Hello Openbsd, > >> > >> Может быть кто-то может сделать backport altq с netbsd. > >> > >> Дело в том что в нэтке altq сделан таким образом что одновременно > >> работает и с pf и altqd. Кто-то может сделать патч чтобы этот кусок > >> кода можно было запихнуть в OPenBSD и в опёнке в довесок к pf(altq) > >> можно было ещё скомпилить altqd и его использовать ? > >> > DT> А зачем? > > > Чтобы можнло было шейпить входящий поток и создавать динамические > очереди > Эта тема тут уже неоднократно подымалась. -- Динар Талыпов |
|
|
Hello Dinar,
Tuesday, May 12, 2009, 3:40:14 PM, you wrote: DT> On Tue, 12 May 2009 15:16:38 +0300 DT> irix <[hidden email]> wrote: >> Hello Dinar, >> >> Tuesday, May 12, 2009, 1:37:23 PM, you wrote: >> >> DT> On Tue, 12 May 2009 11:17:56 +0300 >> DT> irix <[hidden email]> wrote: >> >> >> Hello Openbsd, >> >> >> >> Может быть кто-то может сделать backport altq с netbsd. >> >> >> >> Дело в том что в нэтке altq сделан таким образом что одновременно >> >> работает и с pf и altqd. Кто-то может сделать патч чтобы этот кусок >> >> кода можно было запихнуть в OPenBSD и в опёнке в довесок к pf(altq) >> >> можно было ещё скомпилить altqd и его использовать ? >> >> >> DT> А зачем? >> >> >> Чтобы можнло было шейпить входящий поток и создавать динамические >> очереди >> DT> нет функции инпута(инпут идет сразу в ether_input, если это DT> эзернет)и соответсвенно очереди тоже нет, очередь можно организовать только на выходе. DT> Эта тема тут уже неоднократно подымалась. Хорошо скажу по другому. Измерить скорость входящего потока от определённого ипа и если больше чем нужно то дропать пакеты пока не станет меньше. -- Best regards, irix mailto:[hidden email] |
|
|
On Tue, 12 May 2009 15:43:26 +0300
irix <[hidden email]> wrote: > Hello Dinar, > > Tuesday, May 12, 2009, 3:40:14 PM, you wrote: > > DT> On Tue, 12 May 2009 15:16:38 +0300 > DT> irix <[hidden email]> wrote: > > >> Hello Dinar, > >> > >> Tuesday, May 12, 2009, 1:37:23 PM, you wrote: > >> > >> DT> On Tue, 12 May 2009 11:17:56 +0300 > >> DT> irix <[hidden email]> wrote: > >> > >> >> Hello Openbsd, > >> >> > >> >> Может быть кто-то может сделать backport altq с netbsd. > >> >> > >> >> Дело в том что в нэтке altq сделан таким образом что одновременно > >> >> работает и с pf и altqd. Кто-то может сделать патч чтобы этот кусок > >> >> кода можно было запихнуть в OPenBSD и в опёнке в довесок к pf(altq) > >> >> можно было ещё скомпилить altqd и его использовать ? > >> >> > >> DT> А зачем? > >> > >> > >> Чтобы можнло было шейпить входящий поток и создавать динамические > >> очереди > >> > DT> шейпить входящий поток по определению нельзя, ибо даже в драйвере > DT> нет функции инпута(инпут идет сразу в ether_input, если это > DT> эзернет)и соответсвенно очереди тоже нет, очередь можно организовать только на выходе. > DT> Эта тема тут уже неоднократно подымалась. > > > Хорошо скажу по другому. Измерить скорость входящего потока от > определённого ипа и если больше чем нужно то дропать пакеты пока не > станет меньше. можно через rate-limit в самом pf, там идет скорость пакетов -- Динар Талыпов |
|
|
Hello Dinar,
Tuesday, May 12, 2009, 3:46:43 PM, you wrote: DT> On Tue, 12 May 2009 15:43:26 +0300 DT> irix <[hidden email]> wrote: >> Hello Dinar, >> >> Tuesday, May 12, 2009, 3:40:14 PM, you wrote: >> >> DT> On Tue, 12 May 2009 15:16:38 +0300 >> DT> irix <[hidden email]> wrote: >> >> >> Hello Dinar, >> >> >> >> Tuesday, May 12, 2009, 1:37:23 PM, you wrote: >> >> >> >> DT> On Tue, 12 May 2009 11:17:56 +0300 >> >> DT> irix <[hidden email]> wrote: >> >> >> >> >> Hello Openbsd, >> >> >> >> >> >> Может быть кто-то может сделать backport altq с netbsd. >> >> >> >> >> >> Дело в том что в нэтке altq сделан таким образом что одновременно >> >> >> работает и с pf и altqd. Кто-то может сделать патч чтобы этот кусок >> >> >> кода можно было запихнуть в OPenBSD и в опёнке в довесок к pf(altq) >> >> >> можно было ещё скомпилить altqd и его использовать ? >> >> >> >> >> DT> А зачем? >> >> >> >> >> >> Чтобы можнло было шейпить входящий поток и создавать динамические >> >> очереди >> >> >> DT> шейпить входящий поток по определению нельзя, ибо даже в драйвере >> DT> нет функции инпута(инпут идет сразу в ether_input, если это >> DT> эзернет)и соответсвенно очереди тоже нет, очередь можно организовать только на выходе. >> DT> Эта тема тут уже неоднократно подымалась. >> >> >> Хорошо скажу по другому. Измерить скорость входящего потока от >> определённого ипа и если больше чем нужно то дропать пакеты пока не >> станет меньше. DT> можно через rate-limit в самом pf, там идет скорость пакетов По какой формуле расчитывать скорость, в зависимости от кол-ва пакетов ? -- Best regards, irix mailto:[hidden email] |
|
|
In reply to this post by Dinar Talypov
Hello Dinar,
Tuesday, May 12, 2009, 3:46:43 PM, you wrote: DT> On Tue, 12 May 2009 15:43:26 +0300 DT> irix <[hidden email]> wrote: >> Hello Dinar, >> >> Tuesday, May 12, 2009, 3:40:14 PM, you wrote: >> >> DT> On Tue, 12 May 2009 15:16:38 +0300 >> DT> irix <[hidden email]> wrote: >> >> >> Hello Dinar, >> >> >> >> Tuesday, May 12, 2009, 1:37:23 PM, you wrote: >> >> >> >> DT> On Tue, 12 May 2009 11:17:56 +0300 >> >> DT> irix <[hidden email]> wrote: >> >> >> >> >> Hello Openbsd, >> >> >> >> >> >> Может быть кто-то может сделать backport altq с netbsd. >> >> >> >> >> >> Дело в том что в нэтке altq сделан таким образом что одновременно >> >> >> работает и с pf и altqd. Кто-то может сделать патч чтобы этот кусок >> >> >> кода можно было запихнуть в OPenBSD и в опёнке в довесок к pf(altq) >> >> >> можно было ещё скомпилить altqd и его использовать ? >> >> >> >> >> DT> А зачем? >> >> >> >> >> >> Чтобы можнло было шейпить входящий поток и создавать динамические >> >> очереди >> >> >> DT> шейпить входящий поток по определению нельзя, ибо даже в драйвере >> DT> нет функции инпута(инпут идет сразу в ether_input, если это >> DT> эзернет)и соответсвенно очереди тоже нет, очередь можно организовать только на выходе. >> DT> Эта тема тут уже неоднократно подымалась. >> >> >> Хорошо скажу по другому. Измерить скорость входящего потока от >> определённого ипа и если больше чем нужно то дропать пакеты пока не >> станет меньше. DT> можно через rate-limit в самом pf, там идет скорость пакетов Полистал только что ман по pf.conf.5 про количество пакетов в ед. времени ничего не увидел. Про количество стейтов и стейтов в ед. времени увидел, количество создаваемых стейтов с одного источника увидел. А вот проверки количества пакетов в ед.времени в одном уже созданном стейте не увидел. Направь в нужное русло. -- Best regards, irix mailto:[hidden email] |
|
|
In reply to this post by irix
Hello irix,
Tuesday, May 12, 2009, 3:16:38 PM, you wrote: i> Чтобы можнло было шейпить входящий поток и создавать динамические i> очереди Уж сколько раз твердили миру: шейпить уже принятое - глупо. Если уж очень хочется - поставьте FreeBSD + Dummynet, будет Вам входящий шейп и динамические очереди с любыми масками. -- WBR, Alexander Sheiko |
|
|
In reply to this post by irix
On Tue, 12 May 2009 23:03:47 +0300
irix <[hidden email]> wrote: > Hello Dinar, > > Tuesday, May 12, 2009, 3:46:43 PM, you wrote: > > DT> On Tue, 12 May 2009 15:43:26 +0300 > DT> irix <[hidden email]> wrote: > > >> Hello Dinar, > >> > >> Tuesday, May 12, 2009, 3:40:14 PM, you wrote: > >> > >> DT> On Tue, 12 May 2009 15:16:38 +0300 > >> DT> irix <[hidden email]> wrote: > >> > >> >> Hello Dinar, > >> >> > >> >> Tuesday, May 12, 2009, 1:37:23 PM, you wrote: > >> >> > >> >> DT> On Tue, 12 May 2009 11:17:56 +0300 > >> >> DT> irix <[hidden email]> wrote: > >> >> > >> >> >> Hello Openbsd, > >> >> >> > >> >> >> Может быть кто-то может сделать backport altq с netbsd. > >> >> >> > >> >> >> Дело в том что в нэтке altq сделан таким образом что одновременно > >> >> >> работает и с pf и altqd. Кто-то может сделать патч чтобы этот кусок > >> >> >> кода можно было запихнуть в OPenBSD и в опёнке в довесок к pf(altq) > >> >> >> можно было ещё скомпилить altqd и его использовать ? > >> >> >> > >> >> DT> А зачем? > >> >> > >> >> > >> >> Чтобы можнло было шейпить входящий поток и создавать динамические > >> >> очереди > >> >> > >> DT> шейпить входящий поток по определению нельзя, ибо даже в драйвере > >> DT> нет функции инпута(инпут идет сразу в ether_input, если это > >> DT> эзернет)и соответсвенно очереди тоже нет, очередь можно организовать только на выходе. > >> DT> Эта тема тут уже неоднократно подымалась. > >> > >> > >> Хорошо скажу по другому. Измерить скорость входящего потока от > >> определённого ипа и если больше чем нужно то дропать пакеты пока не > >> станет меньше. > > DT> можно через rate-limit в самом pf, там идет скорость пакетов > > > Полистал только что ман по pf.conf.5 про количество пакетов в ед. > времени ничего не увидел. Про количество стейтов и стейтов в ед. > времени увидел, количество создаваемых стейтов с одного источника > увидел. А вот проверки количества пакетов в ед.времени в одном уже > созданном стейте > не увидел. Направь в нужное русло. > -- Динар Талыпов |
|
|
In reply to this post by Alexander Sheiko
> i> Чтобы можнло было шейпить входящий поток и создавать динамические
> i> очереди > Уж сколько раз твердили миру: шейпить уже принятое - глупо. Твердили-то твердили... Но вот например сервак. 3-4-5 сетевух. 1-ая - в локалку клиентов. 2-ая в индырнет. 3-я на game-серверы. 4-ая-5-ая ещё куда (например второй индырнет и так далее). Надо чтобы некие клиенты в/из локалки получали каждый суммарно не больше чем 256/256 кбит (ну обычный какой-нить "безлимит 256"). Как и где будем шейпить "восходящий"? А если без головняков? > Если уж очень хочется - поставьте FreeBSD + Dummynet, будет Вам > входящий шейп и динамические очереди с любыми масками. Вот то-то и оно, что фрюшники ведь тоже не идиоты, ведь сделали, пользуются. Потому что просто. Так что я бы не стал так категорично. Грязный хак - засунуть чо-то своё в упомянутый ether_input например, или уже в ipv4_input. Тока блин управление этим хаком нетривиальное. Хотя Олег выкладывал примеры всяких там всячин. -- engineer |
|
|
On Wed, 13 May 2009 10:44:40 +0600
engineer <[hidden email]> wrote: > > i> Чтобы можнло было шейпить входящий поток и создавать динамические > > i> очереди > > Уж сколько раз твердили миру: шейпить уже принятое - глупо. > > Твердили-то твердили... Но вот например сервак. 3-4-5 сетевух. 1-ая - > в локалку клиентов. 2-ая в индырнет. 3-я на game-серверы. 4-ая-5-ая > ещё куда (например второй индырнет и так далее). > > Надо чтобы некие клиенты в/из локалки получали каждый суммарно не > больше чем 256/256 кбит (ну обычный какой-нить "безлимит 256"). Как и > где будем шейпить "восходящий"? А если без головняков? > > > Если уж очень хочется - поставьте FreeBSD + Dummynet, будет Вам > > входящий шейп и динамические очереди с любыми масками. > Вот то-то и оно, что фрюшники ведь тоже не идиоты, ведь сделали, > пользуются. Потому что просто. Так что я бы не стал так категорично. > > Грязный хак - засунуть чо-то своё в упомянутый ether_input например, > или уже в ipv4_input. Тока блин управление этим хаком нетривиальное. > Хотя Олег выкладывал примеры всяких там всячин. навскидку можно просто в pf засунуть шейп по скорости пакетов по правилу, если конечно скорость в pf'е уже мерится где нить :) -- Динар Талыпов |
|
|
> навскидку можно просто в pf засунуть шейп по скорости пакетов по правилу, если конечно
> скорость в pf'е уже мерится где нить :) Так пакеты разных размеров бывают. Какой-нить ослоторент будет мелкими пакетишками пуляться, мы их по количеству дропанём (исходя из предположения 1500байтного пакета посчитали что "не больше стоко-то пакетов" будет 256к), а клиент прибежит с криками что не 256, а всего 60 кбит у него прокачивается. А в плане направления идеи ты скорее прав: надо pf хачить, там для этого всё подготовлено - и конфиг с парсером, и так далее. -- engineer |
|
|
On Wed, 13 May 2009 11:54:12 +0600
engineer <[hidden email]> wrote: > > навскидку можно просто в pf засунуть шейп по скорости пакетов по правилу, если конечно > > скорость в pf'е уже мерится где нить :) > > Так пакеты разных размеров бывают. Какой-нить ослоторент будет мелкими > пакетишками пуляться, мы их по количеству дропанём (исходя из > предположения 1500байтного пакета посчитали что "не больше стоко-то > пакетов" будет 256к), а клиент прибежит с криками что не 256, а всего > 60 кбит у него прокачивается. по идее TCP умный при дропе пакетов будет понижать скорость отправки :) > > А в плане направления идеи ты скорее прав: надо pf хачить, там для > этого всё подготовлено - и конфиг с парсером, и так далее. > -- > engineer > > !DSPAM:10,4a0a6097272713001712912! > > > __________ NOD32 4065 (20090511) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com > > -- Динар Талыпов т.+7(8555) 455810 ООО "Камател-Янтел" |
|
|
Dinar Talypov wrote:
>>> навскидку можно просто в pf засунуть шейп по скорости пакетов по правилу, если конечно >>> скорость в pf'е уже мерится где нить :) >> Так пакеты разных размеров бывают. Какой-нить ослоторент будет мелкими >> пакетишками пуляться, мы их по количеству дропанём (исходя из >> предположения 1500байтного пакета посчитали что "не больше стоко-то >> пакетов" будет 256к), а клиент прибежит с криками что не 256, а всего >> 60 кбит у него прокачивается. > по идее TCP умный при дропе пакетов будет понижать скорость отправки :) Если в договоре с клиентом прописаны КБ/с, ограничение по количеству пакетов, очевидно, неприемлемо :-) |
|
|
On Wed, 13 May 2009 10:21:21 +0400
"Andrey N. Oktyabrski" <[hidden email]> wrote: > Dinar Talypov wrote: > >>> навскидку можно просто в pf засунуть шейп по скорости пакетов по правилу, если конечно > >>> скорость в pf'е уже мерится где нить :) > >> Так пакеты разных размеров бывают. Какой-нить ослоторент будет мелкими > >> пакетишками пуляться, мы их по количеству дропанём (исходя из > >> предположения 1500байтного пакета посчитали что "не больше стоко-то > >> пакетов" будет 256к), а клиент прибежит с криками что не 256, а всего > >> 60 кбит у него прокачивается. > > по идее TCP умный при дропе пакетов будет понижать скорость отправки :) > Если в договоре с клиентом прописаны КБ/с, ограничение по количеству > пакетов, очевидно, неприемлемо :-) А в очереде что? пакеты. Соответсвенно задача по ограничению трафика сводится к ограничению скорости пакетов в первую очередь, что приводит в конечном счете к ограничению скорсти в кбитах и мбитах -- Динар Талыпов |
|
|
> в любом случае все существующие алгоритмы так или иначе оперируют с размерами очереди.
> А в очереде что? пакеты. Соответсвенно задача по ограничению трафика сводится к ограничению скорости пакетов в первую очередь, что приводит в конечном счете к ограничению скорсти в кбитах и мбитах Я ленивый и редко смотрю код... но ведь в дополнение к пакетам хранится их размер? в мбуфах он есть собсно, и по крайней мере на входе в pf_test уже всё что надо - известно. pf_test(int dir, struct ifnet *ifp, struct mbuf **m0, struct ether_header *eh) { ... struct mbuf *m = *m0; ... ...m->m_pkthdr.len... вот размер пакета (езернет как я полагаю) ... h = mtod(m, struct ip *); ... можно заюзать h->ip_len - вот и размер ip-пакета. Так что мне _на первый взгляд_ кажется что суммировать не кол-во пакетов а их размеры никакой сложности не представляет... Не подгоняя под "существующие алгоритмы", а чисто так, обычным(и) счётчиком-накопителем. -- engineer |
|
|
On Wed, 13 May 2009 14:25:25 +0600
engineer <[hidden email]> wrote: > > в любом случае все существующие алгоритмы так или иначе оперируют с размерами очереди. > > А в очереде что? пакеты. Соответсвенно задача по ограничению трафика сводится к ограничению скорости пакетов в первую очередь, что приводит в конечном счете к ограничению скорсти в кбитах и мбитах > > Я ленивый и редко смотрю код... но ведь в дополнение к пакетам > хранится их размер? в мбуфах он есть собсно, и по крайней мере на > входе в pf_test уже всё что надо - известно. > > pf_test(int dir, struct ifnet *ifp, struct mbuf **m0, struct ether_header *eh) > { > ... > struct mbuf *m = *m0; > ... > ...m->m_pkthdr.len... вот размер пакета (езернет как я полагаю) > ... > h = mtod(m, struct ip *); > ... > можно заюзать h->ip_len - вот и размер ip-пакета. > > Так что мне _на первый взгляд_ кажется что суммировать не кол-во > пакетов а их размеры никакой сложности не представляет... Не подгоняя > под "существующие алгоритмы", а чисто так, обычным(и) > счётчиком-накопителем. > -- Ведь чтобы ограничить скорость надо пакет либо задержать в очереди, либо его дропнуть не смотря на его размер. -- Динар Талыпов |
|
|
In reply to this post by Anton Maksimenkov-2
Hello engineer,
Wednesday, May 13, 2009, 7:44:40 AM, you wrote: >> i> Чтобы можнло было шейпить входящий поток и создавать динамические >> i> очереди >> Уж сколько раз твердили миру: шейпить уже принятое - глупо. e> Твердили-то твердили... Но вот например сервак. 3-4-5 сетевух. 1-ая - e> в локалку клиентов. 2-ая в индырнет. 3-я на game-серверы. 4-ая-5-ая e> ещё куда (например второй индырнет и так далее). e> Надо чтобы некие клиенты в/из локалки получали каждый суммарно не e> больше чем 256/256 кбит (ну обычный какой-нить "безлимит 256"). Как и e> где будем шейпить "восходящий"? А если без головняков? >> Если уж очень хочется - поставьте FreeBSD + Dummynet, будет Вам >> входящий шейп и динамические очереди с любыми масками. e> Вот то-то и оно, что фрюшники ведь тоже не идиоты, ведь сделали, e> пользуются. Потому что просто. Так что я бы не стал так категорично. e> Грязный хак - засунуть чо-то своё в упомянутый ether_input например, e> или уже в ipv4_input. Тока блин управление этим хаком нетривиальное. e> Хотя Олег выкладывал примеры всяких там всячин. В оргинальном altqd это делал кондиционер с дропером. И динамические очереди ещё можно было содавать и не писать дофига правил. Тут дофига отличных програмистов которые могут исправить эти два упущения. Тем более что кондиционер уже есть в ядре опёнка нужно только pf науить его понимать -- Best regards, irix mailto:[hidden email] |
|
|
In reply to this post by Dinar Talypov
>> Так что мне _на первый взгляд_ кажется что суммировать не кол-во
>> пакетов а их размеры никакой сложности не представляет... Не подгоняя >> под "существующие алгоритмы", а чисто так, обычным(и) >> счётчиком-накопителем. > А причем тут размер пакета, собственно? > Ведь чтобы ограничить скорость надо пакет либо задержать в очереди, > либо его дропнуть не смотря на его размер. Не, ну как так. Ну мне надо ограничить "пропускную способность", то есть дать пресловутые 256/256к в секунду. Независимо от количества поступающих пакетов. Пускай под этими мы будем понимать уже IP уровень, то есть 256/256к байт (IP пакетов). И выберем пока простое - пакеты дропаются по превышении того-то. Мне не важно, рвутся ли сессии при этом или ещё что, неважно как там TCP может регулировать скорость и так далее. Мне важно не дать клиенту прокачать через меня больше чем те "256/256 к в секунду" за которые он мне заплатил. А клиент уже пусть полагается на то, что TCP учтёт потери и снизит скорость. Грубый план. Чтобы реализовать это дело я беру размер каждого поступающего (входящего) пакета и добавляю его к счётчику. Ну, скажем, счётчик этот сбрасывается раз в секунду. Или в несколько секунд, ну неважно для понимания (важно для реализации). Далее, в течение этой длящейся секунды, до тех пор пока не накопится тех 256килобайт ничо не делается, пакеты (входящие) идут как шли. Как накопилось - все новые пакеты (входящие) дропаются, и так до конца этой длящейся секунды. Через секунду счётчик обнуляется - снова пошли пропускать пакеты (входящие) и добавлять их размер в счётчик. Это если для исходящих отдельно применять стандартные средства altq. Но уж если мутить указанный план, и вообще в целях унификации, по уму надо бы сделать 2 счётчика - для входящих и для исходящих пакетов. И считать их размер и дропать их независимо. P.S. не вижу как это выразить через количество пакетов в секунду (их размеры могут меняться). -- engineer |
«
Return to openbsd - Russian
|
1 view|%1 views
| Free forum by Nabble | Edit this page |