| 1.1, FAKE (?), 18:09, 20/05/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Вобщем-то доходчиво написано, но ничего нового кроме ipfw -f pipe flusр | | |
| |
| 2.2, toor99 (ok), 18:33, 20/05/2005 [^] [^^] [^^^] [ответить]
| +/– |
 Ну а что там может быть принципиально нового? Dummynet делает примитивный тейлдроп, со всеми его недостатками. А более совершенную altq во FreeBSD, насколько я понимаю, никто перетаскивать не собирается. | | |
| |
| 3.3, gate (?), 18:44, 20/05/2005 [^] [^^] [^^^] [ответить]
| +/– |
 > А более совершенную altq во FreeBSD, насколько я понимаю, никто перетаскивать не собирается.
А зачем собираться? altq уже давно в пятой ветке. | | |
| 3.5, citrin (ok), 19:29, 20/05/2005 [^] [^^] [^^^] [ответить]
| +/– |
 > Ну а что там может быть принципиально нового? Dummynet делает примитивный тейлдроп, со всеми его недостатками
Там есть еще RED и GRED. А вот подбор оптимальных параметров для RED это очень сложная задача. | | |
| 3.6, uldus (ok), 22:12, 20/05/2005 [^] [^^] [^^^] [ответить]
| +/– |
>со всеми его недостатками. А более совершенную altq во
>FreeBSD, насколько я понимаю, никто перетаскивать не собирается.
Использовал ALTQ в FreeBSD 2.2.1, когда в других операционках шейперами и не пахло. Кстати, и сейчас мало какой шейпер докатился до уровня тогдашнего ALTQ. Если бы не появился простой и предельно ясный Dummynet, ALTQ давно был бы официально в системе.
| | |
|
|
| 1.7, adsh (??), 02:56, 21/05/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Всё хорошо, только лучше ещё использовать GRED - меньше будет потерь и скорость не будет всё время скакать туда / сюда как бешенная. Ну и размеры очередей пакетов подобрать. | | |
| |
| 2.8, dmitry (??), 13:04, 23/05/2005 [^] [^^] [^^^] [ответить]
| +/– | |
как правильно GRED и размер очереди подобрать. каким алгоритмом руководствоваться?
| | |
| |
| 3.10, adsh (??), 22:45, 23/05/2005 [^] [^^] [^^^] [ответить]
| +/– | |
>как правильно GRED и размер очереди подобрать. каким алгоритмом руководствоваться?
С эти очень просто. Поскольку очередь не может быть больше 2*max_th - то такую её и ставим.
Для канала в несколько мегабит рекомендую:
pipe 100 config bw 1Mbit/s queue 60 gred 0.002/10/30/0.1
queue 100 config pipe 100 queue 60 mask dst-ip 0xffffffff gred 0.002/10/30/0.1
add queue 100 tcp from aaa.bbb.ccc.ddd 80 to any via fxp0 out
В данном случае - весь исходящий тафик веб сервера равномерно распределяется между всеми пользователями и не зависит от количества сессий, открытых каждым клиентом. Пример - для сервера - файлопомойки. | | |
| |
| 4.12, net11 (?), 14:31, 24/05/2005 [^] [^^] [^^^] [ответить]
| +/– |
 >>как правильно GRED и размер очереди подобрать. каким алгоритмом руководствоваться?
>
>С эти очень просто. Поскольку очередь не может быть больше 2*max_th -
>то такую её и ставим.
>
>Для канала в несколько мегабит рекомендую:
>
>pipe 100 config bw 1Mbit/s queue 60 gred 0.002/10/30/0.1
>queue 100 config pipe 100 queue 60 mask dst-ip 0xffffffff gred 0.002/10/30/0.1
>
>add queue 100 tcp from aaa.bbb.ccc.ddd 80 to any via fxp0 out
>
>
>В данном случае - весь исходящий тафик веб сервера равномерно распределяется между
>всеми пользователями и не зависит от количества сессий, открытых каждым клиентом.
>Пример - для сервера - файлопомойки.
Не подскажите как лучше поделить канал 256к на клиентов по 64к, какие очереди поставить и параметры gred
подскажите плизз | | |
|
|
|
| 1.9, santa (?), 13:28, 23/05/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Я не согласен с этим
>Оба пользователя непрерывно качают примерно одинаковый поток данных.
>Один из них начал качать раньше. Когда появился второй, то система
>начала ограничивать поток для первого до 110/2=55 Кбит/с. Считая что
>второму также будет отведено 55Кбит/с, однако
.....
в примерах
ipfw queue 1 config pipe 1 weight 50 queue 20
weight 50 - не означает деления канала на части,
а говорит о приоритете, то есть если у двух очередей одинаков приоритет
то пакеты из этих очередей будут выходить по очереди и канал действительно будет делится поровну (если приоритет одинаков).
поэтому если канал реально 80Кбит/с а pipe на 110Кбит/с
вырисовывается другая картина.
если первый пользователь начал раньше качать то его очередь
единственная и он полностью подгребает канал под себя.
если начинает качать второй юзер (подразумевается что приоритеты
очередей у них одинаковы и не обязательно 50) то пакеты из очередей выходят равномерно, а значит скорость делится поровну 80/2=40Кбит/с.
скорость pipe больше чем реальная нужно ставить тогда, когда нужно не ограничить
скорость а распределить по приоритетам.
Я например не зажимаю никого, а всем даю одинаковый приоритет чтоб никто не смог
большим количеством сессий подгребать под себя канал
| | |
|
