Классовый шейпер для браса

[kayot]

По следам этой темы

Есть linux-брас терминирующий PPPoE и шейпящий клиентов. Исход шейпится на физическом eth0.2, вход на ifb.

Скрипт управления шейпером генерируется биллингом, там тысячи строк чужого корявого php, сейчас проще переписать все с нуля чем ЭТО изучать..

 

Что нужно - добавить к существующему htb очередь с буфером пакетов и не шейпить трафик между абонентами.

Как сделано сейчас:

// корневой класс
qdisc add dev eth0.2 root handle 2 htb default d
class add dev eth0.2 root htb rate 1000Mbit ceil 1000Mbit
// хеши
filter add dev eth0.2 parent 2:0             protocol ip pref 2 u32
filter add dev eth0.2 parent 2:0 handle 1: protocol ip pref 2 u32 divisor 256
...
// клиенты
tc class add dev eth0.2 parent 2:0 classid 2:100 htb rate 10Mbit ceil 20Mbit prio 3 quantum 65535
filter add dev eth0.2 parent 2:0 protocol ip pref 2 u32 ht 11:d match ip src 10.0.0.1    flowid 2:100
qdisc add dev eth0.2 parent 2:100 handle 100 sfq  perturb 4

Т.е. клиенты вешаются прямо на корневой qdisc 2:0, без разделения на локальный и внешний трафик и с тормозами после какого-то потока трафика.

 

Делаем 2 класса под корневым, 2:1 клиентский, 2:2 внутренний неограничиваемый трафик

qdisc add dev eth0.2 root handle 2 htb default 1
class add dev eth0.2 classid 2:1 htb rate 1000Mbit ceil 1000Mbit
// добавляем очередь с буфером
qdisc add dev eth0.2 parent 2:1 handle 10: pfifo limit 10000
// класс без ограничений скорости
class add dev eth0.2 classid 2:2 htb rate 1000Mbit ceil 1000Mbit
qdisc add dev eth0.2 parent 2:2 handle 9: pfifo limit 10000
// заворачиваем в него локальный трафик
filter add dev eth0.2 parent 2:0 protocol ip pref 2 u32 match ip src 10.0.0.0/8 match ip dst 10.0.0.0/8  flowid 2:2
// хеши
tc filter add dev eth0.2 parent 2:1             protocol ip pref 2 u32
tc filter add dev eth0.2 parent 2:1 handle 1: protocol ip pref 2 u32 divisor 256
// клиенты, может быть несколько хостов
tc class add dev eth0.2 parent 2:1 classid 2:100 htb rate 10Mbit ceil 20Mbit prio 3 quantum 65535
tc filter add dev eth0.2 parent 2:1 protocol ip pref 2 u32 match ip src 10.0.0.1    flowid 2:100
tc filter add dev eth0.2 parent 2:1 protocol ip pref 2 u32 match ip src 10.0.0.2    flowid 2:100
tc qdisc add dev eth0.2 parent 2:1 handle 100 sfq  perturb 4

При применении этой конструкции скорость не режется вообще. Что я делаю не так?

Правильно ли я навешиваю клиентов и хеш-таблицы на класс 2:1? Или их нужно вешать на qdisc 10:?

Ну и правильно ли сделан обход шейпинга локальных адресов?

Edited December 7, 2011 by kayot

[martini]

а что ТОР говорит ? как там софтирки поживают ?? и какой конфиг машинки ?

[kayot]

Загрузка железа нулевая, core i5-2500 + двухголовый ET board(igb).

При трафике 500/500mbit и 650 pppoe сессий:

[kayot@nas3 ~]$ top
top - 22:24:11 up 84 days,  6:50,  1 user,  load average: 0.00, 0.00, 0.00
Tasks: 760 total,   1 running, 759 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.0%us,  0.0%sy,  0.0%ni, 94.1%id,  0.0%wa,  0.0%hi,  5.9%si,  0.0%st
Cpu1  :  1.0%us,  1.0%sy,  0.0%ni, 94.1%id,  0.0%wa,  0.0%hi,  4.0%si,  0.0%st
Cpu2  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  0.0%us,  0.0%sy,  0.0%ni, 96.0%id,  0.0%wa,  0.0%hi,  4.0%si,  0.0%st
Mem:   4006656k total,  2097820k used,  1908836k free,   297636k buffers
Swap:  2771172k total,        0k used,  2771172k free,   956292k cached
 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
