From: bert hubert <ahu@ds9a.nl>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Anti-CBQ Statements in Howto
Date: Thu, 06 Dec 2001 21:01:29 +0000 [thread overview]
Message-ID: <marc-lartc-100767254506635@msgid-missing> (raw)
In-Reply-To: <marc-lartc-100767069231496@msgid-missing>
On Thu, Dec 06, 2001 at 03:30:47PM -0500, Michael T. Babcock wrote:
> I find the negative attitude toward CBQ to be distracting and
> non-professional in the HOWTO. I've re-read it for the first time in
> about a month and comments like "This can be configured in a variety of
> ways, which I do not understand. Use HTB" do not encourage me about the
> writer.
There is exactly one place that says 'use HTB :-)'. But I will remove it.
> This is not a personal critique, as I can imagine this being said on a
> personal website, but as a generic HOWTO, this is out of place. A
> statement like "if you don't understand these options, you may find HTB
> to be easier to follow" is professional and possibly more accurate.
Well, there are a lot of reasons why CBQ may not fit your needs. I really
want to downplay the 'holy grail' status it has achieved. New text:
You may wonder what happens to traffic that is not classified by any
of the two rules. It appears that in this case, data will then be
processed within 1:0, and be unlimited. The unfiltered behaviour can
be configured in a variety of ways, which have not yet been
documented adequately. HTB is clearer in this respect, so you may
prefer it.
> I've seen other documents that describe the options the author says he
> doesn't understand whose authors like CBQ and/or believe it to be
> well-designed. I've had no real problems with it and don't actually
Read linux/net/sched/sch_cbq.c for some enlightenment.
> see HTB as being easier to configure or follow if you leave the 'knobs'
> on CBQ to their suggested defaults.
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.
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.
Anyway, 'use HTB :-)' may indeed not be appropriate and has been changed,
thanks.
Regards,
bert hubert
--
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
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/
next prev parent reply other threads:[~2001-12-06 21:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-06 20:30 [LARTC] Anti-CBQ Statements in Howto Michael T. Babcock
2001-12-06 21:01 ` bert hubert [this message]
2001-12-06 21:17 ` Michael T. Babcock
2001-12-06 22:58 ` bert hubert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-lartc-100767254506635@msgid-missing \
--to=ahu@ds9a.nl \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox