Date: Sat, 16 May 1998 19:26:52 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: Heikki Suonsivu <hsu@clinet.fi> Cc: Luigi Rizzo <luigi@labinfo.iet.unipi.it>, freebsd-isp@FreeBSD.ORG Subject: Re: Bandwidth limiter available Message-ID: <Pine.BSF.3.95.980516191858.17001C-100000@current1.whistle.com> In-Reply-To: <x23ee9u7pp.fsf@katiska.clinet.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
On 17 May 1998, Heikki Suonsivu wrote:
>
> Luigi Rizzo <luigi@labinfo.iet.unipi.it> writes:
> > I do think that ALTQ is a more complete package. On the other hand,
> > the advantages of dummynet are, in my opinion, the following:
> ...
> > * device-indipendent, since it works at the IP level; ALTQ
> > works at a lower level so it needs to be aware of the interface
> > (and this could be a problem in some cases).
>
> This could be fixed in various ways, either by creating better device
> driver interface or adding extra layer (this would need simple
> modifications to devide driver interface to get a good result).
>
> > * uses ipfw for packet filtering, which makes it easier to configure
> > things (for those already familiar with ipfw). Also, it might save
> > some work since classification is done once both for queueing and
> > firewalling purposes.
>
> It may be easy to use, but ipfw is too inefficient implementation for this
> use. We used a single dedicated P150 to do byte counting for about 400
> networks, totalling of 800 ipfw lines (one for incoming traffic, one for
> outgoing traffic). Even with a slow 2M line the P150 run out of CPU. The
> host was doing nothing else but byte-counting, no fancy queueing, bandwidth
> limiting or like.
I have a change to IPWF that will allow this to be improved radically.
by making the SKIPTO much more efficient you will be able to
(you already can do this but it's less efficient) use a decision tree to
reduce the number of tests to do against each packet..
(theoretically about 32 would be the maximum..)
teh alternative is to do what WE intend to do which is to
finish off (I will be doing this next week)
the TEE rule type and use a process with an efficient radix tree
implementation to do the counting off-line.
>
> There has to be better address-matching code than a linear list. In
> particular this is bad because you want to do per IP matching and various
> IP parameters (type of service field in particular!).
>
> Another serious problem with ipfw is that all packets are processed
> independent of the interface used, which makes the performance problem
> worse. Instead of having 10 lists processed for each packet on each
> interface goes through, all packets go through 100 lists on 10-port router,
> only 10-20 of the lists being actually necessary to match.
You can split it to 10 diferent lists using different rule number ranges
and the skipto command in the first 10 lines.
skipto is at present not very efficient, however as I said above.
that is abount to change.
(however it is still more efficient than processing all the rules between
where you are and the desired rule#)
>
> We are using Cisco custom queuing to get some sort of approximation of
> different service quality per each customer, but it is damn expensive
> equipment for that simple purpose and has some of the problems of ipfw.
stay tuned.. :-)
>
> --
> Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@clinet.fi
> mobile +358-40-5519679 work +358-9-43542270 fax -4555276
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-isp" in the body of the message
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.980516191858.17001C-100000>