From owner-freebsd-performance@FreeBSD.ORG Wed Jun 11 16:37:58 2003 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4349737B401 for ; Wed, 11 Jun 2003 16:37:58 -0700 (PDT) Received: from sherryl.salk.edu (sherryl.snl.salk.edu [198.202.70.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CFC843FBF for ; Wed, 11 Jun 2003 16:37:55 -0700 (PDT) (envelope-from cadams@salk.edu) Received: from malacarne.salk.edu (malacarne.snl.salk.edu [198.202.70.215]) by sherryl.salk.edu (8.12.9/8.12.9) with ESMTP id h5BNbrMw041728 for ; Wed, 11 Jun 2003 16:37:53 -0700 (PDT) Received: from cadams by malacarne.salk.edu with local (Exim 3.35 #1 (Debian)) id 19QFAB-0005tJ-00 for ; Wed, 11 Jun 2003 16:37:55 -0700 Date: Wed, 11 Jun 2003 16:37:55 -0700 To: freebsd-performance@freebsd.org Message-ID: <20030611233755.GA22453@salk.edu> References: <3EE4E156.6030603@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EE4E156.6030603@centtech.com> User-Agent: Mutt/1.5.4i From: Chris Adams Subject: Re: Slow disk write speeds over network X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2003 23:37:58 -0000 On Mon, Jun 09, 2003 at 02:34:46PM -0500, Eric Anderson wrote: > However, ftping a file or cp'ing over NFS shows speeds less than 1MB/s - > which is not what I would expect - it's got gigabit ethernet, and has > very fast read times (via ftp or nfs) over the network. Silly question - how are the switch ports configured? I'd try toggling it from whatever it it is now. We've seen some similar sounding problems with Intel NICs and Cisco switches where either auto or forced port settings will cause extremely slow transfers without causing any errors on either end. It's card/port specific, too, as we've seen cases where allegedly identical hardware must be configured as the opposite of its "twin". Chris