network perf : em driver ?

Alan Amesbury amesbury at umn.edu
Fri Jan 12 10:22:34 PST 2007


"R. B. Riddick" <arne_woerner at yahoo.com> wrote:

> --- Patrick Proniewski <patpro at 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


More information about the freebsd-performance mailing list