From owner-freebsd-stable@FreeBSD.ORG Thu Jun 12 09:21:24 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CC921065686 for ; Thu, 12 Jun 2008 09:21:24 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id AB4458FC1A for ; Thu, 12 Jun 2008 09:21:23 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id m5C9LKXi027879; Thu, 12 Jun 2008 11:21:21 +0200 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 47B114F; Thu, 12 Jun 2008 11:21:20 +0200 (CEST) Date: Thu, 12 Jun 2008 11:21:20 +0200 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: pyunyh@gmail.com Message-Id: <20080612112120.d1b8d059.gerrit@pmp.uni-hannover.de> In-Reply-To: <20080612070126.GF7250@cdnetworks.co.kr> References: <20080527165232.2acbb00f.gerrit@pmp.uni-hannover.de> <3C916EEA-5A2B-4C88-B834-0F47D7D525FA@gmail.com> <20080611092457.82c83083.gerrit@pmp.uni-hannover.de> <20080612032228.GD7250@cdnetworks.co.kr> <20080612085810.072d705d.gerrit@pmp.uni-hannover.de> <20080612070126.GF7250@cdnetworks.co.kr> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.6.12.20531 Cc: freebsd-stable@freebsd.org Subject: Re: broken re(4) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2008 09:21:24 -0000 On Thu, 12 Jun 2008 16:01:26 +0900 Pyun YongHyeon wrote about Re: broken re(4): PY> > I already did simple benchmarking by using "dd if=/dev/zero PY> > of=file" which gave me several 10s of MByte/s under all PY> > circumstances. Can you recommend one of the benchmarking programs PY> > for more detailed testing? PY> Try netperf or iperf in ports/benchmark. The machine in question as client: ------------------------------------------------------------ Client connecting to 130.75.117.1, TCP port 5001 TCP window size: 32.5 KByte (default) ------------------------------------------------------------ [ 3] local 130.75.117.112 port 56513 connected with 130.75.117.1 port 5001 [ 3] 0.0-10.0 sec 211 MBytes 177 Mbits/sec On the server side: ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 64.0 KByte (default) ------------------------------------------------------------ [ 4] local 130.75.117.1 port 5001 connected with 130.75.117.112 port 56513 [ 4] 0.0-10.3 sec 211 MBytes 172 Mbits/sec As server: ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 64.0 KByte (default) ------------------------------------------------------------ [ 4] local 130.75.117.112 port 5001 connected with 130.75.117.1 port 53843 [ 4] 0.0-10.1 sec 399 MBytes 331 Mbits/sec On the client side: ------------------------------------------------------------ Client connecting to 130.75.117.112, TCP port 5001 TCP window size: 32.5 KByte (default) ------------------------------------------------------------ [ 3] local 130.75.117.1 port 53843 connected with 130.75.117.112 port 5001 [ 3] 0.0-10.1 sec 399 MBytes 331 Mbits/sec Hm, being a server seems to work better? The machine on the other side is also having a re-interface and usually transfers data with 20-30MByte/s. The ITX machine I'm testing is using both of it's re-interfaces in a lagg-configuration right now (laggproto loadbalance). Is this the expected performance? cu Gerrit