|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Eugene B. Berdnikov 2:5020/400 08 Apr 2005 02:08:12
To : "Stanislav Sviridenko"
Subject : Re: HTB QoS приоритетный трафик не получает своей полосы
--------------------------------------------------------------------------------
Stanislav Sviridenko <StanislavS@inet.falkon.ru> wrote:
SS> всем привет, есть задача - организовать приоритизацию трафика.
SS> У меня есть
SS> linux роутер (Ядро 2.4.28 ) - с одной стороны у него езернет (клиенты,
SS> eth2), с другой - узкий канал (eth0).
SS>
SS> Создал такие правила:
SS>
SS> #eth2
SS>
SS> tc qdisc add dev eth2 root handle 1:0 htb default 15 r2q 5
Самая главная ошибка - принципиальная: ЗДЕСЬ шейпить бесполезно.
Для подавляющего большинства задач шейпер должен стоять ПЕРЕД узким
местом, а не после узкого канала перед широким.
Есть ещё одна ошибка, и тоже принципиальная: для игрушек важна
не ширина полосы, а время задержки. Одно из следствий этого - то,
что шейпер должен стоять на стороне провайдера.
SS> 1. Запустил закачку по FTP - скорость закачки максимальная.
SS> (занимается весь канал)
SS> 2. Зашел на сервер контры - скорость закачки стала прыгать в сторону
SS> уменьшения (тоесть более приоритетный трафик стал брать свое от канала)
IMHO, Ваш шейпер здесь ни при чём, :) это задержки в очереди на стороне
провайдера.
Судя по статистике, снижение скорости должно быть всего на два процента,
так что если Вам удалось наблюсти такой эффект, да ещё выделить
статистически значимый сигнал, у Вас неплохие навыки обработки данных. :)
SS> 3. Все бы хорошо, но контре от этого не легче - латенси в игре
SS> переваливает за 1200.
Конечно, ведь на стороне провайдета пакеты игрушки никто не пропускает
перед ftp-шными. Они стоят и ждут своей очереди.
SS> Посмотрел статистику:
SS>
SS> # tc -d -s class show dev eth2
[..]
SS> class htb 1:10 parent 1:1 leaf 10: prio 6 quantum 3200 rate 128Kbit ceil
SS> 1020Kbit burst 1759b/8 mpu 0b cburst 2874b/8 mpu 0b level 0 Sent 3209874
SS> bytes 2121 pkts (dropped 0, overlimits 0) rate 48351bit 31pps lended:
SS> 561 borrowed: 1560 giants: 0 tokens: -74528 ctokens: 8758
[...]
SS> class htb 1:7 parent 1:1 leaf 7: prio 5 quantum 3200 rate 128Kbit ceil
SS> 1020Kbit burst 1759b/8 mpu 0b cburst 2874b/8 mpu 0b level 0
SS> Sent 66739 bytes 806 pkts (dropped 0, overlimits 0)
SS> rate 1048bit 11pps
SS> lended: 806 borrowed: 0 giants: 0
SS> tokens: 82740 ctokens: 17548
SS>
SS> Получается так что FTP может занимать неиспользуемую полосу, но если
SS> более приоритетные приложения (CounterStrike) начинают задействовать свою
SS> полосу - то менее приоритетный трафик (FTP) не зажимается и приоритетному
SS> трафику(CounterStrike) не отдаётся положенная полоса.
Так как средний размер пакета в полосе 1:7 получается всего 83 байта,
а rate в 1:7 _очень_ низкий (меньше процента от 128Кbit), то лимит
bandwidth для этого класса никогда не достигается, и заимствовать
у смежных классов ничего не приходится.
--
Eugene Berdnikov
--- ifmail v.2.15dev5.3
* Origin: Institute for High Energy Physics, Protvino, Russia (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
Re: HTB QoS приоритетный трафик не получает своей полосы 