> > > > 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. I'm not sure. How balanced tree of classes could help you with big number of filters ? These are unrelated IMHO. When filter determines class number it is looked using hash table. If you use u32 with 200 nodes in tree and htb then classification time will be about 5 steps for each packet... > > > 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 > > 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 Right. I think so too :) HTB can be useful in this way if you want different parameters (rate,prio) per host .. But we definitely need the changed sfq. The change is trivial but I'm too deep in new htb just now :( devik
