From mboxrd@z Thu Jan 1 00:00:00 1970 From: don-lartc@isis.cs3-inc.com (Don Cohen) Date: Mon, 10 Dec 2001 05:06:47 +0000 Subject: [LARTC] more on cbq parameters ,further CBQ/tc doc, Message-Id: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org > Subject: Re: [LARTC] more on cbq parameters > > On Sat, Dec 08, 2001 at 09:10:50PM +0100, bert hubert wrote: > > > Notice above I supplied bandwidth 30kbit which is far from the actual > > > physical bandwidth (100Mbit). Maybe this is why I get good results. > > > Maybe this is what you're SUPPOSED to do! > > > > Not that I'm aware of. > > To agree with you, AFAICS, the correct way to deal with this is to specify > the root bandwidth as the maximum physical bandwidth on the interface, then > split it down using classes that have rates set to the expected rates. It sounds like you're agreeing with Bert but I think you're really agreeing with ME! > On a 100Mbit card connected to a 256kbit line, I used something like: > > tc qdisc add dev eth0 root handle 1: cbq \ > bandwidth 100Mbit avpkt 1000 > tc class add dev eth0 parent 1:0 classid 1:1 cbq \ > bandwidth 100Mbit rate 256kbit [...] > tc qdisc add dev eth0 parent 1:1 handle 10: cbq \ > bandwidth 256kbit allot 1514 avpkt 1000 This bandwidth (256 above) is NOT the physical device bandwidth. Whereas the only thing about bandwidth in http://www.ds9a.nl/2.4Routing/HOWTO//cvs/2.4routing/output/2.4routing-9.html#ss9.4 is: bandwidth The physical bandwidth of your device, also needed for idle time calculations. I see below that > tc-cbq.8 now says, under CLASSES ... > bandwidth rate > This is different from the bandwidth specified when creating a CBQ disc. Only > used to determine maxidle and offtime, which are only calculated when > specifying maxburst or minburst. Mandatory if specifying maxburst or minburst. Great. So maybe you should tell us what the value is supposed to mean! ======== From: "Michael T. Babcock" To: LARTC List Subject: Re: [LARTC] Re: further CBQ/tc documentation ds9a.nl/lartc/manpages > Reordering happens on a mass scale (packets often go out in a different order > than they were received / generated) but not on a per-qdisc scale (packets > go out 'in order' within an SFQ queue or within a CBQ queue). Its quite No, that's not true either. Within SFQ the packets in one "flow" will not be reordered, within a CBQ class, CBQ itself won't reorder them but of course the child qdisc might. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/