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.
Andrew
--On Saturday, 1 March 2003 10:58 a.m. -0500 Stephen Corey
<[email protected]> 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??
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
Andrew McGregor wrote:
> It should do OK by default, but you might want to read RFC 3150 for some
> ideas for things to do to help.
>
> Andrew
Testing I have done shows it will probably NOT be ok by default, especially
if you have any significant bandwidth on your satellite link. I would suggest
increasing the tcp_[rw]mem buffers at least.
Ben
--
Ben Greear <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
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
> <[email protected]> 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
What problems have you seen with PILC? And you're recommending setting
the send & receive maxes to (bandwidth (in bps) * delay (in
milliseconds))?
What problems have you seen with PILC? And you're recommending setting
the send & receive maxes to (bandwidth (in bps) * delay (in
milliseconds))?