Hi I am trying to upgrade our systems with 2.4.20/HTB3 (before that I used 2.4.9 based kernel with HTB2 patch with no such problems). Since it booted the new kernel I get a lot of kernel messages that keeps klogd using CPU. Here is a sample: Jan 21 09:57:34 s kernel: KERNEL: assertion (cl && cl->un.leaf.q->q.qlen) failed at sch_htb.c(959) Jan 21 09:58:05 s last message repeated 447911 times Jan 21 09:59:06 s last message repeated 879964 times Jan 21 10:00:07 s last message repeated 901413 times I can comment out that assertion from sources but what exactly does that warning mean ? Should I silently ignore it or do I need to fix it ? Also when I run our htb configuration script I get a lot of this kind of messages: Jan 21 09:50:15 s kernel: uantum of class 10056B is small. Consider r2q change .<4>HTB: quantum of class 100578 is small. Consider r2q change.<4>HTB: quantum o f class 100610 is small. Consider r2q change.<4>HTB: quantum of class 100622 is small. Consider r2q change.<4>HTB: quantum of class 100642 is small. Consider r2 q change.<4>HTB: quantum of class 10068B is small. Consider r2q change.<4>HTB: q uantum of class 10068C is small. Consider r2q change.<4>HTB: quantum of class 10 0732 is small. Consider r2q change.<4>HTB: quantum of class 10070B is small. Con sider r2q change.<4>HTB: quantum of class 10070C is small. Consider r2q change.< 4>HTB: quantum of class 10070D is small. Consider r2q change.<4>HTB: quantum of class 1006A6 is small. Consider r2q change.<4>HTB: quantum of class 1006B1 is sm all. Consider r2q change.<4>HTB: quantum of class 1006B2 is small. Consider r2q change.<4>HTB: quantum of class 1006C3 is small. Consider r2q change.<4>HTB: qua ntum of class 1006D5 is small. Consider r2q change.<4>HTB: quan Jan 21 09:50:33 s kernel: of class 1006D6 is small. Consider r2q change.<4>HTB : quantum of class 100725 is small. Consider r2q change.<4>HTB: quantum of class 10072A is small. Consider r2q change.<4>HTB: quantum of class 100737 is small. Consider r2q change.<4>HTB: quantum of class 100738 is small. Consider r2q chang e.<4>HTB: quantum of class 1011C8 is small. Consider r2q change.<4>HTB: quantum of class 1011C9 is small. Consider r2q change.<4>HTB: quantum of class 1011CA is small. Consider r2q change.<4>htb: class F00F10 isn't work conserving ?! and so on... What is wrong with the script ? Why doesnt HTB3 like it ? Thanks ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mihai RUSU wrote: | Hi | | I am trying to upgrade our systems with 2.4.20/HTB3 (before that I used | 2.4.9 based kernel with HTB2 patch with no such problems). Since it booted | the new kernel I get a lot of kernel messages that keeps klogd using CPU. | | Here is a sample: | | Jan 21 09:57:34 s kernel: KERNEL: assertion (cl && cl->un.leaf.q->q.qlen) failed at sch_htb.c(959) | Jan 21 09:58:05 s last message repeated 447911 times | Jan 21 09:59:06 s last message repeated 879964 times | Jan 21 10:00:07 s last message repeated 901413 times | | I can comment out that assertion from sources but what exactly does that | warning mean ? Should I silently ignore it or do I need to fix it ? | | Also when I run our htb configuration script I get a lot of this kind of | messages: | | Jan 21 09:50:15 s kernel: uantum of class 10056B is small. Consider r2q change | .<4>HTB: quantum of class 100578 is small. Consider r2q change.<4>HTB: quantum o | | and so on... | | What is wrong with the script ? Why doesnt HTB3 like it ? These messages appear because of too small rates or ceils for that classes (10:056B, 10:0578, ...). The implicit value for r2q is 10 and because of this the quantum value is too small. "Consider r2q change" it's a good ideea indeed ;-) You can take a look at devik's faq page, maybe it can help: http://luxik.cdi.cz/~devik/qos/htb/htbfaq.htm I don't know if that assertion has the same reason, I haven't noticed something like that in my logs. - -- Catalin Bucur mailto:cata@geniusnet.ro NOC @ Genius Network SRL - Galati - Romania -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+LTU8pDe20wwI9oIRAo+HAJ90pY9n1oCHkxn4vT+JeTUtkr/3fwCffHlU uBMA2jrV0D1+P5moftwTjbA= =yiPG -----END PGP SIGNATURE-----
> These messages appear because of too small rates or ceils for that > classes (10:056B, 10:0578, ...). The implicit value for r2q is 10 and > because of this the quantum value is too small. "Consider r2q change" > it's a good ideea indeed ;-) > You can take a look at devik's faq page, maybe it can help: > http://luxik.cdi.cz/~devik/qos/htb/htbfaq.htm Or www.docum.org on the faq page. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net
On Tue, 21 Jan 2003, Catalin Bucur wrote: > These messages appear because of too small rates or ceils for that > classes (10:056B, 10:0578, ...). The implicit value for r2q is 10 and > because of this the quantum value is too small. "Consider r2q change" > it's a good ideea indeed ;-) > You can take a look at devik's faq page, maybe it can help: > http://luxik.cdi.cz/~devik/qos/htb/htbfaq.htm > > I don't know if that assertion has the same reason, I haven't noticed > something like that in my logs. > Hello Catalin and Stef Thanks for your answers. Indeed after digging more into documentation (the docum.org one is great) we got more less logs. But our logs werent flooded with "quantum" related messages but with that kernel assertion thing. If nobody cant help me here Ill try to contact Mr Martin Devera directly. I have a 2 tree configuration. Here is an example script: #!/bin/bash tc="/sbin/tc" $tc qdisc del dev eth0 root $tc qdisc add dev eth0 root handle 1: htb default 30 $tc class add dev eth0 parent 1: classid 1:1 htb rate 100Mbit $tc class add dev eth0 parent 1:1 classid 1:10 htb rate 40Mbit $tc class add dev eth0 parent 1:1 classid 1:20 htb rate 40Mbit $tc class add dev eth0 parent 1:1 classid 1:30 htb rate 20Mbit # create the first class tree $tc qdisc add dev eth0 parent 1:10 handle 10: htb default 20 $tc class add dev eth0 parent 10: classid 10:1 htb rate 40Mbit $tc class add dev eth0 parent 10:1 classid 10:10 htb rate 256Kbit $tc class add dev eth0 parent 10:1 classid 10:20 htb rate 1Mbit ceil 40Mbit # create the second class tree $tc qdisc add dev eth0 parent 1:20 handle 20: htb default 20 $tc class add dev eth0 parent 20: classid 20:1 htb rate 40Mbit $tc class add dev eth0 parent 20:1 classid 20:10 htb rate 64Kbit $tc class add dev eth0 parent 20:1 classid 20:20 htb rate 1Mbit ceil 40Mbit In fact we dont keep at a time more than 1 tree. So I have qdisc htb 1: and qdisc htb 10: or 20: at a time. When I want to reinitilize my htb trees I create the other tree from the new data (the trees are created db based) but if the current tree is 10: I create the new one 20: . Then after the new tree creation completes I do a tc filter change to classify packets onto the new tree and then a tc qdisc del the old tree (for example 10:). I observed that if between tc filter change (making new packets classify into the new tree) and tc qdisc del (deleting the old tree) I put a delay smaller than a certain ammount (here is 2 seconds) then I get those kernel assertion messages. And I dont get them only for a finite ammount of time, but I get them continously flooding my logs. If I reinitilize the htb tree again but having a bigger delay then I dont get any of that messages. Help ? :) ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated.
> I have a 2 tree configuration. Here is an example script: > #!/bin/bash > > tc="/sbin/tc" > > $tc qdisc del dev eth0 root > $tc qdisc add dev eth0 root handle 1: htb default 30 > $tc class add dev eth0 parent 1: classid 1:1 htb rate 100Mbit > > $tc class add dev eth0 parent 1:1 classid 1:10 htb rate 40Mbit > $tc class add dev eth0 parent 1:1 classid 1:20 htb rate 40Mbit > $tc class add dev eth0 parent 1:1 classid 1:30 htb rate 20Mbit > > # create the first class tree > $tc qdisc add dev eth0 parent 1:10 handle 10: htb default 20 > $tc class add dev eth0 parent 10: classid 10:1 htb rate 40Mbit > > $tc class add dev eth0 parent 10:1 classid 10:10 htb rate 256Kbit > $tc class add dev eth0 parent 10:1 classid 10:20 htb rate 1Mbit ceil 40Mbit > > # create the second class tree > $tc qdisc add dev eth0 parent 1:20 handle 20: htb default 20 > $tc class add dev eth0 parent 20: classid 20:1 htb rate 40Mbit > > $tc class add dev eth0 parent 20:1 classid 20:10 htb rate 64Kbit > $tc class add dev eth0 parent 20:1 classid 20:20 htb rate 1Mbit ceil 40Mbit > > > In fact we dont keep at a time more than 1 tree. So I have qdisc htb 1: > and qdisc htb 10: or 20: at a time. When I want to reinitilize my htb > trees I create the other tree from the new data (the trees are created db > based) but if the current tree is 10: I create the new one 20: . Then > after the new tree creation completes I do a tc filter change to classify > packets onto the new tree and then a tc qdisc del the old tree (for > example 10:). I observed that if between tc filter change (making new > packets classify into the new tree) and tc qdisc del (deleting the old > tree) I put a delay smaller than a certain ammount (here is 2 seconds) > then I get those kernel assertion messages. And I dont get them only for a > finite ammount of time, but I get them continously flooding my logs. If I > reinitilize the htb tree again but having a bigger delay then I dont get > any of that messages. > > Help ? :) Maybe you can activate the debugging in kernel. Can you reproduce this with a small tree? Can you make a _short_ sample script that duplicates the problem? > > ---------------------------- > Mihai RUSU > > Disclaimer: Any views or opinions presented within this e-mail are solely > those of the author and do not necessarily represent those of any company, > unless otherwise specifically stated. > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > --- Catalin(ux) BOIE catab@deuroconsult.ro H323: dino.rdsbv.ro
> Thanks for your answers. Indeed after digging more into documentation (the > docum.org one is great) we got more less logs. But our logs werent flooded > with "quantum" related messages but with that kernel assertion thing. If > nobody cant help me here Ill try to contact Mr Martin Devera directly. So the quantum errors are gone? > In fact we dont keep at a time more than 1 tree. So I have qdisc htb 1: > and qdisc htb 10: or 20: at a time. When I want to reinitilize my htb > trees I create the other tree from the new data (the trees are created db > based) but if the current tree is 10: I create the new one 20: . Then > after the new tree creation completes I do a tc filter change to classify > packets onto the new tree and then a tc qdisc del the old tree (for > example 10:). I observed that if between tc filter change (making new > packets classify into the new tree) and tc qdisc del (deleting the old > tree) I put a delay smaller than a certain ammount (here is 2 seconds) > then I get those kernel assertion messages. And I dont get them only for a > finite ammount of time, but I get them continously flooding my logs. If I > reinitilize the htb tree again but having a bigger delay then I dont get > any of that messages. > > Help ? :) A htb qdisc attached to a htb class is useless and will only eat cpu cycles. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net
Hi Stef On Wed, 22 Jan 2003, Stef Coene wrote: > So the quantum errors are gone? > Yes, thanks again for the tips > > > > Help ? :) > A htb qdisc attached to a htb class is useless and will only eat cpu cycles. > > Stef > What do you mean ? They seem to work just fine. Im no interested in any effect other than beeing able to delete the whole tree from a single command (and deleting the htb qdisc does that) so thats why I created 2 qdiscs inside 2 htb classes. Are there any nasty side effects ? Can you give me some more details ? Thanks ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated.
On Thursday 23 January 2003 00:58, Mihai RUSU wrote: > Hi Stef > > On Wed, 22 Jan 2003, Stef Coene wrote: > > So the quantum errors are gone? > > Yes, thanks again for the tips > > > > Help ? :) > > > > A htb qdisc attached to a htb class is useless and will only eat cpu > > cycles. > > > > Stef > > What do you mean ? They seem to work just fine. Im no interested in any > effect other than beeing able to delete the whole tree from a single > command (and deleting the htb qdisc does that) so thats why I created 2 > qdiscs inside 2 htb classes. Are there any nasty side effects ? Can you > give me some more details ? Thanks If it works, fine for you. It's just not something I would advice :) But why not delete the root qdisc and recreate it? Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net
On Thu, 23 Jan 2003, Stef Coene wrote: > If it works, fine for you. It's just not something I would advice :) > But why not delete the root qdisc and recreate it? > > Stef All started when we observed that in the meantime (the time between tc qdisc del and the time it takes to recreate the whole new tree) people's TCP connections speed increases very much, so its not very nice. We recreate the trees like 100 times a day so that can be a problem. So then we made the 2 trees system. While building the new tree the old one still "serves" packets and then we change by a simple tc filter change. As we observed there is still a small bandwidth increase (the classes are empty) but its very small compared to the other one. If you have another solution please say. ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated.
On Thursday 23 January 2003 20:22, Mihai RUSU wrote: > On Thu, 23 Jan 2003, Stef Coene wrote: > > If it works, fine for you. It's just not something I would advice :) > > But why not delete the root qdisc and recreate it? > > > > Stef > > All started when we observed that in the meantime (the time between tc > qdisc del and the time it takes to recreate the whole new tree) people's > TCP connections speed increases very much, so its not very nice. We > recreate the trees like 100 times a day so that can be a problem. > > So then we made the 2 trees system. While building the new tree the old > one still "serves" packets and then we change by a simple tc filter > change. As we observed there is still a small bandwidth increase (the > classes are empty) but its very small compared to the other one. > > If you have another solution please say. No, I havent'. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net