RE: [LARTC] exploring HTB

[don-lartc@isis.cs3-inc.com (Don Cohen)]

 > Subject: RE: [LARTC] exploring HTB

I expected someone else to say this before, but since nobody has yet ... 

 > > > Just to note that speed depends ONLY on number of ACTIVE classes (active
 > > > flows). Those without data enqueued are idle and don't decrease
 > > > throughtput.
First, the classification time could be pretty significant with
hundreds of filters.  You could minimize this by building a balanced
tree of classes, so that it would only take log(#classes) filters, but
that would be a lot of trouble to build and maintain.

 > > 	Presently I'm running setup with 200 queues (200 RED leaves and 200 u32
 > > classifiers), Thus basically a seperate queue for every individual in my
 > > organization. Ya I never knew about the dependency of throughput on active
 > > flows. I'm planing to go for 400 queues. Sometime before Documentations on
 > > Devik's home page stat that RED is not going to work with HTB and will
 > > simply eat CPU cycles. I couldn't locate it now anywhere? Does it works with
 > > new release of HTB?

I don't think this is the problem HTB was meant to solve.
I think what you really want is the (often suggested/requested)
modified version of sfq that hashes only on source or destination
address (depending on whether you use it for the queue going in to or
out of your local network).  If your addresses are consecutive then
the "hash" function could be particularly good (fast and no
collisions). This would not allow you to offer different amounts of
service to different addresses, but that could also be added easily
(though it would then reintroduce the inconvenience of maintaining
this data in the configuration file).
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/