[Стич]

вот перехожу c htb на hfsc. (htb умирает при 4гбит)

но hfsc при 2гбит начинает блокировать весь трафик на том интерфейсе где он висит.

может кто-нибудь сталкивался

 

    $TC qdisc add dev eth1 root handle fffe: hfsc default fffc

   $TC class add dev eth1 parent fffe:0 classid fffe:fffc hfsc sc rate 10Gbit ul rate 10Gbit
   $TC qdisc add dev eth1 parent fffe:fffc handle fffc: pfifo limit 10000
   $TC filter add dev eth1 protocol all parent fffe:0 prio 90 u32 match u32 0 0 flowid fffe:fffc

   ip хэши для клиентов
   $TC filter add dev $DEV_IMQ parent fffe:0 prio 20 protocol ip u32

клиентский класс
$TC class add dev  eth1 parent  fffe:0 classid fffe::xxxx hfsc sc rate speedKbit ul rate speedKbit
$TC qdisc add dev eth1 parent fffe:xxxx handle xxxx: pfifo limit 10000

 

p.s. про полисеры знаю пока не рассматриваю

Изменено 21 февраля, 2017 пользователем Стич

[vop]

Попробуйте перенести фильтры в ipset.

[Стич]

Попробуйте перенести фильтры в ipset.

как. можно принцип пояснить

[Antares]

может эта статья поможет? https://www.altlinux.org/%D0%A8%D0%B5%D0%B9%D0%BF%D0%B5%D1%80%D0%94%D0%BB%D1%8F%D0%91%D0%BE%D0%BB%D1%8C%D1%88%D0%B8%D1%85%D0%A1%D0%B5%D1%82%D0%B5%D0%B9

[Стич]

Вы думаете если я вынесу фильтры в ipset

перестанет блокироваться весь трафик на 2ГБит/c

[vop]

Вы думаете если я вынесу фильтры в ipset

перестанет блокироваться весь трафик на 2ГБит/c

 

Есть версии, почему у вас перестает проходить трафик? Default class никуда не пропадает?

 

Если проквалифицируете через таблички bitmap, то задача для сервера существенно упростится. Как по мне, это надо делать сразу.

[nuclearcat]

Сталкивался с подобным. Решал через "одно место", так как время поджимало - увеличивал quantum/burst/cburst.

Когда перевалило через 7 гиг - пришлось патчить ядро.

Причину так и не нашел. HFSC проявил себя хуже чем HTB.

[vop]

Переход на hfsc делали именно из-за того, что пляски с quantum/burst/cburst надоели.

[Стич]

Вы думаете если я вынесу фильтры в ipset

перестанет блокироваться весь трафик на 2ГБит/c

 

Есть версии, почему у вас перестает проходить трафик? Default class никуда не пропадает?

 

Если проквалифицируете через таблички bitmap, то задача для сервера существенно упростится. Как по мне, это надо делать сразу.

Так ворде дефаулт класс у меня создан.

У вас hfsc на какой скорости работает, у меня блок трафика только после 2ГБит/c.

 

 

nuclearcat

Сталкивался с подобным. Решал через "одно место", так как время поджимало - увеличивал quantum/burst/cburst.

Когда перевалило через 7 гиг - пришлось патчить ядро.

Причину так и не нашел. HFSC проявил себя хуже чем HTB.

Подскажите как у Вас htb до 7 гиг работал.

У меня ведет себя примерно так:

Загрузка ядер 30%, при снятии шепера у абонентов всё прекрасно.

После 4 гиг начинает не довешивать скорость абонентам, на 100МБит тарифах получает 50МБит

Увеличил до HZ=1000 и квантум до 60000. ситауция стала на 100МБит тарифах получает 80МБит

Буду рад услышать советы что с ним сделать.

Изменено 22 февраля, 2017 пользователем Стич

[nuclearcat]

Для ведра такой тупой патч:

diff -Naur linux-4.7/net/sched/sch_htb.c linux-4.7-patched2/net/sched/sch_htb.c
--- linux-4.7/net/sched/sch_htb.c	2016-07-24 19:23:50.000000000 +0000
+++ linux-4.7-patched2/net/sched/sch_htb.c	2016-09-24 03:36:39.538152781 +0000
@@ -1489,15 +1489,15 @@
		do_div(quantum, q->rate2quantum);
		cl->quantum = min_t(u64, quantum, INT_MAX);

