Re: Kernel tuning for high latency satellite link??

[Matti Aarnio]

On Sun, Mar 02, 2003 at 11:35:29AM +1300, Andrew McGregor wrote:
> On Saturday, 1 March 2003 10:58 a.m. -0500 Stephen Corey
>   <[e-mail]> wrote:
> >Do I need to tune the linux kernel (2.4.18-3) for high latency
> >connections? I'm installing a linux box on a satellite link (~800 ms
> >roundtrip latency). Will the kernel *automatically* change anything
> >based on latency, to hurt my throughput performance??
> 
> It should do OK by default, but you might want to read RFC 3150 for some 
> ideas for things to do to help.

PILC doesn't really help in all cases.
E.g. hight bandwidth * long delay does produce its own problems.

To achieve maximum performance from a tcp-stream,  you need to have
the amount of unacknowledge in-flight data matching that "delay-band-
width product".  In Linux, the   setsockopt() SO_SNDBUF parameter
must be TWICE that value.    Oh, and at the receiving side the
SO_RCVBUF parameter must have matching value.

System-wide default values are at   /proc/sys/net/core/*mem_*
See explanations at  "man 7 socket".  (In cases where application
does NOT set their own values, *mem_default  are used,  and in
all cases, *mem_max  clamp the upper limit.)

If you are pushing some half-duplex application traffic over this
kind of link where latency is longish, no amount of kernel tuning
can help you.   Example of such application protocol is SMTP.
There is  PIPELINING  mode,  which helps by turning SMTP into a semi-
duplex with full syncronization stops only at DATA or BDAT verbs.
However not all MTAs claiming PIPELINING capability in their EHLO-
responses implement it themselves in SMTP client code.
Most notable of those is qmail.

> Andrew

/Matti Aarnio