Justin Schoeman wrote:
Hi all,
I have been getting some strange results with HTB in kernel 2.6.11, and
was wondering if anybody could give me some advice. Also, if someone
could direct me to the changelog for the recent versions so I can see if
it is worth upgrading?
Anyway, the problem can best be summed up by looking at the output of
'tc -s -d class show dev eth0'. Some of the relevant results are:
class htb 1:1 root rate 1686Kbit ceil 1686Kbit burst 1809b/8 mpu 0b
overhead 0b
cburst 1809b/8 mpu 0b overhead 0b level 7
Sent 1964319339 bytes 2514673 pkt (dropped 0, overlimits 0 requeues 0)
rate 1694Kbit 244pps backlog 0b 0p requeues 0
lended: 1257439 borrowed: 0 giants: 0
tokens: -29826 ctokens: -29826
class htb 1:8 parent 1:1 rate 32000bit ceil 1686Kbit burst 1603b/8 mpu
0b overhe
ad 0b cburst 1809b/8 mpu 0b overhead 0b level 6
Sent 27361971 bytes 52043 pkt (dropped 0, overlimits 0 requeues 0)
rate 32704bit 6pps backlog 0b 0p requeues 0
lended: 16076 borrowed: 2007 giants: 0
tokens: -1796566 ctokens: 16310
class htb 1:39 parent 1:1 rate 8000bit ceil 1686Kbit burst 1600b/8 mpu
0b overhe
ad 0b cburst 1809b/8 mpu 0b overhead 0b level 6
Sent 258423850 bytes 281091 pkt (dropped 0, overlimits 0 requeues 0)
rate 132152bit 19pps backlog 0b 0p requeues 0
lended: 5241 borrowed: 270604 giants: 0
tokens: -1073545 ctokens: 1525
As you can see, the parent class is pretty much maxxed out, which is
fine, but two of the child classes are not OK... 1:8 with a target rate
of 32kbit is getting 32kbit, while 1:39 with a target rate of 8kbit is
getting 132kbit! Looking at the states, this seems to be the normal
state while the link is saturated.
Can anybody see something obvious wrong (perhaps an underflow, or
something?), or is more info needed? If so, what info?
Neither are backlogged - If several consecutive tc -s -d class show dev
eth0 are the same then htb isn't limiting them at that time.
1:39 is allowed to borrow - but you say the link is full perhaps your
ceil is too high and you are not fully in control, or you have attached
queues to the leafs which are too short, or there is packet loss elsewhere.
Andy.
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
