[LARTC] Re: is HTB better than CBQ

[LARTC] Re: is HTB better than CBQ

[Jason Tackaberry]

> Hmm, well, I'm trying very hard to understand CBQ because I need to give a
> lecture about it. And I am not succeeding. HTB currently has some

You don't know how relieved I am to hear you say that. :)  I too am
having problems getting a solid handle on CBQ.  And here I thought I was
just being dense. :)

> Right now, if your link sharing needs can be handled by CBQ.init (also
> mentioned in the HOWTO), by all means use it. I suspect CBQ may scale better

CBQ.init looks good, and might do the job, but I don't want to use it on
principle because it's basically a black box.  I tried to read and
understand the script, but that's difficult because I don't understand
CBQ.

So if I can do everything "from first principles" with HTB, I'd be much
happier.  I do plan to try it next week.  I'll share my results with
everyone.

Regards,
Jason.


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/

[LARTC] Re: is HTB better than CBQ

[Martin Devera]

Hi Bert,

by the way, what is lartc@mailman.ds9a.nl ?

> > > In other news, I added a section on HTB,
> > > http://ds9a.nl/2.4Routing/HOWTO//cvs/2.4routing/output/2.4routing-10.html#ss10.2
> > > which you should read if you thing CBQ is complicated. And I added a link to
> > > docum.org, which you should visit.

thanks for good work and for mentioning HTB :) 

> > I guess the impression I get from what you wrote is that HTB is good in
> > simple cases, and CBQ is good in complex cases?  It might be worth
> > explaining a situation in which HTB is inadequate but CBQ would do the
> > job.  I'm not totally clear on that. :)

Well, there are: HTB don't allow you to attach classifiers (filters)
to inner levels of hierarchy yet. I'll implement it if people will 
want it. This is no deficiency about it only more classifiers per
single qdisc might be simpler to maintain.
CBQ allows you to play with overlimit strategies (when class is over
what to do: delay class, drop class, delay parent ..). HTB always
delays class (like TBF or CBQ's default mode). Almost everyone uses
this mode. Maybe some shiny day I'll add drop mode - it is only mode
(except class delay) which makes sense and could shorten delays.
And finally, HTB has less knobs to play with. It's good for majority
of people but there are men which like to play with many settings :-)
About performance issues see bellow.

> Hmm, well, I'm trying very hard to understand CBQ because I need to give a
> lecture about it. And I am not succeeding. 

Drop me a mail. I'll explain you those dark parts of CBQ. It is not
too hard but is it hard enough to make you headaches ;-)
I spent year to understand it. But I was still missing something. The
found the key to understand it while designing HTB. If you want to
understand CBQ then don't think about top level sharing. It is only
way how to implement principle not principle itself...

> HTB currently has some
> performance design issues, which you can read on the site I mention in the
> HOWTO, but these appear to be resolveable.
> 
> Right now, if your link sharing needs can be handled by CBQ.init (also
> mentioned in the HOWTO), by all means use it. I suspect CBQ may scale better
> to larger amounts of bandwidths and complexer situations. However, if what
> you want is too difficult for CBQ.init and you have to type the scripts by
> hand, HTB wins -hands down-.
> 
> HTB will get there (it is not yet in the kernel for example), but may have
> some problems today - although authors tend to overestimate the problems
> their inefficiencies will cause. Right now HTB is polled too often to see if
> it has a packet available. 

Let me correct it a bit. The problem with polling too often is not
tied to HTB. All other non-work-conserving disciplines (those which can
"hold" packets - HTB,CBQ and TBF) suffer from it. There is no way to say
QoS layer: hey here is skb (packet) and it is LAST one I have for now.
Instead after each last packet there is one more dequeue event to see
whether qdisc is empty. But non-work-conserving qdisc can hold packet
and what is worse the packet can be hidden in their non-work-conserving
child. Then the qdisc has to do whole work because it doesn't know whether
the child would like to release its skb.
As I've written in manual, I plan to add option to say that the HTB
instance has only work-conserving children (normal use, it
sometimes doesn't hold for experiments and simulations) and it would
enable to optimize for such case (quickly return from dequeue when time
shows that I just dequeued last packet).

So that only performance difference is from different algorithm. Sometimes
wins HTB sometimes CBQ. But they are not too different. I did measurements
(using pentium's TSC) and it showed that neither CBQ nor HTB is
bottleneck. Most of time is lost somewhere in networking code (80% for
7 class CBQ/HTB) not in QoS.
In fact during testing I successfully reached 380 Mbit throughtput with
PII/600 and HTB with 7 classes (not tested with CBQ). It was with
two full-duplex RTL NICs. I'd sometime like to test gigabit cards ..

> The patch is very modular and does not touch other parts of the kernel. In
> fact, it could be distributed as a separate program, you just need to have
> the kernel headers available.

It is true. I'd only note that I fixed the patches a few days ago because
they didn't work as non-module. There was missing initialization call
from sch_api.c . But if you want to compile only with includes (as
mentioned above by bert) you can simply remove the last ten lines
from new patches.

best regards, 
devik


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/