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/
