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