From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1ZPw4U-0002BS-AI for mharc-grub-devel@gnu.org; Thu, 13 Aug 2015 13:13:42 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34970) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPw4N-00026v-1V for grub-devel@gnu.org; Thu, 13 Aug 2015 13:13:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZPw4H-0006Mm-Sg for grub-devel@gnu.org; Thu, 13 Aug 2015 13:13:34 -0400 Received: from mail-la0-x230.google.com ([2a00:1450:4010:c03::230]:36469) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPw4H-0006MP-K7 for grub-devel@gnu.org; Thu, 13 Aug 2015 13:13:29 -0400 Received: by lagz9 with SMTP id z9so29811896lag.3 for ; Thu, 13 Aug 2015 10:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=K0JPDfnEotUguHhzf6HjPtPnA2+NPERlVzIGlzXBUXY=; b=UaPhEiD4lK3cLZ3b/mcB8lM6GWd6nmiA84jyaxH241ijMwhxNV0eJRT8H8leRjzkN1 wVO0d9xdScnn8tPwuINRzHjIkYFMVz+Zn3uedn8NGC9AutkhWWHt5Q7wIHW/UX+ljefu 0taaIGlLGPzyHGtAqzHMf5Kiq6xA63vSV7qm8KO9oOzh1A/OwGq3Pr18z7fnqSpRZEFV Eol8t2VwiBlq1cY/b0IvS6YUGjTLLZmlmUGWrlnCjqvnKzCLFqzM4xBhaoeC5jIS4ksq Q/J3pt+HfhBZ8iBUWqzV+vhFRr8HjX2zPwkdOaRT4T5haq+FHnD0+Ip48Y0ze56SL07l yE5g== X-Received: by 10.152.234.75 with SMTP id uc11mr37125865lac.20.1439486008856; Thu, 13 Aug 2015 10:13:28 -0700 (PDT) Received: from [192.168.1.43] (ppp91-76-5-127.pppoe.mtu-net.ru. [91.76.5.127]) by smtp.gmail.com with ESMTPSA id ld2sm703980lac.49.2015.08.13.10.13.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Aug 2015 10:13:27 -0700 (PDT) Message-ID: <55CCD037.4040106@gmail.com> Date: Thu, 13 Aug 2015 20:13:27 +0300 From: Andrei Borzenkov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Josef Bacik , The development of GNU GRUB Subject: Re: [PATCH] tcp: ack when we get an OOO/lost packet References: <1439392582-3172342-1-git-send-email-jbacik@fb.com> <55CCA2D3.1050306@fb.com> In-Reply-To: <55CCA2D3.1050306@fb.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::230 Cc: kernel-team@fb.com X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 17:13:39 -0000 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 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 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 >