Jump to content
Калькуляторы

tc шейпинг проблема с задержками

Добрый день уважаемые форумчане,в данный момент пытаюсь настроить шейпинг посредством утилиты ядра tc. Выбрал дисциплину HTB, само разделение канала работает нормально, каждому ипишнику выделяется заданная скорость, но не могу понять как решить проблему задержек если один из пользователей начинает качать, то у других пинги взлетают до 50-100 вместо 3-5мс. Немного улучшает ситуацию, если под дисциплину выделять не всю пропускную способность, а процентов 90, но все равно задержки не стабильны и скачут. Как решается данная проблема у провайдеров?

Share this post


Link to post
Share on other sites

Какая краевая дисциплина используется? Наверное sfq с его короткими очередями. Надо как минимум "pfifo limit 100", а еще лучше codel (man tc-codel).

Share this post


Link to post
Share on other sites

Попробовал с fq_codel, все оффлоады выключил как рекомендуют

ethtool -K eth0 tso off

ethtool -K eth0 gso off

ethtool -K eth0 uso off

ethtool -K eth0 gro off

ethtool -K eth0 ufo off

ethtool -K eth0 lro off

 

Интерфейс у меня работает на 10мбит FD

tc qdisc del dev eth0 root

/sbin/tc qdisc add dev eth0 root handle 1 htb default 30

/sbin/tc class add dev eth0 parent 1: classid 1:2 htb rate 9Mbit

/sbin/tc class add dev eth0 parent 1:2 classid 1:100 htb rate 20Kbit ceil 9Mbit

/sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip src 0.0.0.0/0 match ip dst 192.168.77.23/32 classid 1:100

/sbin/tc class add dev eth0 parent 1:2 classid 1:105 htb rate 20Kbit ceil 9Mbit

/sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip src 0.0.0.0/0 match ip dst 192.168.77.170/32 classid 1:105

/sbin/tc qdisc add dev eth0 parent 1:105 handle 105 fq_codel

/sbin/tc qdisc add dev eth0 parent 1:105 handle 100 fq_codel

 

Т.е. даже с запасом от максимальной скорости в 1 мбит, пинги взлетают до 50, если поставить например 9.5Mbit, то вообще 200. В инете пишут из разряда - прописал tc qdisc add dev eth0 root fq_codel и теперь качаю торренты на полную и играю, пинги как на пустом канале. У меня так не получилось.

Edited by lohmag

Share this post


Link to post
Share on other sites

Тогда вместо htb лучше использовать дисциплину hfsc, там можно указать максимальное время задержки. В качестве краевых классов -- pfifo или codel (без fq).

Share this post


Link to post
Share on other sites

Как решается данная проблема у провайдеров?

Двухкратным запасом по пропускной способности. На практике это и будет лучший QoS.

А вообще, если канал очень узкий и его не хватает на всех (вроде бы речь о 10Мбит/с), то танцы с бубном могут и не помочь.

Допустим удастся сделать красивый "пинг" через приоритеты и т.п., а толку? Остальной трафик как шел еле-еле, так и пойдет.

Share this post


Link to post
Share on other sites

Хорошо, тогда я столкнулся с такой проблемой, при создании скриптом htb.init пишет в лог

 

Feb 26 18:56:25 vsat kernel: [ 8363.461621] HTB: quantum of class 10100 is small. Consider r2q change.

Feb 26 18:56:25 vsat kernel: [ 8363.465288] HTB: quantum of class 10105 is small. Consider r2q change.

Feb 26 18:56:25 vsat kernel: [ 8363.468899] HTB: quantum of class 10030 is small. Consider r2q change.

Feb 26 18:56:25 vsat kernel: [ 8363.471349] HTB: quantum of class 10103 is small. Consider r2q change.

Feb 26 18:56:25 vsat kernel: [ 8363.474958] HTB: quantum of class 10104 is small. Consider r2q change.

Feb 26 18:56:25 vsat kernel: [ 8363.478572] HTB: quantum of class 10030 is small. Consider r2q change.

 

при этом я изменил скрипт и добавил в строчку явное указание для каждого класса quantim 1600, т.е. по идее параметр r2q не должен применяться, но ошибка все равно валится, tckb сделать htb.compile выдаст

