Страница 1 из 1
Странности шейпера
Добавлено: Чт фев 05, 2009 4:56 pm
NiTr0
Заметил весьма странное поведение шейпера (проявляется нерегулярно): периодически у некоторых пользователей появляется либо удвоенная, либо вообще неограниченная скорость. Причем - периодичность случайная.
Вот в один из моментов сделал tc -d class show:
Код: Выделить всё
class htb 1:1 root rate 256000bit ceil 256000bit burst 512Kb cburst 1632b
Sent 364162938 bytes 451587 pkt (dropped 0, overlimits 0 requeues 0)
rate 459320bit 59pps backlog 0b 0p requeues 0
lended: 0 borrowed: 0 giants: 0
tokens: -59999999 ctokens: -59999999
class htb 1:10 parent 1:1 leaf 10: prio 1 rate 256000bit ceil 256000bit burst 512Kb cburst 1632b
Sent 68378042 bytes 50855 pkt (dropped 0, overlimits 0 requeues 0)
rate 203456bit 18pps backlog 0b 0p requeues 0
lended: 50855 borrowed: 0 giants: 0
tokens: 16340250 ctokens: 7250
class htb 1:20 parent 1:1 leaf 20: prio 2 rate 256000bit ceil 256000bit burst 512Kb cburst 1632b
Sent 296048886 bytes 400799 pkt (dropped 2589, overlimits 0 requeues 0)
rate 256336bit 41pps backlog 0b 67p requeues 0
lended: 400732 borrowed: 0 giants: 0
tokens: 16245600 ctokens: -87400
Итого, как видно, родительский класс отказывается резать скорость. Вопрос - почему?
Скрипт - практически оригинальный, вот кусок, отвечающий за установку шейпера:
Код: Выделить всё
UBURST="burst 512k"
..............
/sbin/tc qdisc add dev $1 root handle 1: htb default 20 r2q 100
/sbin/tc class add dev $1 parent 1: classid 1:1 htb rate ${UPSPEED}kbit $UBURST quantum 1514
/sbin/tc class add dev $1 parent 1:1 classid 1:10 htb rate ${UPSPEED}kbit $UBURST prio 1 quantum 1514
/sbin/tc class add dev $1 parent 1:1 classid 1:20 htb rate ${UPSPEED}kbit $UBURST prio 2 quantum 1514
/sbin/tc qdisc add dev $1 parent 1:10 handle 10: sfq perturb 10 quantum 1514
/sbin/tc qdisc add dev $1 parent 1:20 handle 20: sfq perturb 10 quantum 1514
/sbin/tc filter add dev $1 parent 1:0 protocol ip prio 10 u32 match ip tos 0x10 0xff flowid 1:10
/sbin/tc filter add dev $1 parent 1:0 protocol ip prio 10 u32 match ip protocol 1 0xff flowid 1:10
Ядро - 2.6.18 из репозитория центоса
Re: Странности шейпера
Добавлено: Пт фев 06, 2009 5:48 am
gurzufnet
NiTr0 писал(а):Заметил весьма странное поведение шейпера (проявляется нерегулярно): периодически у некоторых пользователей появляется либо удвоенная, либо вообще неограниченная скорость. Причем - периодичность случайная.
Именно поэтому заюзал фрю, очень доволен.
Re: Странности шейпера
Добавлено: Пт фев 06, 2009 7:34 am
ran
NiTr0 писал(а):Заметил весьма странное поведение шейпера (проявляется нерегулярно): периодически у некоторых пользователей появляется либо удвоенная, либо вообще неограниченная скорость. Причем - периодичность случайная.
либо разберись с параметрами burst/cburst
(очень внимательно) либо не трогай их ваще и оставь по дефолту... и буддет тебе щастье
под "очень внимательно" я подразумеваю чтение мейллистов LARTC на эту тему... в 90% случаев это ненужно думаю что и тебе тоже
кроме того ты устанавливаешь r2q и quantum... а раз устанавливаешь - значит хорошо понимаешь что это такое
и ваще... если хочешь это обсуждать - пиши в личку - поговрим на досуге

Re: Странности шейпера
Добавлено: Пт фев 06, 2009 8:26 am
ran
gurzufnet писал(а):Именно поэтому заюзал фрю, очень доволен.
юзай винду... там ваще мышой всё настраивается

Re: Странности шейпера
Добавлено: Пт фев 06, 2009 11:48 am
NiTr0
ran писал(а):либо разберись с параметрами burst/cburst
(очень внимательно) либо не трогай их ваще и оставь по дефолту... и буддет тебе щастье
под "очень внимательно" я подразумеваю чтение мейллистов LARTC на эту тему... в 90% случаев это ненужно думаю что и тебе тоже

