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

Проблема с шейпером

Коллеги, помогите найти подвох. Есть NAS-сервера, коммутируют VPN-сессии клиентов для раздачи Интернета (accel-ppp), есть скрипт шейпера в ip-up. Поменялись тарифы в конторе. Было 16 Мбит/сек, стало - 25 Мбит/сек. Так вот вот те, кто сидел на 16 и перешел на 25, говорят что раньше было все нормально, а после смены тарифы стало еще хежу чем было, т.е. мало того, что нет 25, так стало еще и меньше 16. Классы накладываются правильно, не пойму в чем проблема...

 

#!/bin/bash

TC="/sbin/tc"
DEV=$1

# Скорость физического интерфейса:
IFSPEED="1Gbit"

if [ -f /var/run/radattr.$1 ]
then

# Входящая для клиента (исходящая для сервера):
DOWN=`/usr/bin/awk '/PPPD-Downstream-Speed-Limit/ {print $2}' /var/run/radattr.$1`

# Исходящая для клиента (входящая для сервера):
UP=`/usr/bin/awk '/PPPD-Upstream-Speed-Limit/ {print $2}' /var/run/radattr.$1`

# Очищаем:
$TC qdisc del dev $DEV root
$TC qdisc del dev $DEV ingress

if [ "$DOWN" != "0" ] ;
	then
	DOWN10=`echo $DOWN/10 | bc 2>/dev/null`
	BURST=`echo $DOWN/20 | bc 2>/dev/null`

	# Создаем корневую очередь со скоростью общего входящего канала:
	# cbq	- дисциплина обработки очереди
	# avpkt	- средний размер пакета, для ethernet-интерфейсов можно считать его равным 1000 байт при mtu 1500 байт
	# bandwidth - физическая прпускная способность железки
	$TC qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth $IFSPEED

	# Создаем класс со скоростью согласно тарифу:
	# bounded - запрещает классу занимать свободную полосу от каналов с параметром sharing
	$TC class add dev $DEV parent 1: classid 1:1 cbq bandwidth $IFSPEED rate ${DOWN}kbit prio 1 allot 1514 cell 8 maxburst 6 mpu 700 avpkt 1000 bounded
	$TC class add dev $DEV parent 1: classid 1:2 cbq bandwidth $IFSPEED rate ${DOWN10}kbit prio 2 allot 1514 cell 8 maxburst 6 mpu 700 avpkt 1000 bounded

	# Классифицируем трафик:
	# u32 - классификатор, позволяющий классифицировать пакеты на основании их атрибутов
	# match u32 x y - задаёт значение, с которым будут сравниваться биты из пакета (x) и размер блока данных (y, битовая маска),
	#                 который будет взят из пакета
	#
	# icmp
	$TC filter add dev $DEV parent 1: protocol ip prio 1 u32 match ip protocol 1 0xff flowid 1:1
	#
	# Type of Service - 0x10 minimize-delay
	$TC filter add dev $DEV parent 1: protocol ip prio 2 u32 match ip tos 0x10 0xff flowid 1:2
	#
	# udp
	#~ $TC filter add dev $DEV parent 1: protocol ip prio 2 u32 match ip protocol 17 0xff flowid 1:2
	#
	# Тафтология, но по факту попадает под все пакеты:
	$TC filter add dev $DEV parent 1: protocol all u32 match u32 0 0 flowid 1:1

	# Для более равномерного распределения пропускной пособностями между соединениями прицепим в классу
	# дисциплину обработки очереди SFQ:
	# perturb - этот параметр задает интервал в секундах, через который происходит изменение функции
	$TC qdisc add dev $DEV parent 1:1 sfq perturb 10
	$TC qdisc add dev $DEV parent 1:2 sfq perturb 10

fi

if [ "$UP" != "0" ] ;
	then

	BURST=`echo $UP/20 | bc 2>/dev/null`

	# Корневой класс исходящщего канала:
	$TC qdisc add dev $DEV handle ffff: ingress

	# Этот фильтр контролирует резкое увеличение трафика
	#~ $TC filter add dev $DEV parent ffff: protocol all u32 match ip src 0.0.0.0/0 police rate ${SPEED}kbit burst ${BURST}k mtu 1496 drop flowid :1
	$TC filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src 0.0.0.0/0 police rate ${UP}kbit burst ${BURST}k mtu 1496 drop flowid :1

fi
fi

Share this post


Link to post
Share on other sites

SFQ иногда лажает при увеличении скоростей, попробуйте pfifo limit 50 вместо sfq perturb 10.

 

Прочитал скрипт более внимательно. Вижу, что используется cbq с кучей наворотов, там где достаточно просто tbf. Приоритизацию разных типов трафика лучше делать не в пользовательских классах, а на border router который стоит за шейпером.

Edited by photon

Share this post


Link to post
Share on other sites

А какое количество трафика проходит через сервак и как себя чувствует LA???

В среднем порядка 600 Мбит/сек, la около 2.

Edited by morfair

Share this post


Link to post
Share on other sites

Прежде чем что-то тюнинговать, надо выяснить какая подсистема ядра больше всего нагружает процессор с помощью perf или oprofile.

Edited by photon

Share this post


Link to post
Share on other sites

Приоритизацию разных типов трафика лучше делать не в пользовательских классах, а на border router который стоит за шейпером.

И там и там. В первом случае - у юзера при работающем торренте шелковистые пинги и ютуб не тормозит, во втором - при полке на канале все более-менее работает.

Share this post


Link to post
Share on other sites

Приоритизацию разных типов трафика лучше делать не в пользовательских классах, а на border router который стоит за шейпером.

И там и там. В первом случае - у юзера при работающем торренте шелковистые пинги и ютуб не тормозит, во втором - при полке на канале все более-менее работает.

Первую проблему банальная дисциплина sfq решает изумительно. Вторую не решает ничто, все равно ведь канал расширять придется.

Share this post


Link to post
Share on other sites

Первую проблему банальная дисциплина sfq решает изумительно.

Если торрент сосет в 100500 потоков, а ютуб в 1 - sfq прекрасно размажет доступные N мбит на все 100501 поток. На выходе - тоска и печаль...

 

 

Вторую не решает ничто, все равно ведь канал расширять придется.

Имею относительно положительный опыт аварийной "упаковки" (при обрыве линии) 300-400 мбит трафика (онлайн более 600 тогда был, если память не подводит) в 100 мбит линк. Да, в один поток скорость была порядка 1 мбита, но это лучше чем было без шейпера вообще. А так оверкоммит на 20-30% шейпером смягчается вполне неплохо. Хотя да, это больше актуально для каналов в 200-300 мбит, при каналах в гиг и более уже шейперами не особо стоит заморачиваться... И оверкоммита огромного не будет внезапно (пики смягчаются с ростом абонбазы), и железо на шейпинг мощнее надо будет, и мбит канала дешевле стоит...

Share this post


Link to post
Share on other sites

Первую проблему банальная дисциплина sfq решает изумительно.

Если торрент сосет в 100500 потоков, а ютуб в 1 - sfq прекрасно размажет доступные N мбит на все 100501 поток. На выходе - тоска и печаль...

Угу, перепутал немного. У нас выдается несколько IP клиенту под одну учётку, вот между ними SFQ делит все честно.

Share this post


Link to post
Share on other sites

Join the conversation

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

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.