Перейти к содержимому
Калькуляторы

Классовый шейпер для браса потери пакетов после 600мбит

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

Есть 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:?

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

Изменено пользователем 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 давно превратился в любимую настольную книгу))

Изменено пользователем kayot

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Создаю корневую очередь, вешаю на нее класс и 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 очередь исчезает, так и должно быть или я делаю что-то совсем не то?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Изменено пользователем Alex/AT

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем kayot

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.