lkml.org 
[lkml]   [1998]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: delayed acks after fast recover
   Date: Wed, 25 Nov 1998 22:09:57 +0100 (CET)
From: Andrea Arcangeli <andrea@e-mind.com>

Hello Andrea.

David, in 2.1.129 you have fixed the sender case (doing congestion
avoidance only if we are in fast-retrans) but if I understand the code
well that has nothing to do with the delayed ack problem I reported to you
(since I am always the receiver).

This is true.

I have to say that disabling delayed acks was a lazy approch ;-).

With 2.1.129 I get this trace for example:

...

08:48:15.576381 141.76.20.99.ftp-data > 195.223.140.60.1044: P 2817:3073(256) ack 1 win 32512 [tos 0x8]
08:48:15.656384 141.76.20.99.ftp-data > 195.223.140.60.1044: . 3073:3329(256) ack 1 win 32512 [tos 0x8]
08:48:15.656465 195.223.140.60.1044 > 141.76.20.99.ftp-data: . ack 3329 win 31744 (DF)
08:48:15.736384 141.76.20.99.ftp-data > 195.223.140.60.1044: . 3329:3585(256) ack 1 win 32512 [tos 0x8]
^^^^^^
08:48:16.206425 195.223.140.60.1044 > 141.76.20.99.ftp-data: . ack 3585 win 32512 (DF)
^^^^^^
So I implemented a my own new heuristic to try to improve the delayed acks
calculation. At first I think that using tp->ato for disabling delayed
acks is a bad choice because doing that we lose the good history
information we achieved in the past.

True.

A little bit of history. Before I started doing my overhaul (read as,
rewrite) of most of the 2.1.x TCP code, there existed some code which
had the same intention as yours. However that code solved the problem
in a slightly different manner. But, it did not work and this is why
I removed it at that time.

Essentially it tried to measure the tp->ato delayed ack timeout value
in a similar way to how the RTT estimates are done for retransmit
timeouts. The intention was to keep the ATO close to the expected
interpacket arrival time being seen, but not _too_ close. The idea
was sound and clean, the implementation simply didn't work well.

The bug there seemed to be that the delayed ACK timeouts need to be
less subsceptible to variance, more so than the RTT estimations. The
result is that this experimental ATO algorithm was very subsceptible
to increased delays and interpreted it as (aparent) packet loss more
often than not.

As a side note, you might find the Vegas congestion control algorithms
interesting. What this scheme is attempting to do is dynamically
determine the queue sizes of routers and how congested they are. It's
a really intrigueing idea, and has a lot of potential. We had a
half-done implementation at one point in 2.1.x but I removed it
because not only is the algorithm unproven (still too many questions
remain about it's effect should everyone on the net use it), the
implementation was not complete.

So here my delayed acks implementation against 2.1.129

...

Basically I try to account only the delays between two consecutive packets
in the delack estimation. When the delack timer expires I return to probe
the tp->ato but at the first two consecutive packets from the other end I
stop the probing and start the regime accounting.

Ok I am looking at this patch. But I will take a lot of time with it,
this is an area where if you get it wrong in any way, someone will
notice. It took a lot of time to get the current scheme to work well
in most cases.

One problem I have so far though:

@@ -129,7 +166,7 @@
tp->delayed_acks++;
/* Tiny-grams with PSH set make us ACK quickly. */
if(th->psh && (skb->len < (tp->mss_cache >> 1)))
- tp->ato = HZ/50;
+ tp->delack_mode |= TCP_DELACK_DISABLE;
}

/* Called to compute a smoothed rtt estimate. The data fed to this
This is wrong, I don't like this. The code wants to ack "quickly" not
"right now" in these cases. There is an example case I once saw in a
trace where a SunOS host would send a stream of 100 byte sized
packets, all of which had PSH set because the user was writing in an
inefficient ways. In this case the current code will still "ack every
other" received data packet, your code here will not.

Later,
David S. Miller
davem@dm.cobaltmicro.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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