|
From: | Andrei Borzenkov |
Subject: | Re: [PATCH] tcp: ack when we get an OOO/lost packet |
Date: | Thu, 13 Aug 2015 20:13:27 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 |
On 13.08.2015 16:59, Josef Bacik wrote:
On 08/13/2015 04:19 AM, Andrei Borzenkov wrote:On Wed, Aug 12, 2015 at 6:16 PM, Josef Bacik <address@hidden> wrote: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,I have a feeling that your description is misleading. Patch simply sends duplicated ACK, but partner does not know what has been received and what has not, so it must wait for ACK timeout anyway before retransmitting. What this patch may fix would be lost ACK packet *from* GRUB, by increasing rate of ACK packets it sends. Do you have packet trace for timeout case, ideally from both sides simultaneously?The way linux works is that if you get <configurable amount> of DUP ack's it triggers a retransmit.
Do you have pointers to documentation and code?
I only have traces from the server since tcpdump doesn't work in grub (or if it does I don't know how to do it).
GRUB does not have tcpdump, but your switch quite likely has port mirroring.
The server is definitely getting all of the ACK's, and from my printf()'ing in grub we are either getting re-ordered packets (the most likely) or we are simply losing a packet here or there. This is a pretty long distance and we have a lot of networking between Sweden and California so reordering or packet loss isn't out of the question. Regardless we definitely need to be ACK'ing packets that come in with the last seq we had as the spec says so the sender knows the last bit we had, otherwise we see timeouts once the window is full.
I'm fine with it, I just want to understand why it fixes anything and get commit message right.
Did you consider implementing receive side SACK BTW? You have the right environment to test it :)So I found this bug while implementing SACK, and decided it was faster to just do this rather than add SACK. This method is still exceedingly slow, I only get around 800kb/s over the entire transfer whereas I can sustain around 5.5 mb/s before we start losing stuff, so I'm definitely going to go back and try the timestamp echo stuff since the timeout stuff takes like 6 seconds, and then if that doesn't work bite the bullet and add SACK. But first I want to get my ipv6 patches right ;). Thanks, Josef
[Prev in Thread] | Current Thread | [Next in Thread] |