LINUX.ORG.RU
ФорумAdmin

проблема шейпинга HTB средствами TC (iproute2)


0

3

Всем привет!
Начну с системы - DEBIAN, но вопрос системонезависимый :) ядро - 2.6.32.

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

Суть, как я хотел решить. Измеряю текущую скорость, средств масса. Потом догружаю канал до максимума средствами IPERTF или чем то другим опять же на вкус и цвет много средств. Работает все по принципу клиент-сервер, тоже все подходит. Главное что тестовый трафик я могу генерировать или UDP или TCP на/с произвольный порт. По этим критериям я развешиваю метки и пытаюсь при помощи HTB

Приведу скрипт которым я щас пытаюсь играть:
#!/bin/sh
DEV=eth1
RATEUP=2048
RATEDN=4096
#RATEDN=512

## CLEAN CLASS, QDISK, FILTER (delete root point)
tc qdisc del dev $DEV root
tc qdisc del dev $DEV ingress
tc qdisc del dev ifb0 root
iptables -t mangle -F
# CLEAN OUT IPTABLES MANGLE
#iptables -t mangle -D POSTROUTING -o $DEV -j MYSHAPER-OUT
iptables -t mangle -F MYSHAPER-OUT 2>/dev/null
iptables -t mangle -X MYSHAPER-OUT 2>/dev/null
# CLEAN IN IPTABLES MANGLE
#iptables -t mangle -D PREROUTING -i ifb0 -j MYSHAPER-IN
iptables -t mangle -F MYSHAPER-IN 2>/dev/null
iptables -t mangle -X MYSHAPER-IN 2>/dev/null
#modprobe ifb # лучше добавить в /etc/modules
ip link set dev ifb0 up
## CLEAN END

### OUT RULES
# добавить корневую дисциплину HTB по умолчанию высокий приоритет
tc qdisc add dev $DEV parent root handle 1:0 htb default 20
# добавить общее ограничение скорости по классу
tc class add dev $DEV parent 1:0 classid 1:1 htb rate ${RATEUP}Kbit
# добавляем подклассы, PRIO 0 высший приоритет, по мере увеличения приоритет падает
tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[$RATEUP-1]kbit ceil ${RATEUP}kbit prio 0 # высокий приоритет
tc class add dev $DEV parent 1:1 classid 1:21 htb rate 1kbit ceil ${RATEUP}kbit prio 1 # низкий приоритет
# подключаем дисциплины обработки очереди к подклассам
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
tc qdisc add dev $DEV parent 1:21 handle 21: sfq perturb 10
# направляем трафик в классы по fwmark
tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 20 fw flowid 1:20
tc filter add dev $DEV parent 1:0 prio 1 protocol ip handle 21 fw flowid 1:21

### IN RULES
# добавляем дисциплину - низкоприоритетный класс по умолчанию 1:20
tc qdisc add dev ifb0 handle 1:0 root htb default 20
# добавляем общее ограничение скорости по классу
tc class add dev ifb0 parent 1:0 classid 1:1 htb rate ${RATEDN}kbit
# добавляем подклассы, PRIO 0 высший приоритет, по мере увеличения приоритет падает
tc class add dev ifb0 parent 1:1 classid 1:20 htb rate $[$RATEDN-1]kbit ceil ${RATEDN}kbit prio 0 # высокий приоритет
tc class add dev ifb0 parent 1:1 classid 1:21 htb rate 1kbit ceil ${RATEDN}kbit prio 1 # низкий приоритет
# подключаем дисциплины обработки очереди к подклассам
tc qdisc add dev ifb0 parent 1:20 handle 20: sfq perturb 10
tc qdisc add dev ifb0 parent 1:21 handle 21: sfq perturb 10
# направляем трафик в классы по fwmark
tc filter add dev ifb0 parent 1:0 prio 0 protocol ip handle 20 fw flowid 1:20
tc filter add dev ifb0 parent 1:0 prio 1 protocol ip u32 match ip src 111.222.333.444 flowid 1:21
# перенаправлять входящие пакеты с $DEV в ifb0
tc qdisc add dev $DEV handle ffff: ingress
tc filter add dev $DEV parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0

# Маркируем
### OUT RULES
iptables -t mangle -N MYSHAPER-OUT # Создать новую цепочку
iptables -t mangle -I POSTROUTING -o $DEV -j MYSHAPER-OUT # прикрепить к политике POSTROUTING
iptables -t mangle -A MYSHAPER-OUT -o $DEV -p tcp -d 111.222.333.444 -j MARK --set-mark 21 # ftp
iptables -t mangle -A MYSHAPER-OUT -o $DEV -m mark --mark 0 -j MARK --set-mark 20 # other

