lkml.org 
[lkml]   [1996]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: 1.3.87 and SLOW SLIP/PPP
Date
>>>>> "Linus" == Linus Torvalds <torvalds@cs.helsinki.fi> writes:


Linus> The 1.3.87 patch does something experimental: it does delay
Linus> ack's for "psh" packets, but the delay is shorter than
Linus> usual (0.1 sec instead of 0.5 sec). That helps the Nagle
Linus> rule on the other side to coalesce packets as appropriate
Linus> if there are more writes soon afterwards, but on the other
Linus> hand it might still be noticeable in for a fast typist that
Linus> expects to see the characters one by one.

Linus> Somebody (Alan?) said that BSD doesn't delay at all for
Linus> those kinds of packets, but that might be due to a
Linus> inflexible delayed ack setup rather than any real technical
Linus> reason.

Linus,
Delayed acks are usefull in two conditions:

a) bulk trafic

In bulk trafic the receiver can avoid sending one ack per packet
if it expects the sender to be sending consecutive fragments
very fast. However this is tricky because acks are the clocking
and rate controling mechanism of TCP. That's why RFC 1122
demands implementations two ack every two packets in a full
window. Also note that reducing acks you are reducing the sampling
rate for the rtt calculation and consequently the acuracy of
the rto. Personaly i couldn't find references anywhere for the
"every 2 packets per window" rule. Since the factors involved are
very complex i guess this was a conservative extimate.
But as bottom line: in bulk trafic the receiver can gain if it
delays acks however it must be realy carefull about them.

b) interactive trafic

This one is the easy one. On a interactive session you *should*
use delayed acks. On the server side, every time you receive
a packet the app is going to reply right away echoing the char.
If you delay the ack your going to be spending half the bandwidth.
On the client size, either the user is typing fast and you should
delay the acks for the echo chars or it isn't and you should send
acks right away. How does TCP know ? by messuring the interarrival
time of echo chars. Now this meassuring needs to be done with
care. First it must only count data segments (in the patch i sent
you acks are also counted), second one must/should use this estimate
when it is based on recent data and ignore it (not delaying
the ack) when it's old. Also note that on the client side the
user doesn't have a perception of delay because of delayed acks
since they are for the echo that allready arrived and you aren't
playing funny tricks with rtts since every packet will have it's
echo. Also delayed acks will cause the rtt to climb a bit
increasing the retransmission timeout. I believe that our current
problem comes from two things: Solaris as a broken way to start
the rto calculation for a connection... our estimate of ack
time out is as broken... it bases itself on the 3-way handshake.
Blame Sun and me.


I think we can do it right but unfortunatly i don't have the time right now
do write the apropriate code. What i would suggest is that you disable
delayed acks for now. This would let us know if all the performance problems
come from this and introduce the right code after (maybe after 2.0 if you wish
to release it real soon).

regards,
Pedro.


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