Date: Fri, 12 Jan 2007 12:07:32 -0600 From: Alan Amesbury <amesbury@umn.edu> To: freebsd-performance@freebsd.org Subject: Re: network perf : em driver ? Message-ID: <45A7CE64.4000800@umn.edu> In-Reply-To: <20070112120037.1797516A5DB@hub.freebsd.org> References: <20070112120037.1797516A5DB@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
"R. B. Riddick" <arne_woerner@yahoo.com> wrote: > --- Patrick Proniewski <patpro@patpro.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45A7CE64.4000800>