### IN RULES
iptables -t mangle -N MYSHAPER-IN
#iptables -t mangle -I PREROUTING -i ifb0 -j MYSHAPER-IN
iptables -t mangle -I PREROUTING -j MYSHAPER-IN
#iptables -t mangle -A MYSHAPER-IN -i ifb0 -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 --dport 5001 -j MARK --set-mark 20 # nuttcp
#iptables -t mangle -A MYSHAPER-IN -i ifb0 -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 --sport 5001 -j MARK --set-mark 20 # nuttcp

iptables -t mangle -A MYSHAPER-IN -i ifb0 -p tcp -s 111.222.333.444 -j MARK --set-mark 21 # ftp
iptables -t mangle -A MYSHAPER-IN -i $DEV -p tcp -s 111.222.333.444 -j MARK --set-mark 21 # ftp
iptables -t mangle -A MYSHAPER-IN -i ifb0 -m mark --mark 0 -j MARK --set-mark 20 # избыточно - маркировать немаркированные
iptables -t mangle -A MYSHAPER-IN -i $DEV -m mark --mark 0 -j MARK --set-mark 20 # избыточно - маркировать немаркированные

####################################################
echo «Outbound shaping added to $DEV. Rate: ${RATEUP}Kbit/sec.»
echo «Inbound shaping added to $DEV. Rate: ${RATEDN}Kbit/sec.»



Суть проблемы в том что при небольших полезных нагрузках измерения вроде как идут нормально! Но стоит загрузить канал хотябы процентов на 70-80... тестовый трафик наносит ущерб полезному.

Например, у меня дома сейчас DOWNSTREAM 4мегабита... скачиваю дистриб дебиана... запускаю измерение(догрузку канала до максимума) скорость скачивания падает до 1,5-2 мегабит... останавливаю трафик тестовый скорость опять поднимается до максимума.

Как правильнее развесить приоритеты? может быть методическая ошибка где то?

Кстати возможно важный факт ... Сейчас ставил общее ограничение канала 512кбит... все работало как нужно! Возможно дело не в проценте загрузки канала, а в каких то буферах и пр.....

wreckerov ()
Ответ на: комментарий от wreckerov

tc filter add dev ifb0 parent 1:0 prio 0 protocol ip handle 20 fw flowid 1:20

Не будет работать. Входящий трафик попадает на ifb раньше чем в netfilter, соответственно марков никаких там нету.

ventilator ★★★ ()
Ответ на: комментарий от ventilator

Удивительно, но работает... Может быть я не до конца нюансы вижу.

Конкретно с тем скриптом что ниже... делаю даунлодинг дебиана... мозилла скорость показывает 62кбайт/сек (близко к 512к) тут же пробую по FTP качать с хоста который в скрипте прописан как низкоприоритетный поток - скорость 1кбит.... примерно.. ставлю на паузу дебиан ... у FTP скорость повышается до 512кбит.

Т.е. необходимая логика ПОЛНОСТЬЮ работает при ограничении в 512 ... но при увеличении цифр перестает работать логика.


___________________________
#!/bin/sh
DEV=eth1
#RATEUP=2048
RATEUP=512
#RATEDN=4096
RATEDN=512

## CLEAN CLASS, QDISK, FILTER (delete root point)
tc qdisc del dev $DEV root
tc qdisc del dev $DEV ingress
tc qdisc del dev ifb0 root
iptables -t mangle -F
# CLEAN OUT IPTABLES MANGLE
iptables -t mangle -F MYSHAPER-OUT 2>/dev/null
iptables -t mangle -X MYSHAPER-OUT 2>/dev/null
# CLEAN IN IPTABLES MANGLE
iptables -t mangle -F MYSHAPER-IN 2>/dev/null
iptables -t mangle -X MYSHAPER-IN 2>/dev/null
#modprobe ifb # лучше добавить в /etc/modules
ip link set dev ifb0 up
## CLEAN END

