Hi Bert, by the way, what is lartc@xxxxxxxxxxxxxxx ? > > > 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
