[2512] in linux-net channel archive
Re: PPP is slow (and so is TCP!) [with fixes]
daemon@ATHENA.MIT.EDU (Eric Schenk)
Mon Apr 15 17:02:33 1996
To: roque@di.fc.ul.pt
cc: linux-net@vger.rutgers.edu, netdev@nuclecu.unam.mx
In-reply-to: Your message of "Fri, 12 Apr 1996 12:37:20 EDT."
<199604121737.SAA14629@oberon.di.fc.ul.pt>
Date: Mon, 15 Apr 1996 14:25:37 -0400
From: "Eric Schenk" <schenk@cs.toronto.edu>
roque@di.fc.ul.pt <roque@di.fc.ul.pt> writes:
> Eric> It turns out that the slow interactive performance is caused
> Eric> by the correct application of the Nagle algorithm on the
> Eric> senders side. The problem is that the Nagle algorithm
> Eric> requires that the send not send the next character until it
> Eric> gets the ack for the previous one. Since ACKs are delayed
> Eric> this really slows down the arrival of the response to
> Eric> interactively typed characters.
>
>Are you sure this was the problem ?
>
>Typical interactive session:
>
>client -> char
> echo char <- server
>client -> char [acks echo]
I wasn't precise enough in my diagnosis. The problem is that our
delay for delayed ACK's is way to high. If we remove delayed
ACK's then the interactive performance problem goes away completly.
>this means that ACKs should be delayed for an interactive session.
>They must not be delayed when the connection starts to
>progress after beeing stoped, that's the reason for the ack < HZ/2 test
>I realy don't agree with you. Because interactive sessions are where you
>gain more by having delayed acks since you can achieve a near to ackless
>connection.
It seems that a delay of HZ/2 is very noticable in typing.
However, as you point out, it is not a good idea to get rid of delayed
ACK's all together.
Looking at how the values of ato we are generating over a 14.4KBps
PPP link, I'm finding that the delay ranges from about a 1/4 second
up to over 1/2 second. This is still pretty noticable.
Reading over RFC 813 again, it seems to me that what we want to do
is measure the average time between the receipt of a packet with
data, and the next packet with data that we send.
I've implemented a first stab at this, which samples the time
between recv and send events, and feeds it into an exponential
decay function of: 7/8 * old + new.
I've also set things up so that delays of longer than HZ/2 are not
sampled, and the minimum delay is set to 1/50 second.
It is possible that this should be changed to limit inputs to
the sampling function to a maximum of HZ/2 rather than discarding
the data.
In my testing this seems to give ACKless connections, both over
the loopback interface and over PPP connections, provided that
the typing rate is smooth.
However, it seems to me that this is still a bit of the "wrong thing" to do,
since my current implementation will result in zero delay on ACKs
when a socket is only receving data. Probably I should also sample
consecutive receive events without an intervening send.
Anyone have comments/references on what the "right" way to do this is?
Does this scheme make sense? I'd like to get this right.
-- eric
---------------------------------------------------------------------------
Eric Schenk www: http://www.cs.toronto.edu/~schenk
Department of Computer Science email: schenk@cs.toronto.edu
University of Toronto
