Re[3]: динамические очереди

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

Re[3]: динамические очереди

irix
Hello Dinar,

  Что-бы  это  были  не  сторонние  патчи,  а  были включены в базовое
  дерево. И ещё до кучи можно динамические очереди совместить с вашими
  старыми патчами чтобы правила altq можно было через pfctl добавлять

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


Reply | Threaded
Open this post in threaded view
|

Re: Re[3]: динамические очереди

Dinar Talypov
On Thu, 28 May 2009 12:30:55 +0300
irix <[hidden email]> wrote:

> Hello Dinar,
>
>   Что-бы  это  были  не  сторонние  патчи,  а  были включены в базовое
>   дерево. И ещё до кучи можно динамические очереди совместить с вашими
>   старыми патчами чтобы правила altq можно было через pfctl добавлять
>
по идее правильно сделать, чтоб правила могли добавлятся, но есть несколько но:
1) развертывание правил
2) оптимизация правил
всем этим занимается pfctl
в ядре занесение правил производится атомарно, либо заносится все либо ничего.

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


Reply | Threaded
Open this post in threaded view
|

Re: Re[3]: динамические очереди

Anton Maksimenkov-2
In reply to this post by irix
28 мая 2009 г. 15:30 пользователь irix <[hidden email]> написал:

irix, ты патчи-то тестить готов?
--
antonvm (aka engineer)
Reply | Threaded
Open this post in threaded view
|

Re[5]: динамические очереди

irix
Hello Anton,

Thursday, May 28, 2009, 3:24:33 PM, you wrote:

AM> 28 мая 2009 г. 15:30 пользователь irix <[hidden email]> написал:

AM> irix, ты патчи-то тестить готов?

Ага

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


Reply | Threaded
Open this post in threaded view
|

Re[5]: динамические очереди

irix
In reply to this post by Anton Maksimenkov-2
Hello Anton,

Thursday, May 28, 2009, 3:24:33 PM, you wrote:

AM> 28 мая 2009 г. 15:30 пользователь irix <[hidden email]> написал:

AM> irix, ты патчи-то тестить готов?

ага. Руками и нагами. И багрепорты. Всё всё. Дайте патчи.

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


Reply | Threaded
Open this post in threaded view
|

Re: динамические очереди

Gregory Edigarov-2
irix wrote:

> Hello Anton,
>
> Thursday, May 28, 2009, 3:24:33 PM, you wrote:
>
> AM> 28 мая 2009 г. 15:30 пользователь irix <[hidden email]> написал:
>
> AM> irix, ты патчи-то тестить готов?
>
> ага. Руками и нагами. И багрепорты. Всё всё. Дайте патчи.
>
>  
Только это потом еще надо пропихнуть в mainstream... а то я лично уже
насмотрелся
на судьбу сторонних патчей.

--
With best regards,
        Gregory Edigarov


Reply | Threaded
Open this post in threaded view
|

Re: Re[5]: динамические очереди

Anton Maksimenkov-2
In reply to this post by irix
28 мая 2009 г. 18:46 пользователь irix <[hidden email]> написал:
> AM> irix, ты патчи-то тестить готов?
> ага. Руками и нагами. И багрепорты. Всё всё. Дайте патчи.

Ну чо я могу сказать... В tech@ никто не заинтересовался, Хеннинг
сказал что это не есть желательное. Так что видимо пойдёт оно всё в
пешее эротическое.

В принципе я пока ковыряю ради интереса, раз уж начал копать, но... Да
и сам понимаешь, это можно сделать вобщем-то и так, в скрипте, чтобы
он брал шаблон, настругивал очередей, потом нужные правила
расшиперивал по IPшникам на эти очереди... Правила, конечно,
становятся нечитаемыми, а поддерживать шаблоны - это ещё то гавно...
Но у них видать провайдингом кучи юзеров не занимается никто, им такое
нафиг не нужно. "Никто не использует опен для ххх => в опене нету
удобных фич для ххх => никто не использует опен для ххх ...".

Я так думаю более интересно было бы поковырять в сторону предыдущей
идеи, чтобы ALTQ не давал клиенту аплоадить больше указанного
bandwidth на все (остальные) интерфейсы суммарно. Вот это
действительно никаким скриптом не исправить.
Хотя мне думается, что скорее получится поставить доп.
сервер-прокладку со строго двумя интерфейсами, чем...
--
antonvm
Reply | Threaded
Open this post in threaded view
|

