From owner-freebsd-stable@FreeBSD.ORG Thu Oct 5 16:14:07 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D6DF16A47B for ; Thu, 5 Oct 2006 16:14:07 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.200.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id C056B43D5D for ; Thu, 5 Oct 2006 16:14:00 +0000 (GMT) (envelope-from jdc@koitsu.dyndns.org) Received: from icarus.home.lan (c-67-174-220-97.hsd1.ca.comcast.net[67.174.220.97]) by comcast.net (sccrmhc13) with ESMTP id <200610051608190130047hnke>; Thu, 5 Oct 2006 16:08:19 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 75C721FA039; Thu, 5 Oct 2006 09:08:19 -0700 (PDT) Date: Thu, 5 Oct 2006 09:08:19 -0700 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20061005160819.GA13417@icarus.home.lan> Mail-Followup-To: freebsd-stable@freebsd.org References: <4523764E.3070309@ant.uni-bremen.de> <45252483.5040708@ant.uni-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45252483.5040708@ant.uni-bremen.de> X-PGP-Key: http://jdc.parodius.com/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Re: NFS client slow on amd64 6.2-PRERELEASE #2 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, 05 Oct 2006 16:14:07 -0000 On Thu, Oct 05, 2006 at 05:28:03PM +0200, Heinrich Rebehn wrote: >root@antsrv1 [/tmp] # time dd if=/dev/zero of=/mnt/x/10MB.dat bs=1M count=10 >10485760 bytes transferred in 4.967248 secs (2110980 bytes/sec) > >root@antsrv1 [/tmp] # time dd if=/dev/zero of=/mnt/x/100MB.dat bs=1M count=100 >104857600 bytes transferred in 69.020366 secs (1519227 bytes/sec) > >root@antsrv1 [/tmp] # time dd if=/dev/zero of=/mnt/x/10MB.dat bs=1M count=10 >10485760 bytes transferred in 5.289492 secs (1982376 bytes/sec) > >root@antsrv1 [/tmp] # time dd if=/dev/zero of=/mnt/x/100MB.dat bs=1M count=100 >104857600 bytes transferred in 58.715595 secs (1785856 bytes/sec) This isn't a valid test of performance, in my opinion. bs=1M is a bad idea. You shouldn't be using dd for this kind-of test at all. I should also note that bs=1M is not the same thing as obs=1M ibs=1M. dd's weird like that (someone can explain it, I'm sure -- I've seen it discussed in the pasT). scp is an ""acceptable"" real-life test (not the best, but it's legitimate), and you only did it from antsrv1 --> antsrv2, not the other direction. It's really too bad the OpenBSD guys refuse to incorporate the HP (high-performance) patches into OpenSSH, and being able to say "-c none" would *really* help when it comes to benchmarking network I/O via scp (in our case, we do dump over ssh across a segregated private LAN -- the encryption overhead slows our backups down to a crawl, and is worthless in our environment since as I said, segregated private LAN...) That said: I have seen cases where network peformance on BSD works fantastic uni-directionally -- for example, using FTP to "get" a file from a FreeBSD box on a 100mbit LAN results in a speed of about 300-400kbit/sec, while doing a "put" to the same box results in 90mbit/sec. The problem in that case turned out to be duplex-related. Both boxes were auto-negotiating with the Cisco switch correctly, and indeed the Cisco labelled them as auto-100/full, but as anyone who is familiar with Ciscos knows, auto-negotiation on Catalysts is far from reliable. Both boxes reported auto-neg and being at 100/full as well. I ended up hard-setting the boxes to use 100/full, and set the switch ports to 100/full, then rebooted both boxes (yes, this is sometimes required, as driver auto-neg code is a bit tweaky); voila, problem fixed. If you can connect these two boxes directly via a crossover cable, and you still see the problems, then yes, there's something definitely amiss that needs investigating. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |