[LARTC] more on cbq parameters ,further CBQ/tc doc,

[don-lartc@isis.cs3-inc.com (Don Cohen)]

 > 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@fibrespeed.net>
To: LARTC List <lartc@mailman.ds9a.nl>
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/