Re[7]: динамические очереди

irix
Hello Anton,

Sunday, May 31, 2009, 10:23:52 AM, you wrote:

AM> 28 мая 2009 г. 18:46 пользователь irix <[hidden email]> написал:
>> AM> irix, ты патчи-то тестить готов?
>> ага. Руками и нагами. И багрепорты. Всё всё. Дайте патчи.

AM> Ну чо я могу сказать... В tech@ никто не заинтересовался, Хеннинг
AM> сказал что это не есть желательное. Так что видимо пойдёт оно всё в
AM> пешее эротическое.

AM> В принципе я пока ковыряю ради интереса, раз уж начал копать, но... Да
AM> и сам понимаешь, это можно сделать вобщем-то и так, в скрипте, чтобы
AM> он брал шаблон, настругивал очередей, потом нужные правила
AM> расшиперивал по IPшникам на эти очереди... Правила, конечно,
AM> становятся нечитаемыми, а поддерживать шаблоны - это ещё то гавно...
AM> Но у них видать провайдингом кучи юзеров не занимается никто, им такое
AM> нафиг не нужно. "Никто не использует опен для ххх => в опене нету
AM> удобных фич для ххх => никто не использует опен для ххх ...".

AM> Я так думаю более интересно было бы поковырять в сторону предыдущей
AM> идеи, чтобы ALTQ не давал клиенту аплоадить больше указанного
AM> bandwidth на все (остальные) интерфейсы суммарно. Вот это
AM> действительно никаким скриптом не исправить.
AM> Хотя мне думается, что скорее получится поставить доп.
AM> сервер-прокладку со строго двумя интерфейсами, чем...

