проблема шейпинга 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 мегабит... останавливаю трафик тестовый скорость опять поднимается до максимума.

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

Ссылка

←	[MySQL] Размер базы

exim4 не отправляет письма

→

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

wreckerov
(14.01.11 16:29:49 MSK) автор топика

Ответ на: комментарий от wreckerov 14.01.11 16:29:49 MSK

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

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

ventilator ★★★
(14.01.11 19:15:20 MSK)

Ответ на: комментарий от ventilator 14.01.11 19:15:20 MSK

От использования netfilter можно ведь и отказаться ?

Myp3ik ★★
(14.01.11 21:09:14 MSK)

Ответ на: комментарий от ventilator 14.01.11 19:15:20 MSK

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

Конкретно с тем скриптом что ниже... делаю даунлодинг дебиана... мозилла скорость показывает 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
(14.01.11 21:19:06 MSK) автор топика

Ответ на: комментарий от wreckerov 14.01.11 21:19:06 MSK

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

ventilator ★★★
(14.01.11 22:45:59 MSK)

Ссылка

Ответ на: комментарий от Myp3ik 14.01.11 21:09:14 MSK

да можно то можно ... но вопрос в том что метода работает при низких скоростях ...а мне надо хотябы 4 мегабита.

wreckerov
(14.01.11 22:50:54 MSK) автор топика

Ответ на: комментарий от wreckerov 14.01.11 22:50:54 MSK

Метода не работает. Сделайте один класс на 512 килобит и эффект для входящего трафика будет идентичен.

ventilator ★★★
(14.01.11 23:00:58 MSK)

Ответ на: комментарий от wreckerov 14.01.11 22:50:54 MSK

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

mky ★★★★★
(14.01.11 23:38:47 MSK)

Ответ на: комментарий от mky 14.01.11 23:38:47 MSK

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

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

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

wreckerov
(16.01.11 08:54:46 MSK) автор топика

Ответ на: комментарий от ventilator 14.01.11 23:00:58 MSK

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

# 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
(16.01.11 10:23:07 MSK) автор топика

Ответ на: комментарий от wreckerov 16.01.11 10:23:07 MSK

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

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

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

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

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

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

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

wreckerov
(16.01.11 10:43:32 MSK) автор топика

Ответ на: комментарий от wreckerov 16.01.11 10:43:32 MSK

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

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

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

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

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

ventilator ★★★
(16.01.11 15:33:37 MSK)

Ответ на: комментарий от wreckerov 16.01.11 08:54:46 MSK

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

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

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

mky ★★★★★
(16.01.11 20:37:57 MSK)

Ответ на: комментарий от mky 16.01.11 20:37:57 MSK

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

wreckerov
(17.01.11 10:01:33 MSK) автор топика

Ссылка

Ответ на: комментарий от ventilator 16.01.11 15:33:37 MSK

Не будет работать. Входящий трафик попадает на 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
(17.01.11 10:30:18 MSK) автор топика

Ответ на: комментарий от wreckerov 17.01.11 10:30:18 MSK

Может быть правильнее применить CBQ? или разницы нет?

wreckerov
(17.01.11 18:24:57 MSK) автор топика

Ответ на: комментарий от wreckerov 17.01.11 18:24:57 MSK

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

#!/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
(18.01.11 12:46:43 MSK) автор топика

Ответ на: комментарий от wreckerov 18.01.11 12:46:43 MSK

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

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

wreckerov
(18.01.11 13:04:45 MSK) автор топика

Ответ на: комментарий от wreckerov 18.01.11 13:04:45 MSK

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

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

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

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

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

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

wreckerov
(18.01.11 13:17:14 MSK) автор топика