25959 kayot     20   0 15428 1748  920 R  2.0  0.0   0:00.12 top
   4 root      15  -5     0    0    0 S  1.0  0.0 122:01.31 ksoftirqd/0
5432 named     20   0  378m 133m 2812 S  1.0  3.4 547:49.77 named
23753 root      20   0 28848 1904 1612 S  1.0  0.0   0:00.03 pppd
   1 root      20   0  4112  900  636 S  0.0  0.0   0:02.39 init
   2 root      15  -5     0    0    0 S  0.0  0.0   0:00.00 kthreadd

В соседней теме подобную проблему решили добавлением qdisc типа pfifo с большой очередью пакетов, у себя я не пойму как этот буфер правильно добавить. Lartc давно превратился в любимую настольную книгу))

Edited December 7, 2011 by kayot

[Alex/AT]

Попробуйте перепрыгнуть на HFSC. С HTB была именно такая засада - нагрузка нулевая, а потери пакетов есть.

[photon]

Попробуйте перепрыгнуть на HFSC. С HTB была именно такая засада - нагрузка нулевая, а потери пакетов есть.

Когда есть потери, надо просто увеличивать размеры очередей дочерних классов. Если в качестве краевых дисциплин используются bfifo/pfifo, то это параметр limit. Тем не менее, HFSC интересная дисциплина, надо будет посмотреть.

Edited December 8, 2011 by photon

[kayot]

Зашел в тупик.

Создаю корневую очередь, вешаю на нее класс и pfifo очередь с буфером.

tc qdisc add dev eth0.2 root handle 2: htb default 1
tc class add dev eth0.2 parent 2: classid 2:1 htb rate 1000Mbit ceil 1000Mbit
tc qdisc add dev eth0.2 parent 2:1 handle 7: pfifo limit 10000

Трафик весело бегает, все ок.

#tc -s -d qdisc  show dev eth0.2 && tc -s -d class show dev eth0.2

