[2472] in linux-net channel archive
Re: PPP is slow (and so is TCP!) [with fixes]
daemon@ATHENA.MIT.EDU (roque@di.fc.ul.pt)
Fri Apr 12 14:13:34 1996
To: Eric Schenk <schenk@rnode84.cs.toronto.edu>
Cc: linux-net@vger.rutgers.edu, netdev@nuclecu.unam.mx
Reply-to: roque@di.fc.ul.pt
From: roque@di.fc.ul.pt
In-reply-to: Your message of "Fri, 12 Apr 1996 02:52:07 EDT."
<199604120652.CAA00272@rnode84.cs.toronto.edu>
Date: Fri, 12 Apr 1996 18:37:20 +0200
>>>>> "Eric" == Eric Schenk <schenk@rnode84.cs.toronto.edu> 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]
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
Eric> There are two possible fixes: (1) Every time a character
Eric> gets taken out of the receive buffer send an ACK to the
Eric> other side informing them that the receive window has
Eric> changed.
Eric> (2) Assume that packets with the PSH flag set are
Eric> part of an interactive connection, and don't delay ACKs for
Eric> these packets.
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.
regards,
Pedro.
