(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/