qdisc htb 2: root r2q 10 default 1 direct_packets_stat 35 ver 3.17
Sent 121103682 bytes 174879 pkt (dropped 1, overlimits 28732 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
qdisc pfifo 7: parent 2:1 limit 10000p
Sent 121057350 bytes 174809 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
class htb 2:1 root leaf 7: prio 0 quantum 200000 rate 1000Mbit ceil 1000Mbit burst 1375b/8 mpu 0b overhead 0b cburst 1375b/8 mpu 0b overhead 0b level 0
Sent 121104691 bytes 174905 pkt (dropped 1, overlimits 0 requeues 0)
rate 36745Kbit 6562pps backlog 0b 0p requeues 0
lended: 174905 borrowed: 0 giants: 0
tokens: 125 ctokens: 125

Добавляю к корневому классу клиента

#tc class add dev eth0.2 parent 2:1 classid 2:100 htb rate 2Mbit ceil 2Mbit prio 3 quantum 65535

- и не понимаю что происходит

#tc -s -d qdisc  show dev eth0.2 && tc -s -d class show dev eth0.2

qdisc htb 2: root r2q 10 default 1 direct_packets_stat 84874 ver 3.17
Sent 6724170626 bytes 9113275 pkt (dropped 1, overlimits 2479772 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
class htb 2:100 parent 2:1 prio 3 quantum 65535 rate 2000Kbit ceil 2000Kbit burst 1600b/8 mpu 0b overhead 0b cburst 1600b/8 mpu 0b overhead 0b level 0
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
lended: 0 borrowed: 0 giants: 0
tokens: 100000 ctokens: 100000

class htb 2:1 root rate 1000Mbit ceil 1000Mbit burst 1375b/8 mpu 0b overhead 0b cburst 1375b/8 mpu 0b overhead 0b level 7
Sent 6655571219 bytes 9028401 pkt (dropped 1, overlimits 0 requeues 0)
rate 193612Kbit 30918pps backlog 0b 0p requeues 0
lended: 9028401 borrowed: 0 giants: 0
tokens: 187 ctokens: 187

Куда-то pfifo очередь исчезает, так и должно быть или я делаю что-то совсем не то?

[kayot]

Когда есть потери, надо просто увеличивать размеры очередей дочерних классов. Если в качестве краевых дисциплин используются bfifo/pfifo, то это параметр limit. Тем не менее, HFSC интересная дисциплина, надо будет посмотреть.

Т.е. если у меня есть корневой класс 2:1 и от него идет несколько тысяч клиентских классов 2:100-2:xxxx буфер нужно добавлять именно тут? Не к корневому классу?

[photon]

Т.е. если у меня есть корневой класс 2:1 и от него идет несколько тысяч клиентских классов 2:100-2:xxxx буфер нужно добавлять именно тут? Не к корневому классу?

По обстоятельствам. Очередь корневого класса -- это очередь интерфейса, к которому он привязан. Если проблема действительно связана не с приемом пакетов (что встречается намного чаще), а с отправкой, то надо увеличить очередь интерфейса (ifconfig ... txqueuelen 4000), а также размеры очередей дочерних классов. Кроме того, есть аппаратные RX/TX-буферы, которые можно потрогать с помощью ethtool.

[Alex/AT]

Куда-то pfifo очередь исчезает, так и должно быть или я делаю что-то совсем не то?

Очереди (pfifo/sfq/etc.) можно повесить только на классы-"листья", т.е. на концевые классы. В середине очередей не бывает.

[kayot]

Понял, буду пилить. Всем спасибо.

[martini]

так а потери начинаются у абонентов ? или только dropped у qdisc корневого начинаются ?

[kayot]

Растет dropped у корневого qdisc, а у абонентов не достигается тарифная скорость при не загруженном канале.

 

Похоже разобрался. У клиентов использовался SFQ, плохо работающий с большими скоростями на загруженных серверах(маленькая очередь в 127 пакетов). Плюс, трафик абонентов без ограничения скорости сливался в дефолтный класс с тем же SFQ, тут потери проявлялись еще раньше.

Поменял клиентам дисциплину на pfifo с limit 1000, дефолтному классу поставил её же с limit 10000 - пока полет нормальный, дропов практически нет.

[Alex/AT]

Хм. У нас SFQ работает на всех клиентах, скорости от 1 до 100 мегабит, сквозной трафик порядка 3 Гбит, порядка 500 Kpps на сторону на BRAS. Никаких затыков не отмечено.

Без SFQ абоненты с торрентами будут очень недовольны тем, что у них во время закачки страницы "не открываются".

Edited December 10, 2011 by Alex/AT

[kayot]

Нужно будет еще поэкспериментировать, но пока жалоб не было. Проводил сегодня краш-тест, выключил часть НАСов, оставшиеся работали с загрузкой до 95% - никаких тормозов или потерь. Раньше глюки начинались уже при 20% загрузки на ядро(точнее, начиная с какого-то числа ppp-сессий и соответственно PPS).

Edited December 10, 2011 by kayot

[Dark_Angel]

+1 за SFQ. Тоже используем и всё работает как задумано.

[kayot]

Поймали таки сегодня ситуацию когда клиент загрузил сам себе канал в планку, получил пинг в 1000мс и нерабочий интернет, и очень этому факту огорчился :)

 

Вернул SFQ на клиентов, пока полет нормальный.

[disappointed]

А я вот отмечал, что с SFQ при заказчке торрентом больше оверхэд по полосе получается, если клиент полку делает, дохера дропается.

Поймали таки сегодня ситуацию когда клиент загрузил сам себе канал в планку, получил пинг в 1000мс

Ну а чего в этом такого, либо шейпинг либо полисинг.

[Dark_Angel]

Их тех очередей, что я тестировал - SFQ давал самые хорошие и честные характеристики по лимитам. Говорю о пинге, дроп рейте и полезной полосе со стороны клиента. Ну и среднезатрано по ресурсам. Мне кажется оптимально. Правда тогда еще не было uTorrent с мелкими UDP, может сейчас ситуация изменилась и надо юзать другие очереди?