> 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).