Там  кстати в CDNR ещё была фишка с трёхцветным экшн маркером зависящим
от  скоростей  на  основе  которых  принемались  определённые действия
зелёное  действие,  жёлтое  или  красное. На их базе ещё можно было бы
создать  динамический  шейпер  который  бы  мог  зажимать  скорость  в
зависимости  от  прокаченной  инфы  в опред промежуток времени и сброс
счётчика этих прокачек в опред время. Например
<10Mb/always><5Mb/10Gb (in 1 day)><1Mb/15Gb (in 2 day's)><flush 1 day>,(<green> <yellow> <red>)(reset couter)

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


Reply | Threaded
Open this post in threaded view
|

Re[7]: динамические очереди

irix
In reply to this post by Anton Maksimenkov-2
Hello Anton,

Sunday, May 31, 2009, 10:23:52 AM, you wrote:

AM> 28 мая 2009 г. 18:46 пользователь irix <[hidden email]> написал:
>> AM> irix, ты патчи-то тестить готов?
>> ага. Руками и нагами. И багрепорты. Всё всё. Дайте патчи.

AM> Ну чо я могу сказать... В tech@ никто не заинтересовался, Хеннинг
AM> сказал что это не есть желательное. Так что видимо пойдёт оно всё в
AM> пешее эротическое.

Я  Хенинга  и  некоторых тамошних разработчиком не понимаю. То делайте
посмотрим,  то "мне" это нафиг не нужно и в топку. Причём тут "ему" не
нужно,  другим  нужно.  Я конечно рад конечно что в опёнку не суют всё
подряд  что  нужно  и что не нужно, как на пример в линукс или фрю. Но
даже то что действительно нужно с большой долей вероятности может быть
отброшено  (из-за  например  похмелья у разраба которому был направлен
запрос), что плохо для проекта в целом.

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


Reply | Threaded
Open this post in threaded view
|

Re: Re[7]: динамические очереди

Anton Maksimenkov-2
31 мая 2009 г. 16:09 пользователь irix <[hidden email]> написал:
> Я  Хенинга  и  некоторых тамошних разработчиком не понимаю. То делайте
> посмотрим,  то "мне" это нафиг не нужно и в топку. Причём тут "ему" не

Да как сказать, ты понимай это "делайте, посмотрим" как мягкий отказ
от обсуждения. Ну то есть типа ты сначала реализуй, увидишь все места
с чем это пересекается (может и не получится нихрена), увидишь от чего
всё это зависит ну и что будет зависеть. А потом можно будет
пообсуждать делает ли оно чо надо, нужно ли такое и в таком виде.
А тут видишь, идея была "на грани". Она, как я уже сказал, реализуема
на уровне юзера. Хенинг явно не захочет тащить в "свой" проект (pf)
всякое, что ему потом придётся поддерживать, иметь ввиду и учитывать в
процессе развития. Если б у него был не датацентр, а провайдинг, будь
спок, такие "модернизации" летели бы на ура (да они бы были где-то в
начале даже). Ну и во-вторых, я же рабочий патч не представил. Так,
идея и псевдопатч.

Да вобщем тут чо переживать-то, это ж МОЖНО сделать скриптом из
шаблона. Есть вобщем более необходимые штуки. PPPoE сервер в
частности.
--
antonvm
Reply | Threaded
Open this post in threaded view
|

Re[9]: динамические очереди

irix
Hello Anton,

Sunday, May 31, 2009, 3:10:48 PM, you wrote:

AM> 31 мая 2009 г. 16:09 пользователь irix <[hidden email]> написал:
>> Я  Хенинга  и  некоторых тамошних разработчиком не понимаю. То делайте
>> посмотрим,  то "мне" это нафиг не нужно и в топку. Причём тут "ему" не

AM> Да как сказать, ты понимай это "делайте, посмотрим" как мягкий отказ
AM> от обсуждения. Ну то есть типа ты сначала реализуй, увидишь все места
AM> с чем это пересекается (может и не получится нихрена), увидишь от чего
AM> всё это зависит ну и что будет зависеть. А потом можно будет
AM> пообсуждать делает ли оно чо надо, нужно ли такое и в таком виде.
AM> А тут видишь, идея была "на грани". Она, как я уже сказал, реализуема
AM> на уровне юзера. Хенинг явно не захочет тащить в "свой" проект (pf)
AM> всякое, что ему потом придётся поддерживать, иметь ввиду и учитывать в
AM> процессе развития. Если б у него был не датацентр, а провайдинг, будь
AM> спок, такие "модернизации" летели бы на ура (да они бы были где-то в
AM> начале даже). Ну и во-вторых, я же рабочий патч не представил. Так,
AM> идея и псевдопатч.

AM> Да вобщем тут чо переживать-то, это ж МОЖНО сделать скриптом из
AM> шаблона. Есть вобщем более необходимые штуки. PPPoE сервер в
AM> частности.

Понял.  PPPoE это конечно хорошо. Но ещё лучше сделать унифицированный
проект на подобие mpd. Котоырй бы в ядре мог не только PPPoE крутить а
ещё и впн с диалапом.

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


Reply | Threaded
Open this post in threaded view
|

Re: динамические очереди

Gregory Edigarov-2
In reply to this post by Anton Maksimenkov-2
Anton Maksimenkov wrote:

> 31 мая 2009 г. 16:09 пользователь irix <[hidden email]> написал:
>  
>> Я  Хенинга  и  некоторых тамошних разработчиком не понимаю. То делайте
>> посмотрим,  то "мне" это нафиг не нужно и в топку. Причём тут "ему" не
>>    
>
> Да как сказать, ты понимай это "делайте, посмотрим" как мягкий отказ
> от обсуждения. Ну то есть типа ты сначала реализуй, увидишь все места
> с чем это пересекается (может и не получится нихрена), увидишь от чего
> всё это зависит ну и что будет зависеть. А потом можно будет
> пообсуждать делает ли оно чо надо, нужно ли такое и в таком виде.
> А тут видишь, идея была "на грани". Она, как я уже сказал, реализуема
> на уровне юзера. Хенинг явно не захочет тащить в "свой" проект (pf)
> всякое, что ему потом придётся поддерживать, иметь ввиду и учитывать в
> процессе развития. Если б у него был не датацентр, а провайдинг, будь
> спок, такие "модернизации" летели бы на ура (да они бы были где-то в
> начале даже). Ну и во-вторых, я же рабочий патч не представил. Так,
> идея и псевдопатч.
>  
Боюсь , что даже в случае провайдинга такие модернизации не очень нужны.
Провайдинг сейчас == "умные", а найти сейчас более менее новый свитч, не
умеющий подрезку  полосы - не реально.
> Да вобщем тут чо переживать-то, это ж МОЖНО сделать скриптом из
> шаблона.
легко и непринужденно.
> Есть вобщем более необходимые штуки. PPPoE сервер в
> частности.
>  

--
With best regards,
        Gregory Edigarov


Reply | Threaded
Open this post in threaded view
|

Re: динамические очереди

Dinar Talypov
On Mon, 01 Jun 2009 10:36:33 +0300
Gregory Edigarov <[hidden email]> wrote:


> Боюсь , что даже в случае провайдинга такие модернизации не очень нужны.
> Провайдинг сейчас == "умные", а найти сейчас более менее новый свитч, не
> умеющий подрезку  полосы - не реально.
нарезку канала можно и нужно делать не только на свитче,
PPPoE например только на акцесс концентраторе :)

