backport

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

backport

irix
Hello Openbsd,

  Может быть кто-то может сделать backport altq с netbsd.

  Дело  в  том  что в нэтке altq сделан таким образом что одновременно
  работает  и с pf и altqd. Кто-то может сделать патч чтобы этот кусок
  кода  можно было запихнуть в OPenBSD и в опёнке в довесок к pf(altq)
  можно было ещё скомпилить altqd и его использовать ?

--
Best regards,
 irix                          mailto:[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: backport

Dinar Talypov
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 и его использовать ?
>
А зачем?

--
Динар Талыпов


Reply | Threaded
Open this post in threaded view
|

Re[2]: backport

irix
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]


Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: backport

Dinar Talypov
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> А зачем?
>
>
> Чтобы  можнло  было  шейпить  входящий  поток и создавать динамические
> очереди
>
шейпить входящий поток по определению нельзя, ибо даже в драйвере нет функции инпута(инпут идет сразу в ether_input, если это эзернет)и соответсвенно очереди тоже нет, очередь можно организовать только на выходе.
Эта тема тут уже неоднократно подымалась.

--
Динар Талыпов


Reply | Threaded
Open this post in threaded view
|

Re[4]: backport

irix
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> Эта тема тут уже неоднократно подымалась.


Хорошо  скажу  по  другому.  Измерить  скорость  входящего  потока  от
определённого  ипа  и  если больше чем нужно то дропать пакеты пока не
станет меньше.

--
Best regards,
 irix                            mailto:[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Re[4]: backport

Dinar Talypov
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, там идет скорость пакетов

--
Динар Талыпов


Reply | Threaded
Open this post in threaded view
|

Re[6]: backport

irix
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]


Reply | Threaded
Open this post in threaded view
|

Re[6]: backport

irix
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]


Reply | Threaded
Open this post in threaded view
|

Re[3]: backport

Alexander Sheiko
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


Reply | Threaded
Open this post in threaded view
|

Re: Re[6]: backport

Dinar Talypov
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 про количество пакетов в ед.
> времени  ничего  не  увидел.  Про  количество  стейтов и стейтов в ед.
> времени  увидел,  количество  создаваемых  стейтов  с одного источника
> увидел.   А  вот  проверки количества пакетов в ед.времени в одном уже
> созданном стейте
> не увидел. Направь в нужное русло.
Ошибся, я имел ввиду как раз max-src-conn-rate :)
>

--
Динар Талыпов


Reply | Threaded
Open this post in threaded view
|

Re: Re[3]: backport

Anton Maksimenkov-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Re[3]: backport

Dinar Talypov
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'е уже мерится где нить :)
--
Динар Талыпов


Reply | Threaded
Open this post in threaded view
|

Re: Re[3]: backport

Anton Maksimenkov-2
> навскидку можно просто в pf засунуть шейп по скорости пакетов по правилу, если конечно
> скорость в pf'е уже мерится где нить :)

Так пакеты разных размеров бывают. Какой-нить ослоторент будет мелкими
пакетишками пуляться, мы их по количеству дропанём (исходя из
предположения 1500байтного пакета посчитали что "не больше стоко-то
пакетов" будет 256к), а клиент прибежит с криками что не 256, а всего
60 кбит у него прокачивается.

А в плане направления идеи ты скорее прав: надо pf хачить, там для
этого всё подготовлено - и конфиг с парсером, и так далее.
--
engineer
Reply | Threaded
Open this post in threaded view
|

Re: Re[3]: backport

Dinar Talypov
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
ООО "Камател-Янтел"


Reply | Threaded
Open this post in threaded view
|

Re: backport

Andrey N. Oktyabrski-2
Dinar Talypov wrote:
>>> навскидку можно просто в pf засунуть шейп по скорости пакетов по правилу, если конечно
>>> скорость в pf'е уже мерится где нить :)
>> Так пакеты разных размеров бывают. Какой-нить ослоторент будет мелкими
>> пакетишками пуляться, мы их по количеству дропанём (исходя из
>> предположения 1500байтного пакета посчитали что "не больше стоко-то
>> пакетов" будет 256к), а клиент прибежит с криками что не 256, а всего
>> 60 кбит у него прокачивается.
> по идее TCP умный при дропе пакетов будет понижать скорость отправки :)
Если в договоре с клиентом прописаны КБ/с, ограничение по количеству
пакетов, очевидно, неприемлемо :-)


