[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CBQ vs. TBF





On Sun, 27 Feb 2000, Christopher E. Brown wrote:

> On Sun, 27 Feb 2000, Martin DEVERA wrote:
> 
> > >set up in most cases. Also, a few months ago, I tried to do exactly this,
> > >and got funny rates with CBQ (off by a factor of 2-3, I think).
> > 
> > 
> > yep, the same for me. Then I resolved that I set wrong bandwidth
> > for top level link .. Now it works rather well ..
> > Also can you please see my previous post (as I undestood, you
> > are current maintainer) ?
> > And one more question, why RTNETLINK is used for configuration
> > instead of procfs ? Use of procfs could make configuration much
> > easier (using subdirectories to express hierarchy). Are there any
> > cons ?

I am not sure if procfs would be a problem; however, RTNETLINK was
designed with the purpose of communicating with the kernel for these type
of applications  (aynchronous notification etc). The procfs display thats
there right now might be improved to make things look hierachical. 

> 	With correct bandwidth, weight, rate, maxburst, avpkt etc
> things seem to go correctly.  (maxburst out of sync with iface rate
> and wrong avpkt screws the calculations)
> 
> 	Another helpful item when doing small allocs (16Kbit -
> 256Kbit) on fast links (10 - 100 FD ethernet) is cranking the HZ value
> from 100 on X86 to 1024.  IIRC the QOS stuff does its control every
> HZ, by default, and every 10ms is not very often on a high rate
> interface so small allocs tend to go over.  HZ=1024 is every ~ 1ms
> (just under) instead of every 10ms.  I find this useful when I am
> doing service based controls, ie having say 1:4 being a 512Kbit
> class with different services going into 1:4 with a policed u32
> filter.
> 

A rule of thumb is as follows:
max achievable rate = size * maxburst * 8 * Hz

for a maxburst of 20; size of 1000 bytes; Hz 100 (10ms timer)
achievable rate =   1000*20*8*100 which equals 16Mbps;
increasing Hz to 1000 makes it 160Mbps
You can also up the maxburst; but what will happen is that you'll most
likely start seeing on-off burst as CBQ penalizes the flow for exceeding
its bandwith and on to allow it to send after some timeout.
Infact as you keep increasing maxburst you should see that you get bursts
of data going out at wire speed, then penalization by CBQ, then another
burst at wire speed etc
This should be a good exercise. Any volunteers?

Increasing Hz to 1Khz is probably Ok for machines >= pentium pros.

Increasing the packet size in the estimate will result in an
over-estimation if small packet sizes are the average seen. Vice-versa if
large packets are seen.
 
Note that in Linux however, the accuracy of the bandwidth measurement can
be improved by using a different clock source.

cheers,
jamal