On Fri, 8 Sep 2000, Dennis wrote: > 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. I am glad you are becoming more rational these days and cutting down a little on blanket marketeering statements. You used the word "probably". You are doing good, Denis. Now, what is it that you think cant be done with Linux as is today? cheers, jamal > > 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
