Date: Fri, 11 Sep 1998 17:24:04 +0200 From: Andre Oppermann <oppermann@pipeline.ch> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: dennis@etinc.com, mike@smith.net.au, ulf@Alameda.net, hackers@FreeBSD.ORG Subject: Re: Packet/traffic shapper ? Message-ID: <35F94094.EF55F5A8@pipeline.ch> References: <199809111311.PAA19937@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo wrote: > > > > I suppose that you mean "the 2 best free solutions"? > > > > No, until you give me more technically detailed description of your > > BW manager product. > > well still it is not a free solution so the comment is correct :) > >From what i have read about the Etinc product (and i'll be happy > to be corrected), it does something very similar to the > bandwidth-management part of dummynet, plus comes with support > being commercial software. *Smile*... I recall some threads here on this lists about the quality of that support... Some have been very satisfied, some not... I don't know... I don't have any Etinc products... Anyway, I'm happy with the non-commercial support of FreeBSD! The only sad thing is that the recent "TCP disconnect" (I don't know the name yet) from BUGTRAQ still hasn't been solved... > > What I look for is an alternative for the standard FIFO queueing > > currently done in the BSD IP stack. You might know that bandwidth > > is quite expensive here in Europe and I'd like to drive my links > > up to 90% utilization. That is only possible if I have something > > like RED that does fair queueing on the FreeBSD routers, otherwise > > ALTQ might be for you then. In fact RED+WFQ would be not hard to I know, thats why I want it in 3.0-R. > port to dummynet (and it is in my todo list but not at the top), > and the bw limiting of dummynet could be ported even more easily > to ALTQ, but there is one little difference between ALTQ and > dummynet: > > * ALTQ replaces the queueing management at the interface level, > so it has more feedback from the interface, at the price of having > to modify/recompile each driver. Thats exactly what I want; queueing management on the interface level. If I look at the README of ALTQ it seems not so hard to adjust the drivers to use ALTQ. > * dummynet works at a higher level so the bandwidth is configured > "statically" and you can have queueing underneath. The advantage is > that you don't have to recompile the drivers, dummynet works even > on a ppp link. OK, but thats a different animal IMHO. I don't want to give traffic priorities, just fair queueing... > I have to say that if your machine is not directly on the bottleneck > link, or such link has constant bandwidth (e.g. does not use > compression etc.) then the difference is irrelevant apart from long > term drifts (but you can easily correct them). Term drifts? > It remains as a fact that, as it is now, ALTQ implements WFQ and RED, > whereas dummynet does not. And I think ALTQ can be extended and combined with the recent NetBSD ARP layer changes to give us a really nice networking framework. I'd love to do all that coding and documenting but I'm not yet on that level of understanding of the code and my time limited at the moment. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35F94094.EF55F5A8>