сдается, мне что нужно смотреть не в сторону какого-то шаблона, а непосредственно
в сторону pf тэгов и т.д., или научить altq создавать очереди при клонировании интерфейса:
например:
altq on <vlan> ...., где <vlan> группа интерфейсов,
т.е. при создании интерфейса ему наследуется свойства, вернее копируются очереди по параметрам указанным в очереди

Думается, что так, но есть но:
Чтоб altq запустить на интерфейсе, нужны начальные данные: скорость интерфейса, мту и т.д.,
а группа интерфейса этих данных не содержит.


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


Reply | Threaded
Open this post in threaded view
|

Re: динамические очереди

Anton Maksimenkov-2
In reply to this post by Gregory Edigarov-2
> Боюсь , что даже в случае провайдинга такие модернизации не очень нужны.
> Провайдинг сейчас == "умные", а найти сейчас более менее новый свитч, не
> умеющий подрезку  полосы - не реально.

Ну это как сказать. Это если на доступе их ставить, то ещё куда не
шло. А если по-старинке, на доступе мыльницы? Это не поможет. А если
ещё и юзера PPPoE... Или ещё такой "хитрый" момент - юзерам нужно
резать тока дырнет (ну, путь 256к, да?), а локалку пускай full speed.
Оно конечно, можно сказать "поручите это дело железке, она для этого
заточена и сделает это лучше писюка". Токо вот какая штука получается:
роутинг, он вообще "предназначен" для солидного трафика, как минимум -
масштаба каналов провайдера. И уж там ещё более оправданно говорить
"писюк такое не потянет, для этого железки нужны". Однако же опешники
лезут в роутинг со всего разбегу.
--
antonvm
Reply | Threaded
Open this post in threaded view
|

Re: динамические очереди

Anton Maksimenkov-2
In reply to this post by Dinar Talypov
> сдается, мне что нужно смотреть не в сторону какого-то шаблона, а непосредственно
> в сторону pf тэгов и т.д.

Я так-то идею надумал, в tech@ на собачьем (как мог) написал. Здесь
если надо могу повторить.
Но. Мне нужно помощь с parse.y, я с yaac'ом не на короткой ноге.

> или научить altq создавать очереди при клонировании интерфейса:
> например:
> altq on <vlan> ...., где <vlan> группа интерфейсов,
> т.е. при создании интерфейса ему наследуется свойства, вернее копируются очереди по параметрам указанным в очереди
> Думается, что так, но есть но:
> Чтоб altq запустить на интерфейсе, нужны начальные данные: скорость интерфейса, мту и т.д.,
> а группа интерфейса этих данных не содержит.

Кстати говоря, а как сейчас это? Можно как-то в PF создать
очереди/правила для несуществующих интерфейсов?
--
antonvm
Reply | Threaded
Open this post in threaded view
|

Re: динамические очереди

Gregory Edigarov-2
In reply to this post by Anton Maksimenkov-2
Anton Maksimenkov wrote:

>> Боюсь , что даже в случае провайдинга такие модернизации не очень нужны.
>> Провайдинг сейчас == "умные", а найти сейчас более менее новый свитч, не
>> умеющий подрезку  полосы - не реально.
>>    
>
> Ну это как сказать. Это если на доступе их ставить, то ещё куда не
> шло. А если по-старинке, на доступе мыльницы? Это не поможет. А если
> ещё и юзера PPPoE... Или ещё такой "хитрый" момент - юзерам нужно
> резать тока дырнет (ну, путь 256к, да?), а локалку пускай full speed.
> Оно конечно, можно сказать "поручите это дело железке, она для этого
> заточена и сделает это лучше писюка". Токо вот какая штука получается:
> роутинг, он вообще "предназначен" для солидного трафика, как минимум -
> масштаба каналов провайдера. И уж там ещё более оправданно говорить
> "писюк такое не потянет, для этого железки нужны". Однако же опешники
> лезут в роутинг со всего разбегу.
>  
ну, как раз роутинг писюки тянут аж бегом. у моих хороших друзей,  вон в
Германии
опенок роутит на 3 провайдера, за ним - 5 стоек с серверами. Легко и
ненапряжно.