-		if (!hopt->quantum && cl->quantum < 1000) {
-			pr_warn("HTB: quantum of class %X is small. Consider r2q change.\n",
-				cl->common.classid);
-			cl->quantum = 1000;
+		if (!hopt->quantum && cl->quantum < 1600) {
+//			pr_warn("HTB: quantum of class %X is small. Consider r2q change.\n",
+//				cl->common.classid);
+			cl->quantum = 1600;
		}
-		if (!hopt->quantum && cl->quantum > 200000) {
-			pr_warn("HTB: quantum of class %X is big. Consider r2q change.\n",
-				cl->common.classid);
-			cl->quantum = 200000;
+		if (!hopt->quantum && cl->quantum > 2000000) {
+//			pr_warn("HTB: quantum of class %X is big. Consider r2q change.\n",
+//				cl->common.classid);
+			cl->quantum = 2000000;
		}
		if (hopt->quantum)
			cl->quantum = hopt->quantum;

tc class add dev eth3.777 parent 1: classid 1:1 est 4sec 16sec htb rate ${MAXBW} ceil ${MAXBW} burst 100000 cburst 100000 #корневой

tc class add dev eth3.777 parent 1:1 classid 1:20 est 4sec 16sec htb rate XXXMbit ceil ${MAXBW} burst 10000 cburst 10000 #дочерние

 

qdisc для дочерних применять или pie или pfifo, на остальных может помереть гораздо раньше.

[Стич]

Спасибо за патч.

как я понял из патча у Вас quantum от мин 1600 до максимально 2000000.

Поделись r2q какой у Вас?

до скольких мегабит патч держит?

Изменено 22 февраля, 2017 пользователем Стич

[nuclearcat]

дефолтовый, с этим я не экспериментировал (и похоже зря)

[nuclearcat]

по мегабитам не помню, суммарно через этот тазик бегало около 7 гиг, дальше переделал схему, чтобы не упереться в микроберсты и дропы с ними связанные

[vop]

У вас hfsc на какой скорости работает, у меня блок трафика только после 2ГБит/c.

 

У меня до гигабита, так-что тут опытом не поделюсь.

[kayot]

nuclearcat

if (!hopt->quantum && cl->quantum > 200000) {

Очень интересно.

Получается, нынче можно quantum ставить в 200к, а я всю жизнь считал что предел 65к(когда-то было так, да и во всех манах это число).

Пора править свои скрипты.

[Стич]

Ни чего не помогло с htb, похоже на таких скоростях это путь в никуда.

Пришлось полисить

tc filter police rate drop

[vop]

А фильтры, все же, не пробовали в ipset перенести?

[Стич]

Если фильтры перенести в ipset, теряется гибкость потому что с ipset можно направить только в classfull дисциплины,

которые как показала практика не дружат с потоками в несколько гигбит.

Используя хэш таблцы я могу например для тарифов до 30МБит/c применять htb, на тарифах выше 30МБит/c полисинг на фильтрах.

Что сейчас и делаю.

Изменено 1 марта, 2017 пользователем Стич

[kayot]

Стич

А можно попросить пример такого смешанного шейпера? Давно хочу на полисинг перейти, но не совсем понимаю как скрестить ужа и ежа.

[bomberman]

пожалуй присоеденюсь к просьбе,kayot. Позвольте полюбопытствовать Ваш подход, вернее реализацию.

[SABRE]

kayotbomberman

просто в фильтре, вместо назначения classid сделать action police.

[kayot]

SABRE

Хеш-фильтры остаются без изменений?

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

[Стич]

tc qdisc add dev eth0 root handle fffe: htb default fffd r2q 80

filter add dev eth0 parent fffe:0 prio 5 protocol ip u32

Xэш фильтры остаются без ихменений, только заканчивать их надо разными фильтрами

Для htb:

tc filter add dev eth0 parent fffe:0 protocol ip prio 100 handle xxx:xx: match ip dst xx.xx.xx.xx flowid xx

Для police

tc filter add dev eth0 parent fffe:0 protocol ip prio 100 handle xxx:xx: match ip dst xx.xx.xx.xx police rate mySpeed kbit burst myBurst drop flowid fffe:fffd

 

Причем я класс fffe:fffd не создаю дабы не грузить лишним трафиком htb.

Исходящий я вообще весь на police перевёл.

Изменено 3 марта, 2017 пользователем Стич

[SABRE]

полисить рекомендуют на входящем. Али без разницы?

Без. Это лишь разные механизмы управления трафиком.

Причем я класс fffe:fffd не создаю дабы не грузить лишним трафиком htb.

А разве этот трафик в дефолтный класс HTB не попадает?

[Стич]

А дефолтный то же не создан.

Не знаю правильно ли это или нет.

Но опирался на идею что нету класса нету ненужной нагрузки на htb.