### OUT RULES
# добавить корневую дисциплину HTB по умолчанию высокий приоритет
tc qdisc add dev $DEV parent root handle 1:0 htb default 20
# добавить общее ограничение скорости по классу
tc class add dev $DEV parent 1:0 classid 1:1 htb rate ${RATEUP}Kbit
# добавляем подклассы, PRIO 0 высший приоритет, по мере увеличения приоритет падает
tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[$RATEUP-1]kbit ceil ${RATEUP}kbit prio 0 # высокий приоритет
tc class add dev $DEV parent 1:1 classid 1:21 htb rate 1kbit ceil ${RATEUP}kbit prio 1 # низкий приоритет
# подключаем дисциплины обработки очереди к подклассам
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
tc qdisc add dev $DEV parent 1:21 handle 21: sfq perturb 10
# направляем трафик в классы по fwmark
tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 20 fw flowid 1:20
tc filter add dev $DEV parent 1:0 prio 1 protocol ip handle 21 fw flowid 1:21

### IN RULES
# добавляем дисциплину - низкоприоритетный класс по умолчанию 1:21
tc qdisc add dev ifb0 handle 1:0 root htb default 20
# добавляем общее ограничение скорости по классу
tc class add dev ifb0 parent 1:0 classid 1:1 htb rate ${RATEDN}kbit
# добавляем подклассы, PRIO 0 высший приоритет, по мере увеличения приоритет падает
tc class add dev ifb0 parent 1:1 classid 1:20 htb rate $[$RATEDN-1]kbit ceil ${RATEDN}kbit prio 0 # высокий приоритет
tc class add dev ifb0 parent 1:1 classid 1:21 htb rate 1kbit ceil ${RATEDN}kbit prio 1 # низкий приоритет
# подключаем дисциплины обработки очереди к подклассам
tc qdisc add dev ifb0 parent 1:20 handle 20: sfq perturb 10
tc qdisc add dev ifb0 parent 1:21 handle 21: sfq perturb 10
# направляем трафик в классы по fwmark
tc filter add dev ifb0 parent 1:0 prio 0 protocol ip handle 20 fw flowid 1:20
tc filter add dev ifb0 parent 1:0 prio 1 protocol ip handle 21 fw flowid 1:21
# перенаправлять входящие пакеты с $DEV в ifb0
tc qdisc add dev $DEV handle ffff: ingress
tc filter add dev $DEV parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0

# Маркируем
### OUT RULES
iptables -t mangle -N MYSHAPER-OUT # Создать новую цепочку
iptables -t mangle -I POSTROUTING -o $DEV -j MYSHAPER-OUT # прикрепить к политике POSTROUTING
#iptables -t mangle -A MYSHAPER-OUT -o $DEV -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 --dport 20 -j MARK --set-mark 20
#iptables -t mangle -A MYSHAPER-OUT -o $DEV -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 --dport 21 -j MARK --set-mark 20 # ftp
iptables -t mangle -A MYSHAPER-OUT -o $DEV -p tcp -d 194.67.66.166 -j MARK --set-mark 21 # ftp
iptables -t mangle -A MYSHAPER-OUT -o $DEV -m mark --mark 0 -j MARK --set-mark 20 # other

### IN RULES
iptables -t mangle -N MYSHAPER-IN
#iptables -t mangle -I PREROUTING -i ifb0 -j MYSHAPER-IN
iptables -t mangle -I PREROUTING -j MYSHAPER-IN
#iptables -t mangle -A MYSHAPER-IN -i ifb0 -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 --dport 5001 -j MARK --set-mark 20 # nuttcp
#iptables -t mangle -A MYSHAPER-IN -i ifb0 -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 --sport 5001 -j MARK --set-mark 20 # nuttcp

iptables -t mangle -A MYSHAPER-IN -i ifb0 -p tcp -s 194.67.66.166 -j MARK --set-mark 21 # ftp
iptables -t mangle -A MYSHAPER-IN -i $DEV -p tcp -s 194.67.66.166 -j MARK --set-mark 21 # ftp
iptables -t mangle -A MYSHAPER-IN -i ifb0 -m mark --mark 0 -j MARK --set-mark 20 # избыточно - маркировать немаркированные
iptables -t mangle -A MYSHAPER-IN -i $DEV -m mark --mark 0 -j MARK --set-mark 20 # избыточно - маркировать немаркированные


####################################################
echo «Outbound shaping added to $DEV. Rate: ${RATEUP}Kbit/sec.»
echo «Inbound shaping added to $DEV. Rate: ${RATEDN}Kbit/sec.»
___________________________

wreckerov ()
Ответ на: комментарий от wreckerov

