Ignoramus26973 wrote:
> I installed a gigabit network switch and a gigabit enabled laptop wifi
> adapter (with gigabit, obviously, available on ethernet ports only) in
> my house.
>
> Two computers in my home are connected to the switch and one (laptop)
> to the wifi adaptor.
>
> The highest possible speed of a gigabit connection is about 111
> megabytes per second.
>
> Naturally, I did some tests with a noncompressible 1 gigabyte long
> file (fragment of some gzipped file exactly one GB long).
>
> My first test was to scp files from one computer on the switch to
> another. Here, I was disappointed as the highest speed was only 22
> megabytes per second one way and 46 another way. About 20 and 40
> percent of maximum.
>
> Then I tried using HTTP to transfer the same file (both computers are
> webservers). To my huge surprise, it made a world of difference and
> the transfer speed was 111 or so megabytes per second.
>
> So, now I have a dilemma, I have a fast pipe, but scp is not fast
> enough (given my CPU) to encrypt/decrypt so much data.
>
> I tried something else, which is doing wc -l on a NFS mounted drive
> (same two computers). It was UNBELIEVABLY slow and the load average on
> the NFS server shot WAY up. Transferring a 336 MB file took 157
> seconds, or about e megabytes per second (vs 111 mbps that I achieved
> with HTTP).

So, about 2.7 MB/s? :-)

>
> So, the conclusion is, HTTP is fast (no wonder), SSH is "medium",
> and NFS is "slow, very bad".

I ran into a similar problem with NFS ages back. Turns out you can
largely fix it by configuring NFS to increase the packet size. Been a
few years since I did anything with NFS, though, so you'll have to look
through the docs. I hear they use it in computer clusters, so it can't
be slow in *all* cases.

Around the same time, I also noticed that rsync can have similar speed
issues to SCP for a first copy, owing to it insisting on using SSH for RSH.