Messages in this thread | | | From | roque@di ... | Subject | Re: 1.3.87 and SLOW SLIP/PPP | Date | Sat, 13 Apr 1996 20:32:41 +0100 |
| |
>>>>> "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.
| |