Messages in this thread Patch in this message | | | Date | Mon, 30 Nov 1998 09:43:17 -0800 | From | "David S. Miller" <> | Subject | Re: 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/
| |