--
With best regards,
        Gregory Edigarov


Reply | Threaded
Open this post in threaded view
|

Re: динамические очереди

Anton Maksimenkov-2
> ну, как раз роутинг писюки тянут аж бегом. у моих хороших друзей,  вон в

"это ещё не роутинг". вот будет 500-700Мб/с, да ещё от тучи разных
IPов (клиентов), вот тогда начнётся "роутинг".
--
antonvm
Reply | Threaded
Open this post in threaded view
|

Re: динамические очереди

Dinar Talypov
In reply to this post by Anton Maksimenkov-2
On Mon, 1 Jun 2009 14:07:18 +0600
Anton Maksimenkov <[hidden email]> wrote:

> > сдается, мне что нужно смотреть не в сторону какого-то шаблона, а непосредственно
> > в сторону pf тэгов и т.д.
>
> Я так-то идею надумал, в tech@ на собачьем (как мог) написал. Здесь
> если надо могу повторить.
> Но. Мне нужно помощь с parse.y, я с yaac'ом не на короткой ноге.
видел уже ;)

> > или научить altq создавать очереди при клонировании интерфейса:
> > например:
> > altq on <vlan> ...., где <vlan> группа интерфейсов,
> > т.е. при создании интерфейса ему наследуется свойства, вернее копируются очереди по параметрам указанным в очереди
> > Думается, что так, но есть но:
> > Чтоб altq запустить на интерфейсе, нужны начальные данные: скорость интерфейса, мту и т.д.,
> > а группа интерфейса этих данных не содержит.
>
> Кстати говоря, а как сейчас это? Можно как-то в PF создать
> очереди/правила для несуществующих интерфейсов?
> --

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

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


Reply | Threaded
Open this post in threaded view
|

Re: динамические очереди

Anton Maksimenkov-2
>> Кстати говоря, а как сейчас это? Можно как-то в PF создать
>> очереди/правила для несуществующих интерфейсов?
> очередь на несуществующий интерфейс создать не получится, потому как требуются параметры исходные.

Это я к чему. Это я к тому, что для пппое сервера мне кажется тогда
будет лучше предварительно насоздавать интерфейсов (pppoeХ). Чтобы
сразу к ним можно было ALTQ присобачивать. Хотя бы для начала, меньше
ковырять чтобы.

Я кстати патч для пппое сервера смотрел, ну и далее я так понимаю надо
sppp починить, чтобы юзер/пасс брал снаружи.
Как это "брать" идея есть? ioctl вроде бы не подходит, он для
"наоборот" заточен...
--
antonvm
Reply | Threaded
Open this post in threaded view
|

Re: динамические очереди

Dinar Talypov
On Mon, 1 Jun 2009 15:58:32 +0600
Anton Maksimenkov <[hidden email]> wrote:

> >> Кстати говоря, а как сейчас это? Можно как-то в PF создать
> >> очереди/правила для несуществующих интерфейсов?
> > очередь на несуществующий интерфейс создать не получится, потому как требуются параметры исходные.
>
> Это я к чему. Это я к тому, что для пппое сервера мне кажется тогда
> будет лучше предварительно насоздавать интерфейсов (pppoeХ). Чтобы
> сразу к ним можно было ALTQ присобачивать. Хотя бы для начала, меньше
> ковырять чтобы.
по идее можно сделать интерфейс который бы служил шаблоном,
при поступлении вызова PPPoE он бы себя клонировал с парметрами которые в нем указаны

>
> Я кстати патч для пппое сервера смотрел, ну и далее я так понимаю надо
> sppp починить, чтобы юзер/пасс брал снаружи.
> Как это "брать" идея есть? ioctl вроде бы не подходит, он для
> "наоборот" заточен...

идея сделать сокет наподобии route socket, к нему цепляется приложение которое авторизует,
и управляет состоянием sppp через ioctl или через тот же сокет.

З.Ы. пока это только идеи

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


12