From owner-freebsd-net@FreeBSD.ORG Mon May 8 23:23:30 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B902816A407 for ; Mon, 8 May 2006 23:23:30 +0000 (UTC) (envelope-from tpeixoto@widesoft.com.br) Received: from srv1.netconsultoria.com.br (srv1.netconsultoria.com.br [200.230.201.252]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0603B43D64 for ; Mon, 8 May 2006 23:23:27 +0000 (GMT) (envelope-from tpeixoto@widesoft.com.br) Received: from [192.168.0.1] (mailgw.netconsultoria.com.br [200.230.201.249]) by srv1.netconsultoria.com.br (8.13.6/8.13.3) with ESMTP id k48NN6I7017949; Mon, 8 May 2006 20:23:06 -0300 (BRT) (envelope-from tpeixoto@widesoft.com.br) Message-ID: <445FD2E3.8000900@widesoft.com.br> Date: Mon, 08 May 2006 20:23:15 -0300 From: tpeixoto@widesoft.com.br User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: .@babolo.ru References: <1146762831.921056.82828.nullmailer@cicuta.babolo.ru> In-Reply-To: <1146762831.921056.82828.nullmailer@cicuta.babolo.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.2/1450/Mon May 8 13:38:31 2006 on srv1.netconsultoria.com.br X-Virus-Status: Clean Cc: Lee Johnston , freebsd-net@freebsd.org, Julian Elischer , mihai@duras.ro Subject: Re: Packet loss with traffic shaper and routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2006 23:23:30 -0000 I guess traffic stops if you have pipe rules. In test 1, I did: ${fwcmd} pipe 1 config bw 512Kbit/s ${fwcmd} pipe 2 config bw 512Kbit/s ${fwcmd} add _allow_ all from any to any MAC any 00:11:22:33:44:55 in ${fwcmd} add _allow_ all from any to any MAC 00:11:22:33:44:55 any out x 1600 times. That caused lots of interrupts. Traffic was flowing although no shaping was done. Then, in test 2, with the same rules above, I just flushed the pipes: ipfw pipe flush The traffic was there, and the result is what I said in last post... "."@babolo.ru wrote: > [ Charset ISO-8859-1 unsupported, converting... ] >> Very good. You're right! >> I inserted a rule to match all non-layer2 packets on the top of the >> ruleset and interrupts dropped 10~20% immediately. >> Given that, I went to apply Julian's idea of grouping 'in' and 'out' >> pipe rules to reduce the searching on the firewall and that gave me a >> little bit more of performance. >> As interrupts were still hitting 60% mark, I did some more experiences: >> >> Test 1: I changed all 'pipe' rules to 'allow' rules, so all packets were >> allowed and no shaping was done. The pipes were still there, but there >> were no rules pointing packets to them. >> Result: No difference. Interrupts are the same as before. >> Conclusion: It's not the shaping itself that slows the system. >> >> Test 2: With the same ruleset of test 1, I just removed all pipes (ipfw >> pipe flush). > As far as I understand traffic stops after pipe flush, > and this is reason for CPU goes down > >> Result: Interrupts were only 20%! >> Conclusion: Lots of pipes bother the system. I didn't figure out why, >> but it's not a coincidence. I tested several times to make sure. >> [...]