From owner-freebsd-isp Sat May 16 16:17:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA24926 for freebsd-isp-outgoing; Sat, 16 May 1998 16:17:32 -0700 (PDT) (envelope-from owner-freebsd-isp@FreeBSD.ORG) Received: from lohi.clinet.fi (UNKNOWN@lohi.clinet.fi [194.100.0.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA24921 for ; Sat, 16 May 1998 16:17:29 -0700 (PDT) (envelope-from hsu@katiska.clinet.fi) Received: from katiska.clinet.fi (katiska.clinet.fi [194.100.0.4]) by lohi.clinet.fi (8.8.8/8.8.6) with ESMTP id CAA27580; Sun, 17 May 1998 02:17:13 +0300 (EEST) Received: (from hsu@localhost) by katiska.clinet.fi (8.8.8/8.8.6) id CAA22799; Sun, 17 May 1998 02:17:10 +0300 (EEST) To: Luigi Rizzo Cc: freebsd-isp@FreeBSD.ORG Subject: Re: Bandwidth limiter available References: <199805150331.FAA01765@labinfo.iet.unipi.it.newsgate.clinet.fi> From: Heikki Suonsivu Date: 17 May 1998 02:17:06 +0300 In-Reply-To: Luigi Rizzo's message of 15 May 1998 08:51:23 +0300 Message-ID: Lines: 42 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Luigi Rizzo 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