/sbin/tc qdisc del dev eth0 root

/sbin/tc qdisc add dev eth0 root handle 1 htb default 30

 

/sbin/tc qdisc del dev eth1 root

/sbin/tc qdisc add dev eth1 root handle 1 htb default 30

 

/sbin/tc class add dev eth0 parent 1: classid 1:2 htb rate 9.7Mbit quantum 1600

 

/sbin/tc class add dev eth0 parent 1:2 classid 1:100 htb rate 12.8Kbit ceil 9.5Mbit quantum 1600

/sbin/tc qdisc add dev eth0 parent 1:100 handle 100 sfq perturb 0 quantum 1600

/sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip src 0.0.0.0/0 match ip dst 192.168.77.23/32 classid 1:100

 

/sbin/tc class add dev eth0 parent 1:2 classid 1:105 htb rate 12.8Kbit ceil 9.5Mbit quantum 1600

/sbin/tc qdisc add dev eth0 parent 1:105 handle 105 sfq perturb 0 quantum 1600

/sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip src 0.0.0.0/0 match ip dst 192.168.77.170/32 classid 1:105

 

/sbin/tc class add dev eth0 parent 1:2 classid 1:30 htb rate 12.8Kbit quantum 1600

 

/sbin/tc class add dev eth1 parent 1: classid 1:2 htb rate 9.7Mbit quantum 1600

 

/sbin/tc class add dev eth1 parent 1:2 classid 1:103 htb rate 12.8Kbit ceil 9.7Mbit quantum 1600

/sbin/tc qdisc add dev eth1 parent 1:103 handle 103 sfq perturb 0 quantum 1600

/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip src 192.168.77.170/32 classid 1:103

 

/sbin/tc class add dev eth1 parent 1:2 classid 1:104 htb rate 12.8Kbit ceil 9.7Mbit quantum 1600

/sbin/tc qdisc add dev eth1 parent 1:104 handle 104 sfq perturb 0 quantum 1600

/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip src 192.168.77.23/32 classid 1:104

 

/sbin/tc class add dev eth1 parent 1:2 classid 1:30 htb rate 12.8Kbit quantum 1600

 

Причем если команды скопировать и вставить, то ошибок нет, а если скриптом htb.init start, то сыпятся. Бред какой-то уже голову сломал почему это. Может у кого были такие "особенности"?

Edited by lohmag

Share this post


Link to post
Share on other sites

Скорее всего, у вас проблема в том, что скорости дочерних классов слишком мелкие (десятки килобит), а MTU у Ethernet слишком большой (1500 байт). Эмулировать такое медленное соединение поверх толстого канала можно только таким образом, что между пакетами будут огромные задержки.

 

Пример с HFSC:

tc qdisc add dev eth0 root handle 1: hfsc default fffe
tc class add dev eth0 parent 1: classid 1:1 hfsc sc rate 9.7Mbit ul rate 9.7Mbit
tc class add dev eth0 parent 1:1 classid 1:100 hfsc sc umax 1540 dmax 10ms rate 12.8Kbit ul rate 9.7Mbit
tc qdisc add dev eth0 parent 1:100 handle 100 codel limit 10

Edited by photon

Share this post


Link to post
Share on other sites

Еще вопрос - в процессе настройки решил, что для каждого адреса создается отдельное правило с скоростью, например: всего 45мбит канал, абоненту дается максимум в 5 мбит, их много. Но хочу сделать дефолтную очередь с максимальной скорость в 40мбит, т.е. если правила для ip нет, то пусть работает на максимуме.

Вопрос - при загруженном канале, с таким дефолтом не будут возникать траблы или подводные камни? Будеи ли заданным абонентам резать справедливо скорость или дефолтники их будут щемить?

Share this post


Link to post
Share on other sites

rate 1M, ceil 40M при родительском классе 45М - думаю на исход нормально будет. А вот на вход - % 10-15 (если не болше) запаса надо делать от суммарного, т.е. родительский класс 40М или менее.

Share this post


Link to post
Share on other sites

А какой будет приоритет у клиента, который попадет в такую дефолтную очередь, потому что при перегрузке у остальных юзеров скорость выставляется пропорционально ceil, не будет ли тогда слишком большого приоритета?

Edited by lohmag

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this