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

["Michael T. Babcock" <mbabcock@fibrespeed.net>]

On Sun, Dec 09, 2001 at 09:06:47PM -0800, Don Cohen wrote:
>  > 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!

No -- I agreed with both of you at some level.  In fact, what I should have
pointed out is that I believe the root qdisc should have its bandwidth set
to the physical bandwidth of the device.

According to Radhakrishnan*, for a qdisc:
 * bandwidth represents the maximum bandwidth that is available to the 
   queuing discipline owned by this class.
 * rate represents the bandwidth that is allocated to this class. The 
   kernel does not use this directly. It uses pre-calculated rate 
   translation tables.

*See http://qos.ittc.ukans.edu/howto/ for an old HOWTO.

>  > 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
                  ^^^Device bandwidth
>  > 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
                  ^^^Link bandwidth

> This bandwidth (256 above) is NOT the physical device bandwidth.

It sure is when the ISDN modem can't do more than 256Kbit ... ;-)

> Great.  So maybe you should tell us what the value is supposed to mean!

No, I'm not that smart -- use Google.

>  > 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.

Where exactly did you disagree with me there?  'Not on a per-qdisc scale' seems
to expand to both your statements.  An SFQ 'flow' is a queue of packets, but
it is not a queuing discipline -- I specified that the queue would not be reordered
but that different queues would have their packets pulled off the qdisc in a
potentially different order from the order they were originally queued up in.
-- 
Michael T. Babcock
CTO, FibreSpeed Ltd.     (Hosting, Security, Consultation, Database, etc)
http://www.fibrespeed.net/~mbabcock/

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/