network perf : em driver ?
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
> 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.
OIT Security and Assurance
University of Minnesota
More information about the freebsd-performance