|
From: | Josef Bacik |
Subject: | Re: [PATCH] tcp: ack when we get an OOO/lost packet |
Date: | Mon, 7 Dec 2015 13:28:22 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 |
On 12/07/2015 12:59 PM, Andrei Borzenkov wrote:
12.08.2015 18:16, Josef Bacik пишет:While adding tcp window scaling support I was finding that I'd get some packet loss or reordering when transferring from large distances and grub would just timeout. This is because we weren't ack'ing when we got our OOO packet, so the sender didn't know it needed to retransmit anything, so eventually it would fill the window and stop transmitting, and we'd time out. Fix this by ACK'ing when we don't find our next sequence numbered packet. With this fix I no longer time out. Thanks,Applied. Sorry, it somehow slipped through. More ideas in the same direction. 1. GRUB timeout for receiving currently is ~33 seconds. It is too small comparing with anything else. I am pretty sure in situation from tcpdump you sent me we could recover if timeout was in order of several minutes :)
Yeah I jacked up the receive timeout in one of my iterations and that helped as well. Could probably make it configurable.
2. We may consider sending ACK in grub_net_tcp_retransmit() additionally, although it probably needs proper rate-limiting based on RTT. 3. Using timestamp option may improve RTT detection for partner and is pretty cheap to implement.
I'm trying to get some standard testing set up internally so I can test all of our hardware types whenever I make changes. Once I get that stuff set up I'll look at adding this and some other features. Thanks,
Josef
[Prev in Thread] | Current Thread | [Next in Thread] |