Reply | Threaded
Open this post in threaded view
|

Re: backport

Dinar Talypov
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 умный при дропе пакетов будет понижать скорость отправки :)
> Если в договоре с клиентом прописаны КБ/с, ограничение по количеству
> пакетов, очевидно, неприемлемо :-)
в любом случае все существующие алгоритмы так или иначе оперируют с размерами очереди.
А в очереде что? пакеты. Соответсвенно задача по ограничению трафика сводится к ограничению скорости пакетов в первую очередь, что приводит в конечном счете к ограничению скорсти в кбитах и мбитах

--
Динар Талыпов


Reply | Threaded
Open this post in threaded view
|

Re: backport

Anton Maksimenkov-2
> в любом случае все существующие алгоритмы так или иначе оперируют с размерами очереди.
> А в очереде что? пакеты. Соответсвенно задача по ограничению трафика сводится к ограничению скорости пакетов в первую очередь, что приводит в конечном счете к ограничению скорсти в кбитах и мбитах

Я ленивый и редко смотрю код... но ведь в дополнение к пакетам
хранится их размер? в мбуфах он есть собсно, и по крайней мере на
входе в 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
Reply | Threaded
Open this post in threaded view
|

Re: backport

Dinar Talypov
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-пакета.
>
> Так что мне _на первый взгляд_ кажется что суммировать не кол-во
> пакетов а их размеры никакой сложности не представляет... Не подгоняя
> под "существующие алгоритмы", а чисто так, обычным(и)
> счётчиком-накопителем.
> --
А причем тут размер пакета, собственно?
Ведь чтобы ограничить скорость надо пакет либо задержать в очереди,
либо его дропнуть не смотря на его размер.
--
Динар Талыпов


Reply | Threaded
Open this post in threaded view
|

Re[5]: backport

irix
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]


Reply | Threaded
Open this post in threaded view
|

Re: backport

Anton Maksimenkov-2
In reply to this post by Dinar Talypov
>> Так что мне _на первый взгляд_ кажется что суммировать не кол-во
>> пакетов а их размеры никакой сложности не представляет... Не подгоняя
>> под "существующие алгоритмы", а чисто так, обычным(и)
>> счётчиком-накопителем.
> А причем тут размер пакета, собственно?
> Ведь чтобы ограничить скорость надо пакет либо задержать в очереди,
> либо его дропнуть не смотря на его размер.

Не, ну как так. Ну мне надо ограничить "пропускную способность", то
есть дать пресловутые 256/256к в секунду. Независимо от количества
поступающих пакетов.
Пускай под этими мы будем понимать уже IP уровень, то есть 256/256к
байт (IP пакетов).
И выберем пока простое - пакеты дропаются по превышении того-то.

Мне не важно, рвутся ли сессии при этом или ещё что, неважно как там
TCP может регулировать скорость и так далее. Мне важно не дать клиенту
прокачать через меня больше чем те "256/256 к в секунду" за которые он
мне заплатил. А клиент уже пусть полагается на то, что TCP учтёт
потери и снизит скорость.

Грубый план.
Чтобы реализовать это дело я беру размер каждого поступающего
(входящего) пакета и добавляю его к счётчику. Ну, скажем, счётчик этот
сбрасывается раз в секунду. Или в несколько секунд, ну неважно для
понимания (важно для реализации).
Далее, в течение этой длящейся секунды, до тех пор пока не накопится
тех 256килобайт ничо не делается, пакеты (входящие) идут как шли. Как
накопилось - все новые пакеты (входящие) дропаются, и так до конца
этой длящейся секунды. Через секунду счётчик обнуляется - снова пошли
пропускать пакеты (входящие) и добавлять их размер в счётчик.

Это если для исходящих отдельно применять стандартные средства altq.
Но уж если мутить указанный план, и вообще в целях унификации, по уму
надо бы сделать 2 счётчика - для входящих и для исходящих пакетов. И
считать их размер и дропать их независимо.

P.S. не вижу как это выразить через количество пакетов в секунду (их
размеры могут меняться).
--
engineer
12