> 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" <mbabcock@xxxxxxxxxxxxxx> To: LARTC List <lartc@xxxxxxxxxxxxxxx> 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.
