From owner-freebsd-net@FreeBSD.ORG Sun Nov 4 19:49:34 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7625B217 for ; Sun, 4 Nov 2012 19:49:34 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id CC65C8FC0A for ; Sun, 4 Nov 2012 19:49:33 +0000 (UTC) Received: (qmail 42163 invoked from network); 4 Nov 2012 21:25:19 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 4 Nov 2012 21:25:19 -0000 Message-ID: <5096C6CA.4090306@freebsd.org> Date: Sun, 04 Nov 2012 20:49:30 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Fabian Keil , null@pozo.com Subject: Re: kern/173309: [tcp] TCP connections often prematurely closed by the server side after r242262 [regression] References: <201211032251.qA3Mpnp6017076@freefall.freebsd.org> <5095B953.9060301@freebsd.org> <20121104132957.3965dc99@fabiankeil.de> In-Reply-To: <20121104132957.3965dc99@fabiankeil.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 19:49:34 -0000 On 04.11.2012 13:29, Fabian Keil wrote: > Andre Oppermann wrote: > >> thank you for the bug report. Please try the attached patch >> which should fix the issue you observed. > > Thanks for the patch, Andre. > > It seems to make the transfers 100% reliably again, > but they are frequently very slow: > > fk@r500 ~ $i=1; while curl -o /dev/zero 'http://127.0.0.1:81/90k-file'; do echo $i; ((i=$i+1)); done > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 100 90000 100 90000 0 0 8670 0 0:00:10 0:00:10 --:--:-- 2057 > 1 > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 100 90000 100 90000 0 0 8821 0 0:00:10 0:00:10 --:--:-- 2057 > 2 > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 100 90000 100 90000 0 0 8821 0 0:00:10 0:00:10 --:--:-- 2057 > 3 > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 100 90000 100 90000 0 0 33.0M 0 --:--:-- --:--:-- --:--:-- 42.9M > 4 > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 100 90000 100 90000 0 0 32.5M 0 --:--:-- --:--:-- --:--:-- 85.8M > > Looks like this is caused by occasional 5 second pauses > between packets after the client's TCP window update: Fabian, Manfred, The patch I sent was not correct. Please try this new attached patch instead. -- Andre Index: netinet/tcp_output.c =================================================================== --- netinet/tcp_output.c (revision 242577) +++ netinet/tcp_output.c (working copy) @@ -228,7 +228,7 @@ tso = 0; mtu = 0; off = tp->snd_nxt - tp->snd_una; - sendwin = min(tp->snd_wnd, tp->snd_cwnd); + sendwin = ulmax(ulmin(tp->snd_wnd - off, tp->snd_cwnd), 0); flags = tcp_outflags[tp->t_state]; /* @@ -249,7 +249,7 @@ (p = tcp_sack_output(tp, &sack_bytes_rxmt))) { long cwin; - cwin = min(tp->snd_wnd, tp->snd_cwnd) - sack_bytes_rxmt; + cwin = ulmin(tp->snd_wnd - off, tp->snd_cwnd) - sack_bytes_rxmt; if (cwin < 0) cwin = 0; /* Do not retransmit SACK segments beyond snd_recover */ @@ -355,7 +355,7 @@ * sending new data, having retransmitted all the * data possible in the scoreboard. */ - len = ((long)ulmin(so->so_snd.sb_cc, tp->snd_wnd) + len = ((long)ulmin(so->so_snd.sb_cc, tp->snd_wnd - off) - off); /* * Don't remove this (len > 0) check !