|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Ivan Voytas 2:5020/400 08 Sep 2004 12:45:01
To : Igor V. Kontsevykh
Subject : Re: Hормальный шейпер бывает?
--------------------------------------------------------------------------------
Hi.
> Есть внешние каналы с общей полосой, скажем, 5 мбит,
> все входят в роутер на фре и с него раздаются по:
> 1. клиентам на выделенках с фиксированной полосой, с ними
> просто - в трубу фиксированной ширины и высокий вес в
> общей очереди.
> 2. клиентам на выделенках с оплатой по трафику - им нужно
> предоставить определенной ширины полосу с высоким
> приоритетом и, что очень важно для увеличения выработки,
> всю свободную полосу входящих каналов с низким весом.
> 3. дайлерам - отдать то, что осталось после первых групп, это
> тоже просто - низкий вес в общей очереди.
>
> Вот вторая группа меня и напрягает - как сделать так, чтобы,
> скажем, клиенту сделать трубу на 128к с весом 99, а все, что
> в нее не вместилось (или не все, а еще 128к - но это уже было
> бы совсем шоколадно) - с весом 1?
1. Выделенщики: A - 32Kbit/s, B - 64Kbit/s, C - 128Kbit/s.
2. Выделенщики: D - 32-64Kbit/s, E - 64-96Kbit/s, F - 64-80Kbit/s. Тут
первое число - гарантированная полоса, второе - максимальная полоса при
наличии свободного канала (в данном случае свободного от других выделенщиков
в данной категории (2), а не всего канала, иначе сложней считать будет, хотя
тоже можно). При наличии куска свободной полосы, она распределяется между
D,E,F пропорционально гарантированной полосе каждого.
3. Дайлапщики: G - сколько осталось (ой, не завидую я им, нельзя так,
разбегуться, но дело твое :).
(Смотреть fixed-width шрифтом, pNK - pipe на NKbit/s, qXXX - queue с весом
XXX):
A--p32K---q100--------------p5000Kbit/s
B--p64K---q100-------------/
C--p128K--q100------------/
/
D--p64K---qXXX---pNNNK--/
E--p96K---qYYY--/ /
F--p80K---qZZZ-/ /
/
G-q1(mask 0xff..ff)-/
Вычисление XXX,YYY,ZZZ и NNN:
NNN=32+64+64=160Kbit/s.
XXX=32/160=0.2
YYY=ZZZ=64/160=0.4
XXX и YYY приводим к диапазону 1-100: XXX=20, YYY=ZZZ=40 например.
pNNNK можно убрать, тогда веса вычисляются с учетом всех остальных очередей,
что сложно (наверное не всегда можно будет уложиться в диапазон 1-100, тем
более с нужной точностью).
Самое страшное тут - суммарные задержки во всей совокупности пайпов и
очередей. Поэтому надо как-то извращаться. Hапример длина первого пайпа или
первой очереди в пути прохождения пакета вычисляется из пропускной
способности (например [Kbit/5] пакетов), все остальные - по 1 пакету (config
[queue|pipe] ..... queue 1). Hо это еще проверить надо.
Hу и конечно, в обратную сторону нужно отдельное такое же извращение
сделать, не пихать все в одни и те же пайпы.
Естественно, net.inet.ip.fw.one_pass=0.
Hадеюсь ничего не напутал, пишу по памяти ;)
WBR, Ivan Voytas.
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
