kayot Опубликовано 7 декабря, 2011 (изменено) · Жалоба По следам этой темы Есть 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:? Ну и правильно ли сделан обход шейпинга локальных адресов? Изменено 7 декабря, 2011 пользователем kayot Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martini Опубликовано 7 декабря, 2011 · Жалоба а что ТОР говорит ? как там софтирки поживают ?? и какой конфиг машинки ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 7 декабря, 2011 (изменено) · Жалоба Загрузка железа нулевая, 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 давно превратился в любимую настольную книгу)) Изменено 7 декабря, 2011 пользователем kayot Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 8 декабря, 2011 · Жалоба Попробуйте перепрыгнуть на HFSC. С HTB была именно такая засада - нагрузка нулевая, а потери пакетов есть. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 8 декабря, 2011 (изменено) · Жалоба Попробуйте перепрыгнуть на HFSC. С HTB была именно такая засада - нагрузка нулевая, а потери пакетов есть. Когда есть потери, надо просто увеличивать размеры очередей дочерних классов. Если в качестве краевых дисциплин используются bfifo/pfifo, то это параметр limit. Тем не менее, HFSC интересная дисциплина, надо будет посмотреть. Изменено 8 декабря, 2011 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 8 декабря, 2011 · Жалоба Зашел в тупик. Создаю корневую очередь, вешаю на нее класс и 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 очередь исчезает, так и должно быть или я делаю что-то совсем не то? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 8 декабря, 2011 · Жалоба Когда есть потери, надо просто увеличивать размеры очередей дочерних классов. Если в качестве краевых дисциплин используются bfifo/pfifo, то это параметр limit. Тем не менее, HFSC интересная дисциплина, надо будет посмотреть. Т.е. если у меня есть корневой класс 2:1 и от него идет несколько тысяч клиентских классов 2:100-2:xxxx буфер нужно добавлять именно тут? Не к корневому классу? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 8 декабря, 2011 · Жалоба Т.е. если у меня есть корневой класс 2:1 и от него идет несколько тысяч клиентских классов 2:100-2:xxxx буфер нужно добавлять именно тут? Не к корневому классу? По обстоятельствам. Очередь корневого класса -- это очередь интерфейса, к которому он привязан. Если проблема действительно связана не с приемом пакетов (что встречается намного чаще), а с отправкой, то надо увеличить очередь интерфейса (ifconfig ... txqueuelen 4000), а также размеры очередей дочерних классов. Кроме того, есть аппаратные RX/TX-буферы, которые можно потрогать с помощью ethtool. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 8 декабря, 2011 · Жалоба Куда-то pfifo очередь исчезает, так и должно быть или я делаю что-то совсем не то? Очереди (pfifo/sfq/etc.) можно повесить только на классы-"листья", т.е. на концевые классы. В середине очередей не бывает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 8 декабря, 2011 · Жалоба Понял, буду пилить. Всем спасибо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martini Опубликовано 9 декабря, 2011 · Жалоба так а потери начинаются у абонентов ? или только dropped у qdisc корневого начинаются ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 9 декабря, 2011 · Жалоба Растет dropped у корневого qdisc, а у абонентов не достигается тарифная скорость при не загруженном канале. Похоже разобрался. У клиентов использовался SFQ, плохо работающий с большими скоростями на загруженных серверах(маленькая очередь в 127 пакетов). Плюс, трафик абонентов без ограничения скорости сливался в дефолтный класс с тем же SFQ, тут потери проявлялись еще раньше. Поменял клиентам дисциплину на pfifo с limit 1000, дефолтному классу поставил её же с limit 10000 - пока полет нормальный, дропов практически нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 10 декабря, 2011 (изменено) · Жалоба Хм. У нас SFQ работает на всех клиентах, скорости от 1 до 100 мегабит, сквозной трафик порядка 3 Гбит, порядка 500 Kpps на сторону на BRAS. Никаких затыков не отмечено. Без SFQ абоненты с торрентами будут очень недовольны тем, что у них во время закачки страницы "не открываются". Изменено 10 декабря, 2011 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 10 декабря, 2011 (изменено) · Жалоба Нужно будет еще поэкспериментировать, но пока жалоб не было. Проводил сегодня краш-тест, выключил часть НАСов, оставшиеся работали с загрузкой до 95% - никаких тормозов или потерь. Раньше глюки начинались уже при 20% загрузки на ядро(точнее, начиная с какого-то числа ppp-сессий и соответственно PPS). Изменено 10 декабря, 2011 пользователем kayot Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 13 декабря, 2011 · Жалоба +1 за SFQ. Тоже используем и всё работает как задумано. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 13 декабря, 2011 · Жалоба Поймали таки сегодня ситуацию когда клиент загрузил сам себе канал в планку, получил пинг в 1000мс и нерабочий интернет, и очень этому факту огорчился :) Вернул SFQ на клиентов, пока полет нормальный. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
disappointed Опубликовано 13 декабря, 2011 · Жалоба А я вот отмечал, что с SFQ при заказчке торрентом больше оверхэд по полосе получается, если клиент полку делает, дохера дропается. Поймали таки сегодня ситуацию когда клиент загрузил сам себе канал в планку, получил пинг в 1000мс Ну а чего в этом такого, либо шейпинг либо полисинг. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 14 декабря, 2011 · Жалоба Их тех очередей, что я тестировал - SFQ давал самые хорошие и честные характеристики по лимитам. Говорю о пинге, дроп рейте и полезной полосе со стороны клиента. Ну и среднезатрано по ресурсам. Мне кажется оптимально. Правда тогда еще не было uTorrent с мелкими UDP, может сейчас ситуация изменилась и надо юзать другие очереди? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...