Re: [Nolug] Linux network optimizations

On Tue, Jan 25, 2011 at 8:45 PM, Lee S. Whatley <lee@whatley.org> wrote:
> On Jan 25, 2011, at 8:21 PM, Petri Laihonen wrote:
> I'm curious where you got these numbers from, specifically the 524K buffer
> size number.  Most of the things I've read on tcp/ip optimization suggest
> much larger numbers, like 16 or 32 MB (i.e. 16777216 versus 524288) for your
> buffer sizes.  Of course that is for 1Gb and 10Gb ethernet connections.  Are

I suppose if you really want 'optimal', you could cheat TCP like
Microsoft/Google.
You know... compile a custom kernel with altered slow start thresholds :)
http://blog.benstrong.com/2010/11/google-and-microsoft-cheat-on-slow.html

I would suggest maximal care with a small test sample size.
And always set net.ipv4.tcp_no_metrics_save=1
before trying to use repeated tests to analyze tunings (turning it
off when finished running tests; since the saving of metrics at
least if the saving of previous connections' metrics seems to help).

Some SCPs going faster might not be that great a measure of how well
TCP/IP is performing overall in your situation. Adjustments that
help in one situation may hurt in others; sometimes applications need
best latency, or fairness instead of highest throughput.

What is optimal buffering for TCP when one SCP transfer is running,
versus when there is congestion over a shared WAN with 10 file
transfers running some on localhost some on other hosts, can be quite
different.

SCP's performance with large files is often heavily influenced by the
cryptography overhead; try comparing against using Netcat to
send/receive. For network throughput tests I suggest a simpler
protocol such as FTP. For TCP latency tests, I suggest HTTP static
file load time [preferably with numerous small-sized static image
files], or DNS over TCP query response time.

In real world TCP stacks, these are all happening simultaneously, and
there can be congestion impacting short HTTP downloads as well

A good FTP client should have _much_ better buffering characteristics
for TCP testing, than anything transmitting over SSH, which has very
poor buffering characteristics -- SSH is great for interactive/CLI
usage, but not optimal in the slightest for file transfers.

If you want secure fast file transfers, either a good FTP over SSL
client/server pair, using RC4, or some other "fast" cipher, not 3DES
or AES; or (peferably) pre-encrypt.

The TCP stack and its defaults are not necessarily designed to
maximize apparent transfer rate at all costs. The same tunings
aren't optimal for all situations; Linux TCP stack is highly tunable,
you can pick tcp_congestion_control algorithm; and tcp_frto for
wireless connections, plus thousands of other options..

--
-JH
___________________
Nolug mailing list
nolug@nolug.org