форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Открытые системы на сервере (Квоты, ограничения, QoS / Linux)
Изначальное сообщение		[ Отслеживать ]

"Проблема с шейпером (htb)"	+/–
Сообщение от vvk1987 (ok) on 14-Апр-11, 14:34
Здравствуйте, Возникла проблема с шейпером, а именно с htb. Расширили канал, увеличили абонентскую скорость до нескольких мегабит. И начали происходить непонятные вещи. Существует абонентский web трафик, который направляется в отдельный класс (например 1002 см. ниже) каждого абонента. С учетом полосы пропускания RATE для некоторых абонентов равен 80 Кбит/с (гарантированная скорость), а CEIL выставлена 2,5 Мбит/с. И происходит такая ситуация: в течение первых 15 секунд (примерно) когда человек начинает что-то грузить (например, ролик с youtube) она держится, а потом падает до 1 Мбита. Какие-либо файлы также качаются на скорости 1 Мбит/с. И потом, что интересно эта скорость прям держится в районе 1 Мбит/с и не растет и не падает. При этом канал вообще свободный и родительский класс тоже свободен. Тесты скорости иногда выдают 2,3 Мбит/с. Но вот просто не понятно где может быть косяк, что скорость падает при свободном то канале. Что интересно, раньше при 500 Кбит/с или даже при 1500 Кбит/с эта скорость достигалась и держалась. А вот с 2,5 Мбит/с – падает до 1 Мбит. Также удивляет, что скорость постоянно скачет около значения 1000 Мбит/с. Т.е как бы волнами идет, то падает до 700 Кбит/с то возрастает до 1300 Кбит/с. Т.е колеблется около 1000 Кбит/с. Весь web трафик идет через сквид. Раньше в нем стояли ограничения на скорость скачки на некоторые файлы как 512 Кбит/с, но после расширения, вообще мы конфиг сквида поправили и убрали вообще какие-либо ограничения. Вот дерево классов (пример для 3 абонентов, для внутреннего интерфейса, у 1:100 как пример канал равен 10 Мбит/с): http://img856.imageshack.us/img856/2569/classp.png Ssh – это служебный трафик. Bit - это класс пирингово трафика (торрент) Ring – региональное кольцо Local – внутри локальной сети Т.е скажем для абона 192.168.0.2 скорость 2500 держится секунд 15 потом стабильно падает до 1 Мбит, при свободном канале. Вот пример создания класса: /sbin/tc class add dev eth0 parent 1:100 classid 1:1002 htb rate 80Kbit ceil 2500Kbit /sbin/tc qdisc add dev eth0 parent 1:1002 handle 1002 sfq perturb 10 /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 192.168.0.2 classid 1:1002 Подскажите, пожалуйста, в какую сторону копать, и из за чего это может быть. Какие параметры htb на это могут влиять?
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Проблема с шейпером (htb)"	+/–
Сообщение от LSTemp (ok) on 14-Апр-11, 15:03
>[оверквотинг удален] > Возникла проблема с шейпером, а именно с htb. Расширили канал, увеличили абонентскую > скорость до нескольких мегабит. И начали происходить непонятные вещи. > Существует абонентский web трафик, который направляется в отдельный класс (например 1002 > см. ниже) каждого абонента. С учетом полосы пропускания RATE для некоторых > абонентов равен 80 Кбит/с (гарантированная скорость), а CEIL выставлена 2,5 Мбит/с. > И происходит такая ситуация: в течение первых 15 секунд (примерно) когда человек > начинает что-то грузить (например, ролик с youtube) она держится, а потом > падает до 1 Мбита. Какие-либо файлы также качаются на скорости 1 > Мбит/с. И потом, что интересно эта скорость прям держится в районе > 1 Мбит/с и не растет и не падает. При этом канал а как Вы считаете, труба скорость отдачи не ограничивает? стандарт - первые Х байт бесплатно... > вообще свободный и родительский класс тоже свободен. Тесты скорости иногда выдают > 2,3 Мбит/с. Но вот просто не понятно где может быть косяк, > что скорость падает при свободном то канале. - попробуйте заливать с хоста, который полную загрузку канала обеспечит, без ограничения скорости отдачи (от друзей например из другой wan, или speedtest.net в крайнем случае используйте) - любая заявленная скорость подключения от провайдера гарантируется только на его порту. дальше Ваш трафик идет лесом по любому - провайдер над ним не властен - кто, как и зачем за его оборудованием Вам может понизить скорость его не касается. - из вышесказанного и стройте свои тесты на скорость канала > Что интересно, раньше при 500 Кбит/с или даже при 1500 Кбит/с эта > скорость достигалась и держалась. А вот с 2,5 Мбит/с – падает > до 1 Мбит. а на root-классе что? >[оверквотинг удален] > Т.е скажем для абона 192.168.0.2 скорость 2500 держится секунд 15 потом стабильно > падает до 1 Мбит, при свободном канале. > Вот пример создания класса: > /sbin/tc class add dev eth0 parent 1:100 classid 1:1002 htb rate 80Kbit > ceil 2500Kbit > /sbin/tc qdisc add dev eth0 parent 1:1002 handle 1002 sfq perturb 10 > /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 > match ip dst 192.168.0.2 classid 1:1002 > Подскажите, пожалуйста, в какую сторону копать, и из за чего это может > быть. Какие параметры htb на это могут влиять? что за галиматья картинка? там даже не видно дисциплин обслуживания очереди. классы - классами, а обед по расписанию. давай uname -a tc -s qdisc show dev <DEV> tc -s class show dev <DEV> tc -s filter show dev <DEV> сколько интервейсов в системе на которой поднят шейпер и какой куда смотрит? и если есть правила по маркировке пакетов в сетевом фильтре для шейпера, то соотвествующие правила тоже в студию. PS я тут редко появляюсь, но после предоставления затребованной информации тебе наверняка ответят.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Проблема с шейпером (htb)"	+/–
	Сообщение от vvk1987 (ok) on 14-Апр-11, 15:41
	.............. > uname -a > tc -s qdisc show dev <DEV> > tc -s class show dev <DEV> > tc -s filter show dev <DEV> > сколько интервейсов в системе на которой поднят шейпер и какой куда смотрит? > и если есть правила по маркировке пакетов в сетевом фильтре для шейпера, > то соотвествующие правила тоже в студию. > PS > я тут редко появляюсь, но после предоставления затребованной информации тебе наверняка > ответят. Прям по пунктам отвечу. 1) Провайдер точно ничего не ограничивает, просто дает канал. 2) Падение идет на всех хостах что мы тестили. Т.е например на другом интернете, тот же файл с такого же хоста скачивается с более быстрой скоростью. Т.е не в хостингах дело. 3) uname -a Linux serv 2.6.31-20-generic-pae #57-Ubuntu SMP Mon Feb 1 11:24:59 UTC 2010 i686 GNU/Linux 4) tc -s qdisc show dev <DEV> Их много, приведу только часть абонентских: qdisc htb 1: root r2q 5 default 400 direct_packets_stat 1087 ver 3.17 Sent 44192789123 bytes 44377507 pkt (dropped 513526, overlimits 90365491 requeues 15) rate 0bit 0pps backlog 0b 107p requeues 15 qdisc sfq 10: parent 1:10 limit 127p quantum 1514b flows 127/1024 perturb 10sec Sent 3445669001 bytes 2892514 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 11: parent 1:11 limit 127p quantum 1514b flows 127/1024 perturb 10sec Sent 326710 bytes 2082 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 1002: parent 1:1002 limit 127p quantum 1514b flows 127/1024 perturb 10sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 1003: parent 1:1003 limit 127p quantum 1514b flows 127/1024 perturb 10sec Sent 76343078 bytes 325969 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 1004: parent 1:1004 limit 127p quantum 1514b flows 127/1024 perturb 10sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 1005: parent 1:1005 limit 127p quantum 1514b flows 127/1024 perturb 10sec Sent 54176074 bytes 42991 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 ..... qdisc sfq 200: parent 1:200 limit 127p quantum 1514b flows 127/1024 perturb 10sec Sent 21152663 bytes 243188 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 300: parent 1:300 limit 127p quantum 1514b flows 127/1024 perturb 10sec Sent 26550299260 bytes 25332233 pkt (dropped 499103, overlimits 0 requeues 0) rate 0bit 0pps backlog 87Kb 64p requeues 0 qdisc sfq 400: parent 1:400 limit 127p quantum 1514b flows 127/1024 perturb 10sec Sent 15884603 bytes 266320 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 5) tc -s -d class show dev eth0 class htb 1:3 root rate 100000Kbit ceil 100000Kbit burst 1600b/8 mpu 0b overhead 0b cburst 1600b/ 8 mpu 0b overhead 0b level 7 Sent 44386377606 bytes 44589271 pkt (dropped 0, overlimits 0 requeues 0) rate 10236Kbit 1458pps backlog 0b 0p requeues 0 lended: 12 borrowed: 0 giants: 0 tokens: 110 ctokens: 110 class htb 1:11 parent 1:3 leaf 11: prio 0 quantum 200000 rate 10000Kbit ceil 85000Kbit burst 1600 b/8 mpu 0b overhead 0b cburst 1583b/8 mpu 0b overhead 0b level 0 Sent 331723 bytes 2104 pkt (dropped 0, overlimits 0 requeues 0) rate 544bit 0pps backlog 0b 0p requeues 0 lended: 2092 borrowed: 12 giants: 0 tokens: 19313 ctokens: 2265 class htb 1:10 parent 1:3 leaf 10: prio 0 quantum 100000 rate 4000Kbit ceil 4000Kbit burst 1600b/ 8 mpu 0b overhead 0b cburst 1600b/8 mpu 0b overhead 0b level 0 Sent 3450063036 bytes 2899658 pkt (dropped 0, overlimits 0 requeues 0) rate 270400bit 54pps backlog 0b 0p requeues 0 lended: 2899658 borrowed: 0 giants: 0 tokens: 47750 ctokens: 47750 class htb 1:20 parent 1:3 rate 20500Kbit ceil 20500Kbit burst 1599b/8 mpu 0b overhead 0b cburst 1 599b/8 mpu 0b overhead 0b level 6 Sent 40935984525 bytes 41687513 pkt (dropped 0, overlimits 0 requeues 0) rate 9965Kbit 1404pps backlog 0b 0p requeues 0 lended: 22444497 borrowed: 0 giants: 0 tokens: 735 ctokens: 735 class htb 1:100 parent 1:20 rate 19840Kbit ceil 20500Kbit burst 1597b/8 mpu 0b overhead 0b cburst 1599b/8 mpu 0b overhead 0b level 5 Sent 14247291978 bytes 15740908 pkt (dropped 0, overlimits 0 requeues 0) rate 5592Kbit 718pps backlog 0b 0p requeues 0 lended: 11517856 borrowed: 48659 giants: 0 tokens: 516 ctokens: 485 class htb 1:300 parent 1:20 leaf 300: prio 2 quantum 12500 rate 500000bit ceil 5000Kbit burst 160 0b/8 mpu 0b overhead 0b cburst 1600b/8 mpu 0b overhead 0b level 0 Sent 26636312052 bytes 25435055 pkt (dropped 499158, overlimits 0 requeues 0) rate 4377Kbit 672pps backlog 0b 52p requeues 0 lended: 3040536 borrowed: 22394467 giants: 0 tokens: 9079 ctokens: -1757 class htb 1:200 parent 1:20 leaf 200: prio 0 quantum 2000 rate 80000bit ceil 128000bit burst 1600 b/8 mpu 0b overhead 0b cburst 1600b/8 mpu 0b overhead 0b level 0 Sent 21240899 bytes 244226 pkt (dropped 0, overlimits 0 requeues 0) rate 5536bit 8pps backlog 0b 0p requeues 0 lended: 244226 borrowed: 0 giants: 0 tokens: 2337500 ctokens: 1460938 class htb 1:400 parent 1:20 leaf 400: prio 3 quantum 2000 rate 80000bit ceil 512000bit burst 1600 b/8 mpu 0b overhead 0b cburst 1600b/8 mpu 0b overhead 0b level 0 Sent 15947350 bytes 267373 pkt (dropped 0, overlimits 0 requeues 0) rate 3488bit 7pps backlog 0b 0p requeues 0 lended: 266004 borrowed: 1369 giants: 0 tokens: 1601396 ctokens: 251540 class htb 1:1002 parent 1:100 leaf 1002: prio 0 quantum 1000 rate 40000bit ceil 512000bit burst 1 600b/8 mpu 0b overhead 0b cburst 1600b/8 mpu 0b overhead 0b level 0 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: 5000000 ctokens: 390625 class htb 1:1003 parent 1:100 leaf 1003: prio 0 quantum 2000 rate 80000bit ceil 2500Kbit burst 16 00b/8 mpu 0b overhead 0b cburst 1600b/8 mpu 0b overhead 0b level 0 Sent 76343078 bytes 325969 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 lended: 292637 borrowed: 33332 giants: 0 tokens: 2362500 ctokens: 75610 и т.д 6) tc -s -d filter show dev eth0 filter parent 1: protocol ip pref 90 fw filter parent 1: protocol ip pref 90 fw handle 0x5 classid 1:200 filter parent 1: protocol ip pref 90 fw handle 0x7 classid 1:10 filter parent 1: protocol ip pref 90 fw handle 0x69 classid 1:300 filter parent 1: protocol ip pref 100 u32 filter parent 1: protocol ip pref 100 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 100 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:11   match с0a90000/ffffff00 at 12   match с0a90000/ffffff00 at 16 filter parent 1: protocol ip pref 100 u32 fh 800::801 order 2049 key ht 800 bkt 0 flowid 1:1002   match с0a90002/ffffffff at 16 filter parent 1: protocol ip pref 100 u32 fh 800::802 order 2050 key ht 800 bkt 0 flowid 1:1003   match с0a90003/ffffffff at 16 filter parent 1: protocol ip pref 100 u32 fh 800::803 order 2051 key ht 800 bkt 0 flowid 1:1004   match с0a90004/ffffffff at 16 и т.д 7) На системе 2 интерфейса один смотрит наружу в интернет, другой eth0 - во внутреннюю сеть Сейчас посмотрел статистику для root qdisc. Это вообще нормально, что такое большое количество dropped и overlimits? qdisc htb 1: root r2q 5 default 400 direct_packets_stat 1087 ver 3.17 Sent 42737451559 bytes 42739969 pkt (dropped 512899, overlimits 86837479 requeues 15) rate 0bit 0pps backlog 0b 151p requeues 15
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	3. "Проблема с шейпером (htb)"	+/–
	Сообщение от LSTemp (ok) on 14-Апр-11, 19:29
	>[оверквотинг удален] >> tc -s class show dev <DEV> >> tc -s filter show dev <DEV> >> сколько интервейсов в системе на которой поднят шейпер и какой куда смотрит? >> и если есть правила по маркировке пакетов в сетевом фильтре для шейпера, >> то соотвествующие правила тоже в студию. >> PS >> я тут редко появляюсь, но после предоставления затребованной информации тебе наверняка >> ответят. > Прям по пунктам отвечу. > 1) Провайдер точно ничего не ограничивает, просто дает канал. конечно не ограничивает. ему смысла нет. сказал будет у тебя 100Mbit - значит будет, но только до него, а вот вышестоящий провайдер, у которого твой провайдер инет берет чхать на это хотел и зарежет твою скорость на своем роутере например до 10Mbit, а следующий - до 5, а следующий -..., а сайт с которого ты пытаешься качать собран на дохлом оборудовании, которое не более 100 клиентов одновременно поддерживает. и тебе не повезло - ты 101-й. вот так работает интернет.   > 2) Падение идет на всех хостах что мы тестили. Т.е например на > другом интернете, тот же файл с такого же хоста скачивается с > более быстрой скоростью. Т.е не в хостингах дело. сделай traceroute на "своем" и "другом интернете"  - почувствуй разницу. > 3) uname -a > Linux serv 2.6.31-20-generic-pae #57-Ubuntu SMP Mon Feb 1 11:24:59 UTC 2010 i686 > GNU/Linux Linux - мое ) > 4) tc -s qdisc show dev <DEV> > Их много, приведу только часть абонентских: плохо, что много и плохо, что не все. посмотрим... по приведенным ниже данным полную схему построить невозможно - отсутствуют ключевые узлы... >[оверквотинг удален] > key ht 800 bkt 0 flowid 1:1004 >   match с0a90004/ffffffff at 16 > и т.д > 7) На системе 2 интерфейса один смотрит наружу в интернет, другой eth0 > - во внутреннюю сеть > Сейчас посмотрел статистику для root qdisc. Это вообще нормально, что такое большое > количество dropped и overlimits? > qdisc htb 1: root r2q 5 default 400 direct_packets_stat 1087 ver 3.17 > Sent 42737451559 bytes 42739969 pkt (dropped 512899, overlimits 86837479 requeues 15) > rate 0bit 0pps backlog 0b 151p requeues 15 вопросы: class htb 1:20 parent 1:3 rate 20500Kbit ceil 20500Kbit class htb 1:300 parent 1:20 leaf 300: prio 2 quantum 12500 rate 500000bit ceil 5000Kbit - ты туда ли класс 1:300 прикрутил, судя по логике твоей нумерации? | - rate дочернего класса, больше чем у родительского. ноль не лишний в rate дочернего класса? оно работать будет, но на родительские ограничения ему станет покласть - отсуда может расти незапланированный захват канала (что неизбежно приведет к умеьшению какой-то другой полосы канала. на которую ты рассчитывал в других классах). filter parent 1: protocol ip pref 90 fw handle 0x69 classid 1:300 я же просил правила по маркировке пакетов, если ты такие фильтры используешь. тут теперь сидишь и думаешь, то ли ты под редкий приоритетный трафик этот класс 1:300 заточил, то ли просто лажанулся.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	4. "Проблема с шейпером (htb)"	+/–
	Сообщение от LSTemp (ok) on 14-Апр-11, 20:01
	>[оверквотинг удален] > class htb 1:20 parent 1:3 rate 20500Kbit ceil 20500Kbit > class htb 1:300 parent 1:20 leaf 300: prio 2 quantum 12500 rate > 500000bit ceil 5000Kbit > - ты туда ли класс 1:300 прикрутил, судя по логике твоей нумерации? > | > - rate дочернего класса, больше чем у родительского. ноль не лишний в > rate дочернего класса? оно работать будет, но на родительские ограничения ему > станет покласть - отсуда может расти незапланированный захват канала (что неизбежно > приведет к умеьшению какой-то другой полосы канала. на которую ты рассчитывал > в других классах). лажа с моей > filter parent 1: protocol ip pref 90 fw handle 0x69 classid 1:300 > я же просил правила по маркировке пакетов, если ты такие фильтры используешь. > тут теперь сидишь и думаешь, то ли ты под редкий приоритетный > трафик этот класс 1:300 заточил, то ли просто лажанулся.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	5. "Проблема с шейпером (htb)"	+/–
	Сообщение от LSTemp (ok) on 14-Апр-11, 20:06
	>[оверквотинг удален] > class htb 1:20 parent 1:3 rate 20500Kbit ceil 20500Kbit > class htb 1:300 parent 1:20 leaf 300: prio 2 quantum 12500 rate > 500000bit ceil 5000Kbit > - ты туда ли класс 1:300 прикрутил, судя по логике твоей нумерации? > | > - rate дочернего класса, больше чем у родительского. ноль не лишний в > rate дочернего класса? оно работать будет, но на родительские ограничения ему > станет покласть - отсуда может расти незапланированный захват канала (что неизбежно > приведет к умеьшению какой-то другой полосы канала. на которую ты рассчитывал > в других классах). лажа с моей стороны - 20500Kbit таки болше чем 500000bit. > filter parent 1: protocol ip pref 90 fw handle 0x69 classid 1:300 > я же просил правила по маркировке пакетов, если ты такие фильтры используешь. > тут теперь сидишь и думаешь, то ли ты под редкий приоритетный > трафик этот класс 1:300 заточил, то ли просто лажанулся. правила маркировки все равно давай. и полное ts -s * show <DEV> PS я посчитаю, но ты и сам посмотри - может трафик в другой класс утекает.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	6. "Проблема с шейпером (htb)"	+1 +/–
	Сообщение от vvk1987 (ok) on 14-Апр-11, 23:33
	>[оверквотинг удален] > лажа с моей стороны - 20500Kbit таки болше чем 500000bit. >> filter parent 1: protocol ip pref 90 fw handle 0x69 classid 1:300 >> я же просил правила по маркировке пакетов, если ты такие фильтры используешь. >> тут теперь сидишь и думаешь, то ли ты под редкий приоритетный >> трафик этот класс 1:300 заточил, то ли просто лажанулся. > правила маркировки все равно давай. > и полное ts -s * show <DEV> > PS > я посчитаю, но ты и сам посмотри - может трафик в другой > класс утекает. Ну он 100% не утекает. Правила маркировки это обычные правила iptables которые маркают пакеты с определенных ip (это 1:10 класс) и 1:300 это пиринговые пакеты которые ловит ipp2p модуль. Вот чёт почитал ещё дополнительные доки, и чёт подозрения возникают что нада рыть в сторону параметров burst и cburst. Попробую отследить какое кол-во токенов будет в абонентском классе и родительском при падении скорости - через ts -s show   Сейчас посмотрел статистику для root qdisc. Это вообще нормально, что такое большое количество dropped и overlimits? qdisc htb 1: root r2q 5 default 400 direct_packets_stat 1087 ver 3.17 Sent 42737451559 bytes 42739969 pkt (dropped 512899, overlimits 86837479 requeues 15) rate 0bit 0pps backlog 0b 151p requeues 15
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	7. "Проблема с шейпером (htb)"	+/–
	Сообщение от vvk1987 (ok) on 15-Апр-11, 12:06
	>[оверквотинг удален] > Вот чёт почитал ещё дополнительные доки, и чёт подозрения возникают что нада > рыть в сторону параметров burst и cburst. Попробую отследить какое кол-во > токенов будет в абонентском классе и родительском при падении скорости - > через ts -s show > Сейчас посмотрел статистику для root qdisc. Это вообще нормально, что такое большое > количество dropped и overlimits? >  qdisc htb 1: root r2q 5 default 400 direct_packets_stat 1087 ver > 3.17 >  Sent 42737451559 bytes 42739969 pkt (dropped 512899, overlimits 86837479 requeues 15) >  rate 0bit 0pps backlog 0b 151p requeues 15 Блин, чет уже кажется что дело действительно на стороне хостинга(ов). Посмотрел на разных провайдерах, даже на высоких скоростях скорость скачивания не превышает 1 Мбит/с. Например скачивал файл с zaycev.net. У youtube действительно какой то скачек просходит и скорость падает до 1 Мбит (тоже тестил в разных местах). А вот онлайн фильмы (с разных хостингов) шпарили с максимальной для меня скоростью - 2.5 Мбит/с. Но вот такой вопрос, скачивал вечером ~ 21:00 на нашем канале файл с одного сайта, он качался не больше 1 Мбит/с (НАШ канал был свободный). Пробовал скачивать тот же файл, с того же хостинга но уже утром часов в 9:00 и с ДРУГОГО канала (с другим интернетом) там скорость была 2,5 Мбит/с. Возможно ли такое, что это происходит из за того что на хостинге например установлены разные ограничения на разные временные периоды, или вечером просто был забит исходящий канал этого хостинга? Т.е может ли быть что в разное время на хостинге ограничения разные?
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	8. "Проблема с шейпером (htb)"	+/–
	Сообщение от LSTemp (ok) on 20-Апр-11, 18:26
	>[оверквотинг удален] >>> тут теперь сидишь и думаешь, то ли ты под редкий приоритетный >>> трафик этот класс 1:300 заточил, то ли просто лажанулся. >> правила маркировки все равно давай. >> и полное ts -s * show <DEV> >> PS >> я посчитаю, но ты и сам посмотри - может трафик в другой >> класс утекает. > Ну он 100% не утекает. Правила маркировки это обычные правила iptables которые > маркают пакеты с определенных ip (это 1:10 класс) и 1:300 это > пиринговые пакеты которые ловит ipp2p модуль. - клиенты как подключаются к тебе? vlan? vpn? ppoe? etc? - покажи пару правил маркировки пакетов для leaf-классов - дисциплины обслуживания очереди ко всем leaf классам прикручены? какие? > Вот чёт почитал ещё дополнительные доки, и чёт подозрения возникают что нада > рыть в сторону параметров burst и cburst. Попробую отследить какое кол-во > токенов будет в абонентском классе и родительском при падении скорости - > через ts -s show че там рыть? по простому - это сколько объема информации сможет получить клиент на максимальной скорости, прежде чем у него начнут другие ожившие клиенты полосу отбирать. понятно, что burst всех дочерних классов должен быть <= родительского (как и для rate & ceil). судя по докам если это не так, то на установки родительского класса будет положено со всей ответсвенностью :) - я не пробовал - делал по правилам то есть если клиент 1 качает на максимальной скорости (канал полностью свободен) и появляется клиент 2, с которым он канал делит, то при burst 100k 1-й еще 100k скачает на этой скорости, а потом его начнут урезать и делить канал с клиентом 2. > Сейчас посмотрел статистику для root qdisc. Это вообще нормально, что такое большое > количество dropped и overlimits? >  qdisc htb 1: root r2q 5 default 400 direct_packets_stat 1087 ver > 3.17 >  Sent 42737451559 bytes 42739969 pkt (dropped 512899, overlimits 86837479 requeues 15) >  rate 0bit 0pps backlog 0b 151p requeues 15 я бы сказал что нет. при грамотном шейпинге канала на root вообще ничего дропаться не должно. все дропы должны происходить в leaf-классах.   наличие дропа в корневой дисциплине указывает на то, что какой-то трафик остается не классифицированным и идет мимо всех твоих нарезанных каналов (direct_packets_stat 1087). PS ipp2p модуль не спасет отца русской демократии. тому же торрент-клиенту достаточно включить шифрование трафика и данный модуль будет сосать (как очевидно и все ему подобные) ибо основан на анализе содержимого пакета. ИМХО вывод один: поскольку никак не возможно (в частности для торрент-клиентов) достоверно опознать p2p трафик, то единственным методом борьбы с ним является определение более приоритетных классов для всех остальных используемых типов (icmp, http, hppts, ssh, etc) трафика. а p2p и иже с ним - по умолчанию - в кал. долго, нудно, но никуда не денешься.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	9. "Проблема с шейпером (htb)"	+/–
	Сообщение от vvk1987 (ok) on 21-Апр-11, 14:24
	>[оверквотинг удален] >>> и полное ts -s * show <DEV> >>> PS >>> я посчитаю, но ты и сам посмотри - может трафик в другой >>> класс утекает. >> Ну он 100% не утекает. Правила маркировки это обычные правила iptables которые >> маркают пакеты с определенных ip (это 1:10 класс) и 1:300 это >> пиринговые пакеты которые ловит ipp2p модуль. > - клиенты как подключаются к тебе? vlan? vpn? ppoe? etc? > - покажи пару правил маркировки пакетов для leaf-классов > - дисциплины обслуживания очереди ко всем leaf классам прикручены? какие? 1) По vlan 2) во всех классах sfq >[оверквотинг удален] >> рыть в сторону параметров burst и cburst. Попробую отследить какое кол-во >> токенов будет в абонентском классе и родительском при падении скорости - >> через ts -s show > че там рыть? > по простому - это сколько объема информации сможет получить клиент на максимальной > скорости, прежде чем у него начнут другие ожившие клиенты полосу отбирать. > понятно, что burst всех дочерних классов должен быть <= родительского (как > и для rate & ceil). судя по докам если это не > так, то на установки родительского класса будет положено со всей ответсвенностью > :) - я не пробовал - делал по правилам ну это quantum определяет объем информации, перед тем как передавать управление в другой класс. А burst это просто сколько инфы будет передано на максимальной скорости, а остальное уже там будет зависеть сколько токенов будет "истрачено".... Если burst родительского меньше чем дочернего класса, то трафик для листового класса будет просто притормаживать, т.е разгоняется и падает и т.д. Это я проверял. >[оверквотинг удален] >> количество dropped и overlimits? >>  qdisc htb 1: root r2q 5 default 400 direct_packets_stat 1087 ver >> 3.17 >>  Sent 42737451559 bytes 42739969 pkt (dropped 512899, overlimits 86837479 requeues 15) >>  rate 0bit 0pps backlog 0b 151p requeues 15 > я бы сказал что нет. > при грамотном шейпинге канала на root вообще ничего дропаться не должно. все > дропы должны происходить в leaf-классах. > наличие дропа в корневой дисциплине указывает на то, что какой-то трафик остается > не классифицированным и идет мимо всех твоих нарезанных каналов (direct_packets_stat 1087). Может быть это указывает на то что канал иногда перегружен? Ну или достигает иногда моментов, когда полоса практически полностью используется. Просто шейпинг сделан по всем правилам, дефолтный класс стоит, в него иногда что-то попадает. По идее туда всё должно сыпаться.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	10. "Проблема с шейпером (htb)"	+/–
	Сообщение от vvk1987 (ok) on 21-Апр-11, 14:37
	>[оверквотинг удален] >>>  rate 0bit 0pps backlog 0b 151p requeues 15 >> я бы сказал что нет. >> при грамотном шейпинге канала на root вообще ничего дропаться не должно. все >> дропы должны происходить в leaf-классах. >> наличие дропа в корневой дисциплине указывает на то, что какой-то трафик остается >> не классифицированным и идет мимо всех твоих нарезанных каналов (direct_packets_stat 1087). > Может быть это указывает на то что канал иногда перегружен? Ну или > достигает иногда моментов, когда полоса практически полностью используется. > Просто шейпинг сделан по всем правилам, дефолтный класс стоит, в него иногда > что-то попадает. По идее туда всё должно сыпаться. Да, интересный вопрос, ща ещё раз прочитал про параметр direct_packets_stat. Как же он может быть не равен 0 если есть дефолтный класс? Может это какая нить служебная информация отсылается в сеть сервером?
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	11. "Проблема с шейпером (htb)"	+/–
	Сообщение от LSTemp (ok) on 22-Апр-11, 12:30
	>[оверквотинг удален] >>>> я посчитаю, но ты и сам посмотри - может трафик в другой >>>> класс утекает. >>> Ну он 100% не утекает. Правила маркировки это обычные правила iptables которые >>> маркают пакеты с определенных ip (это 1:10 класс) и 1:300 это >>> пиринговые пакеты которые ловит ipp2p модуль. >> - клиенты как подключаются к тебе? vlan? vpn? ppoe? etc? >> - покажи пару правил маркировки пакетов для leaf-классов >> - дисциплины обслуживания очереди ко всем leaf классам прикручены? какие? > 1) По vlan > 2) во всех классах sfq ну а пару примеров маркировки пакетов? >[оверквотинг удален] >> понятно, что burst всех дочерних классов должен быть <= родительского (как >> и для rate & ceil). судя по докам если это не >> так, то на установки родительского класса будет положено со всей ответсвенностью >> :) - я не пробовал - делал по правилам > ну это quantum определяет объем информации, перед тем как передавать управление в > другой класс. А burst это просто сколько инфы будет передано на > максимальной скорости, а остальное уже там будет зависеть сколько токенов будет > "истрачено".... Если burst родительского меньше чем дочернего класса, то трафик для > листового класса будет просто притормаживать, т.е разгоняется и падает и т.д. > Это я проверял. не путайте ежа с ужом. quantum работает с дисциплиной обслуживания очереди в данном классе, а burst - с самим классом. quantum для sfq определяет объем информации, который может быть извлечен из очереди за один раз (не более указанного значения) и к ограничению скорости в классах вообще никакого отношения не имеет. >[оверквотинг удален] >>>  qdisc htb 1: root r2q 5 default 400 direct_packets_stat 1087 ver >>> 3.17 >>>  Sent 42737451559 bytes 42739969 pkt (dropped 512899, overlimits 86837479 requeues 15) >>>  rate 0bit 0pps backlog 0b 151p requeues 15 >> я бы сказал что нет. >> при грамотном шейпинге канала на root вообще ничего дропаться не должно. все >> дропы должны происходить в leaf-классах. >> наличие дропа в корневой дисциплине указывает на то, что какой-то трафик остается >> не классифицированным и идет мимо всех твоих нарезанных каналов (direct_packets_stat 1087). > Может быть это указывает на то что канал иногда перегружен? Ну или несомненно. наличие дропов именно об этом и говорит. но наличие дропов в корневом классе указыват на то, что часть трафика просто не шейпится совсем. что это за трафик, каков его источник и объем и надо в первую очередь выяснять. ну а после шейпить. > достигает иногда моментов, когда полоса практически полностью используется. > Просто шейпинг сделан по всем правилам, дефолтный класс стоит, в него иногда > что-то попадает. По идее туда всё должно сыпаться. по дефолту туда посыпится и трафик самого сервера например, и трафик всех неучтенных видов. если не хотите разбираться с этим трафиком, то попробуйте явно поставить низкопроритетный фильтр на весь трафик (вроде prio 100 u32 dst 0.0.0.0/0) и завернуть его в дефолтный класс - может Вас и такой вариант устроит.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	12. "Проблема с шейпером (htb)"	+/–
	Сообщение от vvk1987 (ok) on 22-Апр-11, 15:00
	>[оверквотинг удален] >>>>> класс утекает. >>>> Ну он 100% не утекает. Правила маркировки это обычные правила iptables которые >>>> маркают пакеты с определенных ip (это 1:10 класс) и 1:300 это >>>> пиринговые пакеты которые ловит ipp2p модуль. >>> - клиенты как подключаются к тебе? vlan? vpn? ppoe? etc? >>> - покажи пару правил маркировки пакетов для leaf-классов >>> - дисциплины обслуживания очереди ко всем leaf классам прикручены? какие? >> 1) По vlan >> 2) во всех классах sfq > ну а пару примеров маркировки пакетов? Маркировка пирингово трафика $IPTABLES -t mangle -A PREROUTING -j CONNMARK --restore-mark $IPTABLES -t mangle -A PREROUTING -m mark ! --mark 0 -j ACCEPT $IPTABLES -t mangle -A PREROUTING -m ipp2p --kazaa --bit -j MARK --set-mark 105 $IPTABLES -t mangle -A PREROUTING -m mark --mark 105 -j CONNMARK --save-mark >[оверквотинг удален] >> другой класс. А burst это просто сколько инфы будет передано на >> максимальной скорости, а остальное уже там будет зависеть сколько токенов будет >> "истрачено".... Если burst родительского меньше чем дочернего класса, то трафик для >> листового класса будет просто притормаживать, т.е разгоняется и падает и т.д. >> Это я проверял. > не путайте ежа с ужом. quantum работает с дисциплиной обслуживания очереди в > данном классе, а burst - с самим классом. quantum для sfq > определяет объем информации, который может быть извлечен из очереди за один > раз (не более указанного значения) и к ограничению скорости в классах > вообще никакого отношения не имеет. Ничего не путаю. Параметр quantum есть как для дисциплины sfq, так и отдельно для каждого класса (просто явно его можно не указывать, а он вычисляется на основе параметра r2q и rate класса). Вот как раз quantum класса и обозначает что я сказал. Вот подтверждение: http://www.docum.org/docum.org/faq/cache/31.html http://www.opennet.me/base/net/htb_manual.txt.html    А quantum для sfq определяет количество байт, которые будут выведены за один раз из одной очереди, перед тем как перейти к другой очереди, но в той же дисциплине. Т.е sfq дисциплина имеет несколько очередей из которых циклически выводится quantum байт. Ну да ладно... >[оверквотинг удален] > надо в первую очередь выяснять. ну а после шейпить. >> достигает иногда моментов, когда полоса практически полностью используется. >> Просто шейпинг сделан по всем правилам, дефолтный класс стоит, в него иногда >> что-то попадает. По идее туда всё должно сыпаться. > по дефолту туда посыпится и трафик самого сервера например, и трафик всех > неучтенных видов. > если не хотите разбираться с этим трафиком, то попробуйте явно поставить низкопроритетный > фильтр на весь трафик (вроде prio 100 u32 dst 0.0.0.0/0) и > завернуть его в дефолтный класс - может Вас и такой вариант > устроит. Меня как раз и напрягает то, почему вместо того чтобы идти в дефолтный класс он не шейпится вообще. Как я думал фильтр по типу prio 100 u32 dst 0.0.0.0/0 как бы уже должен быть захардкожен в htb логику. По доке ведь такая логика объясняется. Время от времени, я перезапускаю htb правила, т.е очищаю и прописываю заного (ну например при изменении параметров какого-нить класса). Может в эти моменты часть трафика "проскакивает"? и изменяет значение direct_packets_stat? И ещё небольшой вопрос, а вот такое большое количество dropped и overlimits пакетов в root qdisc может означать как раз дропанье для дефолтного класса? Просто вот смотрю статистику, эти значения постоянно растут. Главная проблема в том что канал то при этом свободный. Т.е мне не понятны всё таки точные причины как трафик может оставаться непошейпенным при наличии дефолтного класса.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	14. "Проблема с шейпером (htb)"	+/–
	Сообщение от LSTemp (ok) on 22-Апр-11, 15:41
	Вы сказали: "Ничего не путаю. Параметр quantum есть как для дисциплины sfq, так и отдельно для каждого класса (просто явно его можно не указывать, а он вычисляется на основе параметра r2q и rate класса). Вот как раз quantum класса и обозначает что я сказал. Вот подтверждение: http://www.docum.org/docum.org/faq/cache/31.html http://www.opennet.me/base/net/htb_manual.txt.html    А quantum для sfq определяет количество байт, которые будут выведены за один раз из одной очереди, перед тем как перейти к другой очереди, но в той же дисциплине. Т.е sfq дисциплина имеет несколько очередей из которых циклически выводится quantum байт. Ну да ладно..." Вы просто забыли посмотреть для каких типов класса этот параметр валидный. Это параметры не для htb-класса, который Вы используете. Делайте класс sfq и задавайте ему quantum - ради бога - никто не спорит. Только вот с sfq классами Вы например не сможете занимать полосу, которая в данный момент другим клиентом не используется :).
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	13. "Проблема с шейпером (htb)"	+/–
	Сообщение от LSTemp (ok) on 22-Апр-11, 15:08
	> не путайте ежа с ужом. quantum работает с дисциплиной обслуживания очереди в > данном классе, а burst - с самим классом. quantum для sfq > определяет объем информации, который может быть извлечен из очереди за один > раз (не более указанного значения) и к ограничению скорости в классах > вообще никакого отношения не имеет. у Вас же все классы, как htb определены, из того чо Вы листанули. Какой там quantum? а шейпинг классами определяется. 1) Внутри класса может быть указана дисциплина обслуживания очереди (qdisc), которая будет определять каким образом вставшие в очередь пакеты обрабатываются (т.е сколько/какие/в_каком_порядке за один раз отдадуться в класс, который их шейпить будет) например дисциплина sfq старается равномерно отдавать на выход пакеты, которые соотвествуют разным соединениям. и таким образом пытается балансировать нагрузку между всеми сетевыми потоками, которые в нее направлены. это предотвращает монопольный захват всей полосы одним приложением (хотя приложение, которое создает больше сетевых потоков (тот же торрент например), все равно получит преимущество - ибо распределение идет пропорционально сетевым потокам). 2) если объем извлеченной из очереди информации превышает htb ceil, то тут дроп и будет (но заметь - именно в этом классе, а не в корневом). сдедовательно при грамотной настройке (когда parent ceil>=sum(child ceil)) в верхний класс трафик, перекрывающий возможности его пропускной способности просто не пройдет. 3) в результате в корневой дисциплине обслуживания очереди, которая напрямую привязана к интерфейсу, и из которой данные уже в конечном итоге извлекаются и уходят клиентам, дропов быть просто не должно.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	15. "Проблема с шейпером (htb)"	+/–
	Сообщение от vvk1987 (ok) on 22-Апр-11, 15:42
	>[оверквотинг удален] > 2) > если объем извлеченной из очереди информации превышает htb ceil, то тут дроп > и будет (но заметь - именно в этом классе, а не > в корневом). сдедовательно при грамотной настройке (когда parent ceil>=sum(child ceil)) > в верхний класс трафик, перекрывающий возможности его пропускной способности просто не > пройдет. > 3) > в результате в корневой дисциплине обслуживания очереди, которая напрямую привязана к интерфейсу, > и из которой данные уже в конечном итоге извлекаются и уходят > клиентам, дропов быть не должно. Ну дисциплины (sfq) могут быть приаттачены только к краевым классам и никак иначе. Естесно за исключением htb, которая присоеденина к корню. По второму пункту вместо parent ceil>=sum(child ceil) наверно parent RATE>=sum(child RATE). А для ceil там другая формула: parent ceil>=MAX(из child ceil). Все эти рэйт, сейлы они прям точно рассчитаны с учётом всех правил, и т.д. Перед шейпингом прочитал все статьи которые нашел и на русском и на английском. Т.е прям уверен что в параметрах классов никаких косяков не должно быть. Просто вот эта статистика, которая плоходокументирована напрягает. С другой стороны, почему в корневом классе всё понулям стоит: class htb 1:3 root rate 100000Kbit ceil 100000Kbit burst 1600b cburst 1600b Sent 38880096215 bytes 40517713 pkt (dropped 0, overlimits 0 requeues 0) rate 14217Kbit 1870pps backlog 0b 0p requeues 0 lended: 21 borrowed: 0 giants: 0 tokens: -445 ctokens: -445
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	16. "Проблема с шейпером (htb)"	+/–
	Сообщение от LSTemp (ok) on 22-Апр-11, 15:54
	>[оверквотинг удален] >> и будет (но заметь - именно в этом классе, а не >> в корневом). сдедовательно при грамотной настройке (когда parent ceil>=sum(child ceil)) >> в верхний класс трафик, перекрывающий возможности его пропускной способности просто не >> пройдет. >> 3) >> в результате в корневой дисциплине обслуживания очереди, которая напрямую привязана к интерфейсу, >> и из которой данные уже в конечном итоге извлекаются и уходят >> клиентам, дропов быть не должно. > Ну дисциплины (sfq) могут быть приаттачены только к краевым классам и никак > иначе. Естесно за исключением htb, которая присоеденина к корню. Вы просто путаете дисциплину sfq и класс sfq. обработка пакета присходит примерно так: фильтр->очередь (дисциплина) класса->класс->переход на уровень выше и все опять так же > По второму пункту вместо parent ceil>=sum(child ceil) наверно parent RATE>=sum(child RATE). > А для ceil там другая формула: parent ceil>=MAX(из child ceil). запечатался. я про rate сказать хотел. >[оверквотинг удален] > и т.д. Перед шейпингом прочитал все статьи которые нашел и на > русском и на английском. Т.е прям уверен что в параметрах классов > никаких косяков не должно быть. Просто вот эта статистика, которая плоходокументирована > напрягает. > С другой стороны, почему в корневом классе всё понулям стоит: > class htb 1:3 root rate 100000Kbit ceil 100000Kbit burst 1600b cburst 1600b >  Sent 38880096215 bytes 40517713 pkt (dropped 0, overlimits 0 requeues 0) >  rate 14217Kbit 1870pps backlog 0b 0p requeues 0 >  lended: 21 borrowed: 0 giants: 0 >  tokens: -445 ctokens: -445 как это по нулям? Sent 38880096215 bytes, rate 14217Kbit - это что?
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	17. "Проблема с шейпером (htb)"	+/–
	Сообщение от vvk1987 (ok) on 22-Апр-11, 15:55
	>[оверквотинг удален] >> русском и на английском. Т.е прям уверен что в параметрах классов >> никаких косяков не должно быть. Просто вот эта статистика, которая плоходокументирована >> напрягает. >> С другой стороны, почему в корневом классе всё понулям стоит: >> class htb 1:3 root rate 100000Kbit ceil 100000Kbit burst 1600b cburst 1600b >>  Sent 38880096215 bytes 40517713 pkt (dropped 0, overlimits 0 requeues 0) >>  rate 14217Kbit 1870pps backlog 0b 0p requeues 0 >>  lended: 21 borrowed: 0 giants: 0 >>  tokens: -445 ctokens: -445 > как это по нулям? Sent 38880096215 bytes, rate 14217Kbit - это что? Ну я имею ввиду, что dropped 0 и overlimits 0
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	20. "Проблема с шейпером (htb)"	+/–
	Сообщение от LSTemp (ok) on 22-Апр-11, 16:23
	>[оверквотинг удален] >>> никаких косяков не должно быть. Просто вот эта статистика, которая плоходокументирована >>> напрягает. >>> С другой стороны, почему в корневом классе всё понулям стоит: >>> class htb 1:3 root rate 100000Kbit ceil 100000Kbit burst 1600b cburst 1600b >>>  Sent 38880096215 bytes 40517713 pkt (dropped 0, overlimits 0 requeues 0) >>>  rate 14217Kbit 1870pps backlog 0b 0p requeues 0 >>>  lended: 21 borrowed: 0 giants: 0 >>>  tokens: -445 ctokens: -445 >> как это по нулям? Sent 38880096215 bytes, rate 14217Kbit - это что? > Ну я имею ввиду, что dropped 0 и overlimits 0 так быть и должно. в идеале. Вы же весь трафик шейпить хотите => каждый трафик в свой класс => дроп будет в соответствующем (как правило leaf) классе. что в конечном итоге позволяет проанализировать классы, посмотреть какой трафик сечется больше всего (его объем и надобность) и оценить необходимость перенастройки.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	18. "Проблема с шейпером (htb)"	+/–
	Сообщение от vvk1987 (ok) on 22-Апр-11, 15:58
	>[оверквотинг удален] >>> в корневом). сдедовательно при грамотной настройке (когда parent ceil>=sum(child ceil)) >>> в верхний класс трафик, перекрывающий возможности его пропускной способности просто не >>> пройдет. >>> 3) >>> в результате в корневой дисциплине обслуживания очереди, которая напрямую привязана к интерфейсу, >>> и из которой данные уже в конечном итоге извлекаются и уходят >>> клиентам, дропов быть не должно. >> Ну дисциплины (sfq) могут быть приаттачены только к краевым классам и никак >> иначе. Естесно за исключением htb, которая присоеденина к корню. > Вы просто путаете дисциплину sfq и класс sfq. Неее... Не путаю. Sfq - бесклассовая дисциплина. Никаких классов здесь нет. >[оверквотинг удален] >> русском и на английском. Т.е прям уверен что в параметрах классов >> никаких косяков не должно быть. Просто вот эта статистика, которая плоходокументирована >> напрягает. >> С другой стороны, почему в корневом классе всё понулям стоит: >> class htb 1:3 root rate 100000Kbit ceil 100000Kbit burst 1600b cburst 1600b >>  Sent 38880096215 bytes 40517713 pkt (dropped 0, overlimits 0 requeues 0) >>  rate 14217Kbit 1870pps backlog 0b 0p requeues 0 >>  lended: 21 borrowed: 0 giants: 0 >>  tokens: -445 ctokens: -445 > как это по нулям? Sent 38880096215 bytes, rate 14217Kbit - это что?
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	19. "Проблема с шейпером (htb)"	+/–
	Сообщение от LSTemp (ok) on 22-Апр-11, 16:18
	>[оверквотинг удален] >>>> в верхний класс трафик, перекрывающий возможности его пропускной способности просто не >>>> пройдет. >>>> 3) >>>> в результате в корневой дисциплине обслуживания очереди, которая напрямую привязана к интерфейсу, >>>> и из которой данные уже в конечном итоге извлекаются и уходят >>>> клиентам, дропов быть не должно. >>> Ну дисциплины (sfq) могут быть приаттачены только к краевым классам и никак >>> иначе. Естесно за исключением htb, которая присоеденина к корню. >> Вы просто путаете дисциплину sfq и класс sfq. > Неее... Не путаю. Sfq - бесклассовая дисциплина. Никаких классов здесь нет. и точно путаю. днюха у друга - праздную. извини - мозги споили и засрали - дерагют :). все путаю. 3-и сутки пошли... пора останавливаться. burst - это количество данных, которые ты выше скорости ceil послать можешь.   если что не так - извини. но про то что в корне дропов быть не должно - это очевидно. >[оверквотинг удален] >>> русском и на английском. Т.е прям уверен что в параметрах классов >>> никаких косяков не должно быть. Просто вот эта статистика, которая плоходокументирована >>> напрягает. >>> С другой стороны, почему в корневом классе всё понулям стоит: >>> class htb 1:3 root rate 100000Kbit ceil 100000Kbit burst 1600b cburst 1600b >>>  Sent 38880096215 bytes 40517713 pkt (dropped 0, overlimits 0 requeues 0) >>>  rate 14217Kbit 1870pps backlog 0b 0p requeues 0 >>>  lended: 21 borrowed: 0 giants: 0 >>>  tokens: -445 ctokens: -445 >> как это по нулям? Sent 38880096215 bytes, rate 14217Kbit - это что?
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	21. "Проблема с шейпером (htb)"	+/–
	Сообщение от vvk1987 (ok) on 22-Апр-11, 18:44
	>[оверквотинг удален] >>>> русском и на английском. Т.е прям уверен что в параметрах классов >>>> никаких косяков не должно быть. Просто вот эта статистика, которая плоходокументирована >>>> напрягает. >>>> С другой стороны, почему в корневом классе всё понулям стоит: >>>> class htb 1:3 root rate 100000Kbit ceil 100000Kbit burst 1600b cburst 1600b >>>>  Sent 38880096215 bytes 40517713 pkt (dropped 0, overlimits 0 requeues 0) >>>>  rate 14217Kbit 1870pps backlog 0b 0p requeues 0 >>>>  lended: 21 borrowed: 0 giants: 0 >>>>  tokens: -445 ctokens: -445 >>> как это по нулям? Sent 38880096215 bytes, rate 14217Kbit - это что? Сейчас собрал всю статистику, выполнил tc -s -d qdisc show dev eth0 | grep dropped > dropped.log создал скрипт, который подсчитывает сумму Sent dropped для всех дисциплин. И вот что оказалось: Вот что статистика выдала для root qdisc: Sent 55617906185 bytes 57933006 pkt (dropped 828280, overlimits 121745778 requeues 24) И вот что посчитал мой скрипт для всех остальных НЕ root qdisc: Sent 55617501176 dropped 828280 Т.е как я теперь понимаю в root qdisc отображается просто сумма dropped ну и Sent пакетов. Правда тут Sent разошелся на 400 Кбайт, но думаю это не значительно. Правда overlimits получился не равен сумме. Так как у всех остальных это значение 0.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	22. "Проблема с шейпером (htb)"	+/–
	Сообщение от LSTemp (ok) on 22-Апр-11, 19:20
	>[оверквотинг удален] > tc -s -d qdisc show dev eth0 | grep dropped > dropped.log > создал скрипт, который подсчитывает сумму Sent dropped для всех дисциплин. И вот > что оказалось: > Вот что статистика выдала для root qdisc: > Sent 55617906185 bytes 57933006 pkt (dropped 828280, overlimits 121745778 requeues 24) > И вот что посчитал мой скрипт для всех остальных НЕ root qdisc: > Sent 55617501176 dropped 828280 > Т.е как я теперь понимаю в root qdisc отображается просто сумма dropped > ну и Sent пакетов. > Правда тут Sent разошелся на 400 Кбайт, но думаю это не значительно. конечно незначительно. а sent ему сам бог велел как сумму чилдов показывать. а вот Вам тест на старой федоре-4: QDISC: qdisc htb 1: r2q 10 default 20 direct_packets_stat 0 Sent 1067567 bytes 1095 pkt (dropped 0, overlimits 1104 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 20: parent 1:20 limit 128p quantum 1514b perturb 10sec Sent 1067567 bytes 1095 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 CLASS: class htb 1:1 root rate 1000Kbit ceil 2000Kbit burst 300Kb cburst 300Kb Sent 1067567 bytes 1095 pkt (dropped 0, overlimits 0 requeues 0) rate 56480bit 7pps backlog 0b 0p requeues 0 lended: 0 borrowed: 0 giants: 0 tokens: 2456768 ctokens: 1228384 class htb 1:20 parent 1:1 leaf 20: prio 0 rate 500000bit ceil 500000bit burst 1850b cburst 1850b Sent 1067567 bytes 1095 pkt (dropped 0, overlimits 0 requeues 0) rate 54528bit 7pps backlog 0b 0p requeues 0 lended: 1095 borrowed: 0 giants: 0 tokens: 27936 ctokens: 27936 FILTER: filter parent 1: protocol ip pref 49152 u32 filter parent 1: protocol ip pref 49152 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 49152 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:20  (rule hit 1094 success 1094)   match 00000000/00000000 at 16 (success 1094 ) все идет в оди класс - 1:20 ( видно что по фильту 1094 пакета прошоло, а в корне 1095). тут вообще ни в каких классах, кроме корневого, статистики по дропу нет (имеется в виду ненулевой). обновляться не пробовали? м/б и реализация в дистрибутиве тоже роль играет. показ в родительском классе суммы дропов чилдов тоже имеет место жить - это вполне адекватный вариант. только не очень удобный для анализа. > Правда overlimits получился не равен сумме. Так как у всех остальных это > значение 0.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема