[lkml]   [2003]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Kernel tuning for high latency satellite link??
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
> <> 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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:33    [W:0.046 / U:2.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site