А вы попробуйте сначала фтп запустить, а потом мозиллу. И еще глянуть статистику по классам на ifb устройстве. У вас попадает в дефолт класс(20) все как мне кажется. Не исключено конечно что у вас особый, уличный нетфильтр, в который пакеты попадают до ingress очереди сетевого интерфейса.

ventilator ★★★ ()
Ответ на: комментарий от wreckerov

Вы всё таки, как вам советуют, посмотрите статистику по классам, что куда попадает. И потом я не понял, а провайдер у вас скорость совсем не ограничивает? Просто, если вы пытаетесь загрузить канал практически до ограничителя у провайдера, то всё это особо бесполезно, там, у провайдера, всё равно одна очередь.

mky ★★★★★ ()
Ответ на: комментарий от mky

Я конечно посмотрю что куда попадает. Но про одну очередь у провайдера вы пардон бред пишете. Потому что не внимательно прочитали мою цель! Она в том чтобы ПРОВЕРИТЬ как раз то самое ограничение у провайдера, не снимая полезной нагрузки.

Например через канал идет видео конференция посредством программы SJPhone, рядом идут 5 разговоров по SIP.... и все это загружает канал например на 1 мегабит, канал заявлен 2 мегабита, но реально может быть доступен на 1,5. Вот моя задача не снимая трафик измерить доступную скорость канала. По моей методе я делаю низкий приоритет на измерительный трафик и пытаюсь догрузить канал. Тест должен показать 0,5 мегабит, просуммировав с реальной нагрузкой я получу максимально доступный канал.

Повторю цель - есть полезный трафик и есть трафик которым я хочу «до отсечки» у провайдера загрузить канал. Вот этот «догрузочный трафик» не должен сдвигать ВООБЩЕ полезный трафик.

wreckerov ()
Ответ на: комментарий от ventilator

Удивительная штука для меня, но кажется Вы правы!

