We have already developed a better solution. I was just trying to save the guy time trying to do something that probably can't be done with the tools he's using. Dennis www.etinc.com At 08:44 AM 09/08/2000 -0400, jamal wrote: > >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
