Skip site navigation (1)Skip section navigation (2)
Date:      17 May 1998 02:17:06 +0300
From:      Heikki Suonsivu <hsu@clinet.fi>
To:        Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Cc:        freebsd-isp@FreeBSD.ORG
Subject:   Re: Bandwidth limiter available
Message-ID:  <x23ee9u7pp.fsf@katiska.clinet.fi>
In-Reply-To: Luigi Rizzo's message of 15 May 1998 08:51:23 %2B0300
References:  <199805150331.FAA01765@labinfo.iet.unipi.it.newsgate.clinet.fi>

next in thread | previous in thread | raw e-mail | index | archive | help

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.

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.

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.

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?x23ee9u7pp.fsf>