On Thu, 7 Sep 2000, Dennis wrote: > At 03:53 PM 09/07/2000 -0400, you wrote: > > > >[stuff about inefficiencies of CBQ deleted] > > > >Denis, can you provide substantial proof of what you claim? > > Read the studies, its an inherent property of the technique. Its a > round-robin deal, and the larger the robin, the less efficient the round > Only the highest priority traffic is guaranteed its slice...everything else > suffers as the number of queues increase. Is this a problem, or a simple Operating design trade-off? There are many queues implies there is more overhead in the RR. There are many flows implies you use more RAM. This applies to _any_ scheduling algorithm in _any_ operating systems is not specific to CBQ being RR. FYI, Linux CBQ uses DRR. What was the other alternative that you were thinking of to replace RR schemes? > the 2 major pitfalls of cbq are: > > 1) unidirectional (outgoing) only Give me a reason as to why you want to shape inbound packets in a PC architecture. Actually give me a reason why you would want to do it in an architecture with a switched fabric. Policing inbound traffic, yes (and we already have it in Linux -- its called the ingress qdisc) Non work-conserving inbound shaping? please provide the rationale. [of course there are probably router vendors out there who would try to sell you what you just said because that is what their design dictates] > 2) inefficiencies increase with the number of streams/classes > Read my arguement above. FYI, there are many scheduling algorithms in Linux. You can take your pick and use what you like. cheers, jamal - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org
