[altq 687] Re: interesting behavior

[Kenjiro Cho <kjc@csl.sony.co.jp>]

Nobuaki Takahashi wrote:
> On Wed, 10 Jan 2001 14:19:55 +0900
> Kenjiro Cho <kjc@csl.sony.co.jp> wrote:
> > Nop.  def_class can also use 95Mbps in this setting.
> > You should set udp_class as a child of root_class to prevent def_calss
> > from stealing the bandwidth assigned to udp_class.
> 
> I tried to use modified configuration file according to above
> comment. The new configuration file:
> ==================
> interface xl1 bandwidth 100M cbq
> class cbq xl1 root_class NULL pbandwidth 100
> class cbq xl1 udp_class root_class borrow pbandwidth 95 default
>         filter xl1 udp_class 192.168.3.2 0 0 0 17
> ==================
> 
> ... and I have found that when this configuration file is used,
> the ATM application did not work where it worked with the old
> configuration file. I cannot understand this behavior...

You should not make udp_class as default.
What I meant was something like:
===========================================================
interface xl1 bandwidth 100M cbq
class cbq xl1 root_class NULL pbandwidth 100
class cbq xl1 def_class root_class borrow pbandwidth 10 default
class cbq xl1 udp_class root_class pbandwidth 80
	filter xl1 udp_class 192.168.3.2 0 0 0 17
===========================================================

> > As usual, I need altqstat output for further analysis.
> 
> I retrieved altqdstat result when ATM application works and when
> it does not work. Since the data file seems to be a big for casting
> for mailing list, I located it onto a web server.
> 
> Result of when it works is:
> http://www.kaynet.ecc.u-tokyo.ac.jp/~taka/temp/ok
> Result of when it does not work is:
> http://www.kaynet.ecc.u-tokyo.ac.jp/~taka/temp/dame

Comparing these outputs, the problem seems to be bursty transmission
by the sender (coupled with the timer granularity of CBQ).

The "delays" field indicates that udp_class gets suspended several
times in the NG case but it is never suspended in the OK case.
When there's no competing traffic, a burst of packets are transmitted
and exceeds the assigned rate for a short time period, even though the
average rate is 30Mbps for a longer time period. 
When there's competing traffic, a burst becomes smoother since
competing traffic is interleaved.

You can try
 - shape packets at the sender
and/or
 - make udp_class more burst-tolerant by increasing "maxburst"

-Kenjiro