From owner-freebsd-net@FreeBSD.ORG Sun Aug 10 02:12:12 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F20AF537 for ; Sun, 10 Aug 2014 02:12:11 +0000 (UTC) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AF6DF25A2 for ; Sun, 10 Aug 2014 02:12:11 +0000 (UTC) Received: by mail-qc0-f170.google.com with SMTP id x3so584053qcv.29 for ; Sat, 09 Aug 2014 19:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O9O+LVVPmI1+5Dc3omOIKVqWXuyM++K24VAJqHxfRk4=; b=Q0/uPA288lECBHFAkHZ9DZHCPB7lEanmjuXisPkVz7+9CCr4V1nS8Dwfk40jIz+f3A ELdmcGhAp5FqIbjYxaZLzSeMaEUqVEY/FXNEF1b3sn/4w/Hy9O6PJAT63/RFQ0cPJNM2 /eh9czbdOWO9kdctqsdTXWcx0zFdRIZN31NzwL1jvGyh9thiCBrKpaqJe4MjSPDsVoPt jp4k9xsJbSS/1yTIaeRaU8VNSS3dQb5+/AnigIQb6qTK63tivdUl1iu9FlCNAgk5ZUHD 1GIg+fLzazvUnKkX8Q/7KMJAnu+Yn2rZwxOI7OlR6tlIz363dco5baEB50rU2pSiCO++ rCYQ== MIME-Version: 1.0 X-Received: by 10.229.68.131 with SMTP id v3mr50597999qci.10.1407636730519; Sat, 09 Aug 2014 19:12:10 -0700 (PDT) Received: by 10.224.137.71 with HTTP; Sat, 9 Aug 2014 19:12:10 -0700 (PDT) In-Reply-To: <3F6BC212-4223-4AAC-8668-A27075DC55C2@lurchi.franken.de> References: <20140809184232.GF83475@funkthat.com> <8AE1AC56-D52F-4F13-AAA3-BB96042B37DD@lurchi.franken.de> <20140809204500.GG83475@funkthat.com> <3F6BC212-4223-4AAC-8668-A27075DC55C2@lurchi.franken.de> Date: Sun, 10 Aug 2014 10:12:10 +0800 Message-ID: Subject: Re: A problem on TCP in High RTT Environment. From: Niu Zhixiong To: Michael Tuexen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-net@freebsd.org, John-Mark Gurney , Bill Yuan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 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, 10 Aug 2014 02:12:12 -0000 Hi During the TCP4 transmission. Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 2097346 10.0.10.2.13504 10.0.10.3.9000 ESTABLISHED Regards, Niu Zhixiong =EF=BC=8D=EF=BC=8D=EF=BC=8D=EF=BC=8D=EF=BC=8D=EF=BC=8D=EF=BC=8D=EF=BC=8D=EF= =BC=8D=EF=BC=8D=EF=BC=8D=EF=BC=8D=EF=BC=8D=EF=BC=8D=EF=BC=8D kaiaixi@gmail.com On Sun, Aug 10, 2014 at 4:58 AM, Michael Tuexen < Michael.Tuexen@lurchi.franken.de> wrote: > > On 09 Aug 2014, at 22:45, John-Mark Gurney wrote: > > > Michael Tuexen wrote this message on Sat, Aug 09, 2014 at 21:51 +0200: > >> > >> On 09 Aug 2014, at 20:42, John-Mark Gurney wrote: > >> > >>> Niu Zhixiong wrote this message on Fri, Aug 08, 2014 at 20:34 +0800: > >>>> Dear all, > >>>> > >>>> Last month, I send problems related to FTP/TCP in a high RTT > environment. > >>>> After that, I setup a simulation environment(Dummynet) to test TCP > and SCTP > >>>> in high delay environment. After finishing the test, I can see TCP i= s > >>>> always slower than SCTP. But, I think it is not possible. (Plz see t= he > >>>> figure in the attachment). When the delay is 200ms(means RTT=3D400ms= ). > >>>> Besides, the TCP is extremely slow. > >>>> > >>>> ALL BW=3D20Mbps, DELAY=3D 0 ~ 200MS, Packet LOSS =3D 0 (by dummynet) > >>>> > >>>> This is my parameters: > >>>> FreeBSD vfreetest0 10.0-RELEASE FreeBSD 10.0-RELEASE #0: Thu Aug 7 > >>>> 11:04:15 HKT 2014 > >>>> > >>>> sysctl net.inet.tcp > >>> > >>> [...] > >>> > >>>> net.inet.tcp.recvbuf_auto: 0 > >>> > >>> [...] > >>> > >>>> net.inet.tcp.sendbuf_auto: 0 > >>> > >>> Try enabling this... This should allow the buffer to grow large enou= gh > >>> to deal w/ the higher latency... > >>> > >>> Also, make sure your program isn't setting the recv buffer size as th= at > >>> will disable the auto growing... > >> I think the program sets the buffer to 2MB, which it also does for SCT= P. > >> So having both statically at the same size makes sense for the > comparison. > >> I remember that there was a bug in the combination of LRO and delayed > ACK, > >> which was fixed, but I don't remember it was fixed before 10.0... > > > > Sounds like disabling LRO and TSO would be a useful test to see if that > > improves things... But hiren said that the fix made it, so... > > > >>> If you use netstat -a, you should be able to see the send-q on the > >>> sender grow as necessary... > > > > Also, getting the send-q output while it's running would let us know > > if the buffer is getting to 2MB or not... > That is correct. Niu: Can you provide this? > > Best regards > Michael > > > > -- > > John-Mark Gurney Voice: +1 415 225 5579 > > > > "All that I will do, has been done, All that I have, has not." > > > >