From: "Michael T. Babcock" <mbabcock@fibrespeed.net>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Anti-CBQ Statements in Howto
Date: Thu, 06 Dec 2001 21:17:10 +0000 [thread overview]
Message-ID: <marc-lartc-100767363111235@msgid-missing> (raw)
In-Reply-To: <marc-lartc-100767069231496@msgid-missing>
(Warning: long reply ...)
On Thu, Dec 06, 2001 at 10:01:29PM +0100, bert hubert wrote:
> There is exactly one place that says 'use HTB :-)'. But I will remove it.
I decided to use the exact quote as an example, but I'm glad you
understood what I meant.
> 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.
I can understand that feeling, but CBQ hasn't necessarily achieved holy grail
status among those people who would first approach the HOWTO having never
done traffic shaping at all before. Many of those working with Linux traffic
shaping may or may not have come from Cisco, etc. backgrounds, but I for one
simply started with Linux's offerings in 2.2.x and worked from there.
> 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?
> 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.
I have sold those clients exact rates of bandwidth and allow full sharing
of the available bandwidth when it is available and prioritise traffic
to and from servers, especially interactive traffic, and specify different
rates for each customer to and from our servers vs. to and from the Internet.
I measure the effects with RRDTool as per a script I've sent a couple of
other people for review and have had pretty good results from what I can see
and the clients have not complained of getting less than what they should,
nor is my current remote SSH session lagged at all.
> 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.
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.
--
Michael T. Babcock
CTO, FibreSpeed Ltd. (Hosting, Security, Consultation, Database, etc)
http://www.fibrespeed.net/~mbabcock/
_______________________________________________
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:17 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
2001-12-06 21:17 ` Michael T. Babcock [this message]
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-100767363111235@msgid-missing \
--to=mbabcock@fibrespeed.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.