burst - размер буффера токенов, сделал его 512кб для того, чтобы юзеры с пакетами типа 128кбит не испытывали дискомфорта при серфинге. cburst - не трогал.
Мэйллисты - покопаю...
ran писал(а):кроме того ты устанавливаешь r2q и quantum... а раз устанавливаешь - значит хорошо понимаешь что это такое

quantum - должен быть больше макс размера пакета (эзернет фрейм - 1500, пптп фрейм - 1436 вроде), но в то же время меньше 60000. Взял с запасом 1514. Если автоматом - то вычисляется из скорости и r2q, но не подходит из-за того, что на пакетах от 128к до 4м получается, что квантум не укладывается в рамки, результат - гадит в логи.
ran писал(а):и ваще... если хочешь это обсуждать - пиши в личку - поговрим на досуге

Думаю, это будет интересно не только мне

потому можно и тут продолжить.
Добавлено: Пт фев 06, 2009 1:30 pm
ran
Думаю, это будет интересно не только мне

потому можно и тут продолжить.
возможно... только вот форум не тот

Re: Странности шейпера
Добавлено: Сб фев 07, 2009 2:53 am
gurzufnet
ran писал(а):gurzufnet писал(а):Именно поэтому заюзал фрю, очень доволен.
юзай винду... там ваще мышой всё настраивается

Спасибо попробую

а то по старой памяти юзаю слакварь.
А если серьезно, то у мну просто было ограничено время.
А еще (шепотом) мне фря нравится

Добавлено: Сб фев 07, 2009 10:00 am
ran
2 NiTr0:
просмотрев конфиг твоего ядра я бы ИМХО порекомендовал следующее:
1. если архитектура позволяет поставить CONFIG_NET_SCH_CLK_CPU=y ну на худой крнец CONFIG_NET_SCH_CLK_JIFFIES=y так как CONFIG_NET_SCH_CLK_GETTIMEOFDAY=y это самый плохой вариант для шейпера (а у тебя стоит именно он)
GETTIMEOFDAY
Default setting is the most conservative PSCHED_GETTIMEOFDAY. It is very slow both because of weird slowness of do_gettimeofday() and because it forces code to use unnatural "timeval" format, where microseconds and seconds fields are separate. Besides that, it will misbehave, when delays exceed 2 seconds (f.e. very slow links or classes bounded to small slice of bandwidth) To resume: as only you will get it working, select correct clock source and forget about PSCHED_GETTIMEOFDAY forever.
JIFFIES
Clock is derived from jiffies. On architectures with HZ=100 granularity of this clock is not enough to make reasonable bindings to real time. However, taking into account Linux architecture problems, which force us to use artificial integrated clock in any case, this switch is not so bad for schduling even on high speed networks, though policing is not reliable.
CPU
It is available only for alpha and pentiums with correct CPU timestamp. It is the fastest way, use it when it is available, but remember: not all pentiums have this facility, and a lot of them have clock, broken by APM etc. etc.
2. CONFIG_PREEMPT=y
ваще-то для корректного шейпинга:
1. однопроцессорная архитектура гораздо лучше мультипроцессорной
2. средняя загрузка цпу не должна превышать 10%
ну а нсчёт burst/cburst... попробуй для начала поставить по дефолту, если поможет - кури мейллисты LARTC возможно в этом случае и cburst нада тоже устанавливать я навскидку не помню а искать некогда
насчёт
r2q/quantum да и ваще весь
этот фак почитать непомешает

Добавлено: Пн фев 09, 2009 6:16 pm
NiTr0
Хм... почитал хелп к опциям:
CONFIG_NET_SCH_CLK_GETTIMEOFDAY: Say Y here if you want to use gettimeofday as clock source. This clock source has high resolution, is synchronized on all processors and handles cpu clock frequency changes, but it is slow.
Choose this if you need a high resolution clock source but can't use the CPU's cycle counter.
CONFIG_NET_SCH_CLK_JIFFIES:
Say Y here if you want to use the timer interrupt (jiffies) as clock source. This clock source is fast, synchronized on all processors and handles cpu clock frequency changes, but its resolution is too low for accurate shaping except at very low speed.
Других источников - нет...
Добавлено: Вт фев 24, 2009 5:28 pm
NiTr0
Как подсказали на наге, rate всех подклассов не должен превышать rate родительского класса. А для указания макс. полосы для каждого подкласса - нужно пользовать ceil...
Добавлено: Пт фев 27, 2009 8:07 am
ran
Как подсказали на наге, rate всех подклассов не должен превышать rate родительского класса.
ну это в идеале на самом деле такое получается далеко не всегда (например когда заранее неизвестно количество подклассов на которые нужно разделить общую полосу)
А для указания макс. полосы для каждого подкласса - нужно пользовать ceil...
ну разумеется rate это тн CIR (Committed Information Rate) - гарантированная скорость, а ceil это MBR (Maximum Bit rate) максимально возможная