# tc -s -p qdisc show dev eth1
qdisc htb 1: root refcnt 2 r2q 10 default 20 direct_packets_stat 0
Sent 468606 bytes 6151 pkt (dropped 0, overlimits 89 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 20: parent 1:20 limit 127p quantum 1514b perturb 10sec
Sent 459467 bytes 5981 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 21: parent 1:21 limit 127p quantum 1514b perturb 10sec
Sent 9139 bytes 158 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
qdisc ingress ffff: parent ffff:fff1 ----------------
Sent 8148858 bytes 7920 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0

# tc -s class show dev eth1
class htb 1:1 root rate 512000bit ceil 512000bit burst 1600b cburst 1600b
Sent 1832512 bytes 19616 pkt (dropped 0, overlimits 0 requeues 0)
rate 34720bit 40pps backlog 0b 0p requeues 0
lended: 142 borrowed: 0 giants: 0
tokens: 373047 ctokens: 373047

class htb 1:20 parent 1:1 leaf 20: prio 0 rate 511000bit ceil 512000bit burst 1599b cburst 1600b
Sent 1809569 bytes 19229 pkt (dropped 0, overlimits 0 requeues 0)
rate 34720bit 40pps backlog 0b 0p requeues 0
lended: 19118 borrowed: 66 giants: 0
tokens: 373766 ctokens: 373047

class htb 1:21 parent 1:1 leaf 21: prio 1 rate 1000bit ceil 512000bit burst 1600b cburst 1600b
Sent 22943 bytes 387 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
lended: 311 borrowed: 76 giants: 0
tokens: 154406662 ctokens: 360167


__________________________________________________________________________

# tc -s -p qdisc show dev ifb0
qdisc htb 1: root refcnt 2 r2q 10 default 20 direct_packets_stat 0
Sent 10328346 bytes 9986 pkt (dropped 23, overlimits 18331 requeues 0)
rate 0bit 0pps backlog 0b 84p requeues 0
qdisc sfq 20: parent 1:20 limit 127p quantum 1514b perturb 10sec
Sent 10328346 bytes 9986 pkt (dropped 23, overlimits 0 requeues 0)
rate 0bit 0pps backlog 103960b 84p requeues 0
qdisc sfq 21: parent 1:21 limit 127p quantum 1514b perturb 10sec
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0



# tc -s class show dev ifb0
class htb 1:1 root rate 512000bit ceil 512000bit burst 1600b cburst 1600b
Sent 23291053 bytes 22596 pkt (dropped 0, overlimits 0 requeues 0)
rate 443088bit 54pps backlog 0b 0p requeues 0
lended: 199 borrowed: 0 giants: 0
tokens: -371060 ctokens: -371060

class htb 1:20 parent 1:1 leaf 20: prio 0 rate 511000bit ceil 512000bit burst 1599b cburst 1600b
Sent 23319049 bytes 22612 pkt (dropped 395, overlimits 0 requeues 0)
rate 433728bit 54pps backlog 0b 16p requeues 0
lended: 22397 borrowed: 199 giants: 0
tokens: -241764 ctokens: -371060

class htb 1:21 parent 1:1 leaf 21: prio 1 rate 1000bit ceil 512000bit burst 1600b cburst 1600b
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: 200000000 ctokens: 390625

_____________________________________________________________________


Т.е. в 21-ый класс во входящем направлении ничего не попадает.


Решения уже достаточно срочно нужно :( Может быть кто то может помочь написать верный скрипт? , а я отблагодарю презентом на мобилу :) например...

wreckerov ()
Ответ на: комментарий от wreckerov

Я Ващу мысль услышал - что у меня серьезный косяк во ВХОДЯЩЕМ направлении... хотя не понятно почему общее ограничение входящее работает, а раздельное нет...

Но больше не понятно почему в ИСХОДЯЩЕМ направлении не работает тоже, хотя по счетчикам TC видно что трафик делится и попадает в разные классы. Сечас пробовал аплодить сразу на два хоста, один низкоприоритетный. Пробовал в двух случаях:
1. RATEUP=2048
2. RATEUP=512

В первом случае низкоприоритетный АПЛОД был скоростью 80кБайт в сек, а высокоприоритетный 140кБайт в сек. Сумма: 220 * 8 = 1760кбит/сек. вполне возможно, есть же заголовки TCP,FTP и пр ...

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

Вопрос - это работает как надо или нет?

Сразу поясню - вопрос возник потому что если баловаться не двумя аплодами через FTP, а сделать высокоприоритетный FTP, «низкоприоритетный» запустить iperf то скорость высокоприоритетного падает на половину где то.... на период запуска iperf. Т.е. ущерб полезному трафику есть! :(

Провайдер дает честный Ethernet из свитча Zyxel, без модемов всяких.

wreckerov ()
Ответ на: комментарий от wreckerov

Не стоит вообще удивляться если кто то оказался прав ;-)

Я Ващу мысль услышал - что у меня серьезный косяк во ВХОДЯЩЕМ направлении... хотя не понятно почему общее ограничение входящее работает, а раздельное нет...


Общее ограничение - рут класс интерфейса ifb0 ясное дело что он работает. В класс 20 трафик попадает потому что это дефолтный класс.
А почему фильтры не работают на ifb я уже писал.

Вопрос - это работает как надо или нет?

Вы посмотрите статистику по классам.

ventilator ★★★ ()
Ответ на: комментарий от wreckerov

>Она в том чтобы ПРОВЕРИТЬ как раз то самое ограничение у провайдера, не снимая полезной нагрузки.

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

И второе, входящий трафик ограничивается путём складывания пакетов в промежуточную очередь и это работает для таких протоколов, как tcp, где сервер ждёт подтверждений от клиента и задержка пакетов притормаживает их отправку. Если же говорить про udp и iperf, то он просто генерит пакеты с заданной полосой. Если от удалённой машины на ваш сервер идёт upd поток 1 Мбит, то этот поток и будет 1 Мбит и с помощью ifb вы не сделаете из него 0,5 Мбит. Точнее сделаете, но только на выходе из ifb, а физический канал будет загружен на 1 Мбит.

mky ★★★★★ ()
Ответ на: комментарий от mky

mky! Я может быть что-то не так говорю... но мне тоже глубоко наплевать на провайдера. Мне нужно выяснять РАЗ в пять минут, дает мне провайдер заявленную скорость или нет - с ним SLA подписан! И я сейчас в такой ситуации что могу его заставить согласиться с моей методикой измерения. Если я по утвержденной методике его уличу в том что он отклонился от SLA - на него штраф.

wreckerov ()
Ответ на: комментарий от ventilator

Не будет работать. Входящий трафик попадает на ifb раньше чем в netfilter, соответственно марков никаких там нету.


Это я понял. Но задача то по факту распадается на две. Ограничить вход и ограничить выход. Вход не работает потому что с ingress вообще отдельная песня. Я решил дабы разобраться в теме решил оставить эту сложность пока в стороне. Решил заняться исходящим трафиком.

Судя по счетчикам все попадает куда надо. Смотрел так:
# tc -s class show dev eth1
.... до того как начал общатьься с низкоприоритетным хостом много раз смотрел на счетчик все по нулям.

class htb 1:21 parent 1:1 leaf 21: prio 1 rate 1000bit ceil 2048Kbit burst 1600b cburst 1599b
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: 200000000 ctokens: 97656


После того как начал аплодить на низкоприоритетный хост файл по FTP счетчики зашевелились:

class htb 1:21 parent 1:1 leaf 21: prio 1 rate 1000bit ceil 2048Kbit burst 1600b cburst 1599b
Sent 17806295 bytes 28694 pkt (dropped 0, overlimits 0 requeues 0)
rate 1956Kbit 395pps backlog 0b 2p requeues 0
lended: 171 borrowed: 28521 giants: 0
tokens: -37980326 ctokens: 31521

Ниже начала появляться такая запись, пока не понял что это и зачем:

class sfq 21:113 parent 21:
(dropped 0, overlimits 0 requeues 0)
backlog 0b 2p requeues 0
allot 374



Т.е. все попадает куда надо, рэйт проставляется 1956Kbit. Правда он в это значение установился только к концу минутной закачки. Значение менялось ступенями примерно кажые 5 сек.
rate 501248bit 93pps
rate 874008bit 162pps
rate 1153Kbit 216pps
rate 1360Kbit 258pps
rate 1514Kbit 287pps
rate 1631Kbit 313pps

Хотя скорость скачивания по данным FAR сразу была 2 мегабита почти.

Может быть в этом проблема? Просто догрузка канала у меня тоже кратковременная, продолжительность пробовал максимум 10 сек пока. Может какие нить уже заполненные буферы не успевают перераспределиться? Тогда их 100% можно подкрутить. Главное обнаружить их.

Может быть еще какие нить методы диагностики подскажете?

wreckerov ()
Ответ на: комментарий от wreckerov

Спрошу сильно проще:

#!/bin/sh
DEV=eth1
RATEUP=2048
#RATEUP=1024
RATETEST=64

tc qdisc del dev $DEV root
tc qdisc add dev $DEV handle 1:0 root htb default 20
tc class add dev $DEV parent 1:0 classid 1:1 htb rate ${RATEUP}Kbit
tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[$RATEUP-$RATETEST]kbit ceil ${RATEUP}kbit prio 0 # высокий приоритет
tc class add dev $DEV parent 1:1 classid 1:21 htb rate ${RATETEST}kbit ceil ${RATEUP}kbit prio 1 # низкий приоритет

tc filter add dev $DEV parent 1:0 prio 11 protocol ip u32 match ip dst 194.67.66.166/32 flowid 1:21
tc filter add dev $DEV parent 1:0 prio 12 protocol ip u32 match ip dst 0.0.0.0/0 flowid 1:20


Вот такой СУПЕР простой скрипт оставил для тестов. При RATEUP=1024 все работает как надо... при увеличении RATEUP до 2048... начинается перекос. Высокому приоритету отдается около 70% скорости... а низкоприоритетный занимает 30% вместо положенных 64к. Стоит остановить низкоприоритетный трафик, высокий приоритет занимает 100%.

Как побороть? где просчет?

wreckerov ()
Ответ на: комментарий от wreckerov

Эксперименты дальше показали что даже если поставить RATEUP=1950 То тоже все работает как надо!

Что это может означать?

wreckerov ()
Ответ на: комментарий от wreckerov

если поставить RATEUP=2000 тоже все работает как надо, но но почти :) Скорость низкоприорететной очереди подскакивает до 128к периодически.

Судя по всему низкоприоритетная очередь пользуется своим правом заимствования в высокоприоритетной очереди (при наличии полосы).

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

Вопрос ПОЧЕМУ? и как этого избежать?

Просто сама цель то в том чтобы проверить максимально доступную полосу а не в выставлении костылей.

Ведь если я оставлю все как описал выше .... в штатной ситуации будет все как надо, но стоит провайдеру взять и уменьшить полосу пропускания, то мой измерительный трафик начнет аффектить полезный трафик. А это противоречит постановке задачи.

wreckerov ()
Ответ на: комментарий от wreckerov

Вынужден признать что MKY был тоже прав.

Получается что для моей задачи нужен другой критерий.

Если в высокоприоритетной очереди есть хоть один пакет, то из низкоприоритетной ни один пакет не уйдет.

Какими средствами это можно сделать?

wreckerov ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.