From owner-freebsd-performance@FreeBSD.ORG Fri Jan 12 18:22:34 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8E7316A416 for ; Fri, 12 Jan 2007 18:22:34 +0000 (UTC) (envelope-from amesbury@umn.edu) Received: from mta-a2.tc.umn.edu (mta-a2.tc.umn.edu [134.84.119.206]) by mx1.freebsd.org (Postfix) with ESMTP id 711E213C469 for ; Fri, 12 Jan 2007 18:22:34 +0000 (UTC) (envelope-from amesbury@umn.edu) Received: from [160.94.247.212] (paulaner.oitsec.umn.edu [160.94.247.212]) by mta-a2.tc.umn.edu (UMN smtpd) with ESMTP for ; Fri, 12 Jan 2007 12:07:33 -0600 (CST) X-Umn-Remote-Mta: [N] paulaner.oitsec.umn.edu [160.94.247.212] #+LO+TS+AU+HN Message-ID: <45A7CE64.4000800@umn.edu> Date: Fri, 12 Jan 2007 12:07:32 -0600 From: Alan Amesbury User-Agent: Thunderbird 1.5.0.9 (X11/20061222) MIME-Version: 1.0 To: freebsd-performance@freebsd.org References: <20070112120037.1797516A5DB@hub.freebsd.org> In-Reply-To: <20070112120037.1797516A5DB@hub.freebsd.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: network perf : em driver ? X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2007 18:22:34 -0000 "R. B. Riddick" wrote: > --- Patrick Proniewski wrote: >> I'll give FTP a try, but I would like the network to be fast for >> every protocols. I'm planning to share data using NFS, WebDAV, or SMB >> (and scp occasionally), but I've still to choose and configure >> appropriate servers. >> > We had that problem before: Some HTTP server implementations just dont bring > it... :-) thttpd is quite efficient, I have heard... > > You can try > 1. src/tools/tools/netrate/netblast > 2. increase MTU (ifconfig em0 mtu 65536 or so; never tried that myself) I don't think you want to do this, as *all* devices on the same network segment (layer 2) will have to use the same MTU for it to work safely and reliably. Besides, I think em(4)'s maximum MTU is 9216, so I don't think you *can* set an MTU that high. Again, if you're changing MTU, make sure that everything else on that same segment changes MTU as well. Besides, even with an MTU of 1500, a gigabit network should be able to beat 17MB/sec. > 3. ports/benchmarks/tcpblast > 4. build something with nc: > server: nc -l 1234 > /dev/null > client: dd if=/dev/zero bs=1m | nc serverIP 1234 > which will eliminate disk latency... I initially thought scp's encryption and compression overhead were possible sources of throughput problems, but Patrick (in his initial posting) said that scp is *faster* than HTTP. Since SMP is apparently involved, I'm wondering if this is related to the various em(4) problems noted earlier in a number of threads on -stable and -hackers. I'd suggest checking those for clues, particularly if SMP actually is being used. Polling may also help... or may not; I think it's dependent on the load and task at hand. -- Alan Amesbury OIT Security and Assurance University of Minnesota