| 1.1, Nick (??), 12:10, 01/12/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 > [Router]---[Shaper]---[Router]
Да таких хавату пруд-пруди.
А вот если сам роутер является одним из потребителей инета одновременно с клиентами _за_ ним - то на этот вопрос и линух толком не отвечает...
| | |
| |
| 2.2, fa (??), 12:47, 01/12/2008 [^] [^^] [^^^] [ответить]
| +/– |
 Зря Вы так. Статья хорошая. Кратко и по делу. Даже с готовым решением.
Кстати, подскажите, как правильно выбрать верхнюю планку канала (то, что в статье urate и drate). Пару раз приходилось чуть ли не воевать с клиентами, которым ставил шейпер. Все норовят поставить число повыше.
| | |
| |
| 3.3, terminus (ok), 13:06, 01/12/2008 [^] [^^] [^^^] [ответить]
| +/– |
С научной точки зрения не расскажу, потому, что не помню уже как расчитывать (лабараторки делали, но было это давно) :(
Но в общем есть такая вешь в теории информации - есть теоремы доказывающие, что при передаче сигнала в канале с задержкой и потерями, обеспечить передачу без потерь можно только тогда, когда скорость источника меньше скорости канала (короче канал должен быть чуть больше чем скорость источника). Вот поэтому и зарезают на шейпере делая чуть меньше иначе начинают проявляться непредвиденные потери.
Кто конкретней опишет как расчитывать? Обычно, кажется, выставляют на 1-2% меньше.
| | |
| |
| 4.6, Дмитрий Иванов (?), 13:49, 01/12/2008 [^] [^^] [^^^] [ответить]
| +/– |
 Теория информации здесь ни при чем. Скорее, теория очередей, a.k.a. теория массового обслуживания.
| | |
|
| 3.4, Nick (??), 13:22, 01/12/2008 [^] [^^] [^^^] [ответить] | +/– | Ну, как грицо, социализм - это контроль и учет Контроль - понятно, а вот учет... большой текст свёрнут, показать | | |
| |
| 4.7, Дмитрий Иванов (?), 13:53, 01/12/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Автор сделал верхнюю планку ниже (не суть на сколько) с подчеркнутой целью:
>
>создать очередь своих клиентов у себя, а не у ISP. Почему это
>так для него важно - в статье, увы, не рассмотрено и
>принято за аксиому.
.........
>[оверквотинг удален]
>обслуживать наши упорядоченные запросы - уже нашего шейпера касаться не должны.
>Но если касаются, и реальная пропускная ниже установленной в нашем шейпере
>( < urate) - то в конце концов дропы (ответное падение
>пропускной) постигнут наших клиентов в любом случае.
>Возможно, автор опасается именно этого, (а на практике апстримы могут реально давать
>такие результаты) и принимает алгоритм дропа как случайный - то да,
>чтобы улучшить качество приоритезации - стоит опустить планку ниже апстрима.
>Но если алгоритм дропа _может_ учитывать заданные параметры шейпера и дропать недополученную
>полосу у всех клиентов согласно их лимитам - то любое падение
>пропускной апстрима отразится на всех клиентах ожидаемым образом, согласно лимитам.
Да, вы более развернуто объяснили то, что мне казалось очевидным.
| | |
| |
| 5.8, Nick (??), 14:08, 01/12/2008 [^] [^^] [^^^] [ответить]
| +/– | |
Я вообще, по жизни, не занимался глубокими изысканиями в этом вопросе: насколько высоко задавать планку шейпера.
Но я изучал "Достаточно общую теорию управления" (ДОТУ) авторского коллектива ВП СССР.
Как видите, она дает возможность войти в любую проблемматику и дать достаточно полный анализ.
Горячо рекомендую всем и каждому с целью повышения управленческих способностей:
http://dotu.ru/2004/06/23/20040623-dotu_red-2004/
Или в виде аудиокниги:
http://kob.in.ua/sound/dotu_audioboock.rar
ДОТУ лежит в основе Концепции общественной безопасности (КОБ),
которая является единственным (без преувеличений) выходом из того развала,
куда нас опустили в процессе "независимости" после развала СССР.
Рекомендуется всем думающим людям.
Кратко и наглядно изложено в видеолекциях Петрова:
http://pravdu.ru/lessons/petrov/
PS Не примите за спам, ибо это реальные и очень важные знания.
| | |
|
|
| 3.5, Дмитрий Иванов (?), 13:48, 01/12/2008 [^] [^^] [^^^] [ответить]
| +/– | |
Верхнюю планку следует выставлять немного ниже толщины канала. На практике где-то 95%. Главным образом определяется точностью шейпера у вас и у апстрима. Или точностью определения толщины канала (тут тоже бывают варианты). Главное, чтобы очередь гарантированно была у вас, а не в другом месте. В этом главная идея QoS: переносим очередь в то место, где можем управлять ею.
| | |
|
| 2.12, Аноним (12), 16:50, 01/12/2008 [^] [^^] [^^^] [ответить]
| +/– | |
> А вот если сам роутер является одним из потребителей инета одновременно с клиентами _за_ ним - то на этот вопрос и линух толком не отвечает...
Да ну?!
"А мужики-то не знают!.." (с)
Видимо, это только у юнг не работает.
| | |
| |
| 3.13, Nick (??), 17:04, 01/12/2008 [^] [^^] [^^^] [ответить]
| +/– |
>> А вот если сам роутер является одним из потребителей инета одновременно с клиентами _за_ ним - то на этот вопрос и линух толком не отвечает...
>
>Да ну?!
>"А мужики-то не знают!.." (с)
>Видимо, это только у юнг не работает.
ок, слушаю "на пальцах" как классифицировать пакет-ответ (входящий во интерфейс) на реальный аддресс, за которым сидят И проги с самого роутера И клиенты в локалке.
Т.е. пакет-ответ идет на адресс, на котором осуществляеццо SNAT.
За сим, информации о том кому на самом деле направляется пакет (самому роутеру или одному из клиентов - что доступно только на этапе deNAT'а, а он много дальше, чем ingress на ифейсе с реальным ИП по тракту IP модуля) на этапе входящего (а только там можно зажать траффик для самого роутера) шейпинга.
Я даже предпринял попытку реализовать это дело. Даже написал патч и отправил. Меня послали, но указали в чем я был неправ.
Вобщем, я весь во внимании. ДОпускаю, что чего-то я и не заметил.
| | |
| |
| 4.14, terminus (ok), 18:20, 01/12/2008 [^] [^^] [^^^] [ответить]
| +/– | |
На ipfw можно очень по-разному организовать, что сначала - шейпинг или нат. Вот кривиникий пример который будет шейпить все сразу и для клиентов за натом и для самого рутера.
em0 - inet
fxp0 - lan
--
/etc/sysctl.conf
net.inet.ip.fw.one_pass: 0
--
ipfw add 100 allow all from any to any via lo0
ipfw add 210 pipe 100 config bw 95Mbit/s
ipfw add 220 pipe 200 config bw 95Mbit/s
ipfw add 230 queue 111 config weight 30 queue 50 pipe 100 gred 0.002/5/15/0.05
ipfw add 240 queue 112 config weight 70 queue 50 pipe 100 gred 0.002/5/15/0.05
ipfw add 231 queue 211 config weight 30 queue 50 pipe 200 gred 0.002/5/15/0.05
ipfw add 241 queue 212 config weight 70 queue 50 pipe 200 gred 0.002/5/15/0.05
ipfw add 250 queue 111 udp from me to any out via em0
ipfw add 260 queue 112 tcp from me to any out via em0
ipfw add 270 queue 211 udp from any to me in via em0
ipfw add 280 queue 212 tcp from any to me in via em0
ipfw add 290 check-state
ipfw add 300 allow tcp from me to any out via em0 keep-state
ipfw add 400 allow udp from me to any out via em0 keep-state
ipfw add 500 allow ip from me to any out via em0 keep-state
ipfw add 550 queue 111 udp from any to any out via em0
ipfw add 560 queue 112 tcp from any to any out via em0
ipfw add 800 nat 1 config if em0 log deny_in reset same_ports
ipfw add 900 nat 1 all from any to any via em0
ipfw add 1024 allow all from any to any
--
Почитайте вот этот материал - просветляет очень :)
http://nuclight.livejournal.com/124348.html
| | |
|
|
|
| 1.11, adsh (ok), 16:23, 01/12/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 А как соотносятся:
net.inet.ip.dummynet.hash_size=1024
net.inet.ip.fw.dyn_buckets=1024
если у имеется 4900 динамических очередей? Не мало?
| | |
|
