From owner-freebsd-ipfw@FreeBSD.ORG Thu Mar 5 18:58:33 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62E34106564A for ; Thu, 5 Mar 2009 18:58:33 +0000 (UTC) (envelope-from sebastian.mellmann@net.t-labs.tu-berlin.de) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by mx1.freebsd.org (Postfix) with ESMTP id E845E8FC17 for ; Thu, 5 Mar 2009 18:58:32 +0000 (UTC) (envelope-from sebastian.mellmann@net.t-labs.tu-berlin.de) Received: from [192.168.1.2] (g225034230.adsl.alicedsl.de [92.225.34.230]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 7BA24700D493; Thu, 5 Mar 2009 19:58:31 +0100 (CET) Message-ID: <49B020D8.8070502@net.t-labs.tu-berlin.de> Date: Thu, 05 Mar 2009 19:58:32 +0100 From: Sebastian Mellmann User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ian Smith References: <49AED3B1.1060209@net.t-labs.tu-berlin.de> <20090305124242.P71460@sola.nimnet.asn.au> <36832.62.206.221.107.1236237708.squirrel@anubis.getmyip.com> <20090306033309.J71460@sola.nimnet.asn.au> In-Reply-To: <20090306033309.J71460@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw (dummynet) adds delay, but not configured to do so X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 18:58:33 -0000 > > > Also, without using a separate pipe for either traffic direction, you're > > > using 'half-duplex' mode, as well described in ipfw(8) TRAFFIC SHAPING. > > Paired pipes will speed things up. Maybe not noticeably for pings (call > and response work half-duplex) but for esp TCP it could be considerable. > > How does this "pairing" of pipes work? Couldn't find any documentation about it. > > > Output of 'sysctl net.inet.ip.fw.one_pass' and 'ipfw show' with your > > > example of using multiple pipes? > > > > [root@ ~/ipfw]# sysctl net.inet.ip.fw.one_pass > > net.inet.ip.fw.one_pass: 0 > > > > [root@ ~/ipfw]# ipfw show > > 00010 0 0 allow ip from any to any via lo0 > > 10000 122 11832 allow ip from any to any via em2 > > 10100 0 0 pipe 100 ip from 192.168.5.0/26 to 192.168.7.0/24 in via em0 > > 10200 0 0 pipe 200 ip from 192.168.7.0/24 to 192.168.5.0/26 out via em0 > > 10300 342 28728 pipe 500 ip from any to any via em0 > > 10400 359 36512 pipe 510 ip from any to any via em1 > > 10500 0 0 pipe 300 udp from 80.80.80.1 to 60.60.60.1 src-port 4000 dst-port 4000 via em1 > > 10600 0 0 pipe 305 udp from 60.60.60.1 to 80.80.80.1 src-port 4000 dst-port 4000 via em0 > > 10700 0 0 pipe 310 udp from 80.80.80.1 to 60.60.60.1 src-port 4001 dst-port 4001 via em1 > > 10800 0 0 pipe 315 udp from 60.60.60.1 to 80.80.80.1 src-port 4001 dst-port 4001 via em0 > > 65535 14144748 9784372451 allow ip from any to any > > A note of caution: using 'via' unqualified can be tricky; 'via em0' on > the inbound pass is the same as 'in recv em0', but 'via em0' on the > outbound pass includes packets that came IN on em0 but are going out on > any interface, as well as those that came in on any interface that are > going OUT on em0. I prefer specifying 'in recv' and 'out xmit' where > there might be any ambiguity; this usually works naturally with pipes, > where you'd normally have one pipe per flow direction anyway. > > Actually I'm using 'in recv' and 'out xmit', but it wasn't applied in this example, but thanks for the hint again (you already mentioned that on the freebsd-question mailing list I think ;-)). > Hopefully increasing kern.hz solves your main issue, and worth trying > the new! net.inet.ip.dummynet.io_fast too. Let us know your results? > > For now we will stick to the delay "issue" and see how it affects our results. > cheers, Ian > Regards, Sebastian