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

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

[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/

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

[Michael T. Babcock]

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/

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

[Stef Coene]

>  > 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.htm
>l#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!
I don't know exactly what the parameter does, but I know that you need to 
specify it like Michael T. Babcock does to get CBQ working.

For the root qdisc this is indeed the physical link bandwidth.  But if you 
attach a qdisc to a class, this is the rate of the class.  I suggest to 
create a bounded class with rate = link bandwidth and attach a qdisc to it.  
Attach all other class to this qdisc and it will work like you want.  Trust 
me, I tried it a lot ;-)


Stef


-- 

stef.coene@docum.org
 More QOS info : http://docum.org/
 Title : "Using Linux as bandwidth manager"
     

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

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

[bert hubert]

On Sun, Dec 09, 2001 at 09:06:47PM -0800, Don Cohen wrote:

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

These are cbq's within cbq's, for which there is generally no need.

When specifying 'bandwidth' with qdisc add, it *must* be the bandwidth of
the physical interface, or when the cbq is embedded within another cbq (ie,
when using 'tc qdisc add dev eth0 parent' as opposed to 'tc qdisc add dev
eth0 root'), it should be the bandwidth available to the class you attach it
to.

Because that bandwidth may not be fixed, embedding cbq's within cbq's rarely
makes sense.

Specifying 'bandwidth' with 'tc class add' only makes sense when specifying
minburst or maxburst, and is ONLY used for calculating those two, when
specified. You can safely omit it in fact. *If* specifying it, I'm not sure
if it should be:

	o 	The rate of the parent class; or
	o	The bandwidth of the interface
 
>  > 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!

Maybe I should charge money. Do you see my point? 

Regards,

bert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
Trilab                                 The Technology People
Netherlabs BV / Rent-a-Nerd.nl           - Nerd Available -
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet

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

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

[Michael T. Babcock]

On Mon, Dec 10, 2001 at 07:47:01AM +0100, Stef Coene wrote:
> For the root qdisc this is indeed the physical link bandwidth.  But if you 
> attach a qdisc to a class, this is the rate of the class.  I suggest to 
> create a bounded class with rate = link bandwidth and attach a qdisc to it.  
> Attach all other class to this qdisc and it will work like you want.  Trust 
> me, I tried it a lot ;-)

And for those who haven't looked, read all the examples of Stef's site --
they will help you understand how the parameters interact.
-- 
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/