[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[altq 686] Re: interesting behavior
Thank you very much for comment, Kenjiro san.
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...
> > I guess the reason ATM application worked is because of the more
> > frequent (device?) interruption at C.
> It could be.
> Have you tried "options HZ=1000" in your kernel config file?
Yes, as it is mentioned in altq's manual, this configuration is
setup at altq enabled router.
> > It would be great if I can get some comment concerning this issue,
> > the reason why ATM application did not work when ALTQ was enabled
> > and why ATM application started working when interrupting UDP
> > data stream is started transporting.
>
> 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
I hope it could be a useful information.
Regards,
Nobuaki Takahashi
--
高橋伸明 taka@kaynet.ecc.u-tokyo.ac.jp
http://www.kaynet.ecc.u-tokyo.ac.jp/~taka/