[geeks] Network Slowness

[Doug McLaren]

On Thu, May 24, 2007 at 11:57:35AM -0400, Sridhar Ayengar wrote:

| Caleb Shay wrote:
| > I work for a company that makes network backup software for virtual
| > machines, I've done every test under the sun for checking network
| > throughput :)  You will almost never see more than 20 MB/s on
| > SSH/SCP/SFTP transfers, not matter how fast your media is.
| 
| Anyway, I'd be happy with 20MB/s.  I'm getting *5*.

Then try another protocol.  ftp, rsh/rcp, smb, etc.  The nc example
you were given is excellent -- it even removes disk I/O as a
bottleneck.

Don't blame the hardware or OSs until you've tried something that's
not encrypted.  They are absolutely right -- ssh can't keep up with
local network speeds, even on the fastest hardware.  This HPN SCP
stuff is interesting, though it looks like a lot of their speed
increase also comes from using the `none' encryption method (which
should greatly reduce cpu as a bottleneck.)

At home, between roughly 2 GHz Athlon machines with low end gigabit
ethernet cards ($6 Fry's specials!), cheap hub/switch ($30 Fry's
special, no jumbo frames, no special optimizations), etc. I see at
most about 20-30 MB/s transfer rates with things like rcp or smb.
Which isn't anywhere near the theoretical maximum, but it's still a
lot nicer than the 11-12 MB/s or so I get out of 100baseT.

If you've got dozens of GB to transfer on a local (i.e. somewhat
secure) network, it's often far faster to enable rsh and use it or rcp
just for that transfer than to use ssh.

   tar -cf - . | rsh host 'cd /foo ; tar -xpvvf -' 

can be a very fast way of moving lots of data to another box.  ssh is
a drop-in replacement for this, but it might be over an order of
magnitude slower.  `-c blowfish' helps, but doesn't totally resolve
the problem.

-- 
Doug McLaren, dougmc at frenzied.us
To envision how a 4-processor system running [SunOS] 4.1.x works, think
of four kids and one bathroom.                  -- John DiMarco