Re: [LARTC] Anti-CBQ Statements in Howto

Linux Advanced Routing and Traffic Control

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

 



On Thu, Dec 06, 2001 at 04:17:10PM -0500, Michael T. Babcock wrote:

> > Read linux/net/sched/sch_cbq.c for some enlightenment.
> 
> The first thing I did with the 2.2.x kernels was read most of the source for
> most of the sch_*.c files I found interesting along with a couple of 
> co-workers to understand what they were doing.  That makes me a techie and
> probably not a typical user ... but that's ok, right?

Yeah, but I specifically mean comments from Alexey himself about CBQ in
Linux:

        --- It seems that cbq-2.0 is not very accurate. At least, I cannot
        interpret some places, which look like wrong translations
        from NS. Anyone is advised to find these differences
        and explain to me, why I am wrong 8).

        --- Linux has no EOI event, so that we cannot estimate true class
        idle time. Workaround is to consider the next dequeue event
        as sign that previous packet is finished. This is wrong because of
        internal device queueing, but on a permanently loaded link it is
	true.
        Moreover, combined with clock integrator, this scheme looks
        very close to an ideal solution.  */

> > If you see CBQ working well, you are probably on an empty 10 or 100mbit
> > segment, talking directly to the switch, or using a plain-old-modem with a
> > fixed bitrate. In other cases, CBQ is 'saved' because it actually contains
> > token bucket filters, which ARE pretty accurate.
> 
> Actually, I've got a 10/100 switch attached to three servers, four ethernet
> clients and a gateway that is on a fibre optic link to the Internet with
> a backup cable modem for web traffic (like A/V streaming) and one dial-in
> customer who expects to get snappy response on their 33k6 modem.

So you fall into the 'CBQ should work well' category. 

> > CBQ relies on being dequeued at a well known rate, which is simply not
> > always the case. Furthermore, often there is no 'well known rate', for
> > example when using a PPP-over-Ethernet modem over a userspace socket.
> 
> I'm sure this is a common case for some users, but its hasn't been something
> I've had to deal with, thus my lack of empathy.

Well, I decided to get to the bottom of this due to the relatively large
number of 'CBQ doesn't work!' complaints I receive.

> PS, I do appreciate the HOWTO and the help its been.  If I may make another
> suggestion though, having links to external ressources from within the HOWTO
> sections might be useful -- descriptions of how RED and SFQ work according
> to people who've done masters work with them and/or designed them are online
> in PDF and other formats which I've found quite enlightening for knowing how
> these things ought to work.

If you have good links, I would be very happy to receive them! I don't need
to invent the wheel, if good stuff is available, I want to link it.

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



[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux