A problem on TCP in High RTT Environment.

[Niu Zhixiong]

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
－－－－－－－－－－－－－－－
 kaiaixi at gmail.com


On Sun, Aug 10, 2014 at 4:58 AM, Michael Tuexen <
Michael.Tuexen at lurchi.franken.de> wrote:

>
> On 09 Aug 2014, at 22:45, John-Mark Gurney <jmg at funkthat.com> 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 <jmg at funkthat.com> 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 is
> >>>> always slower than SCTP. But, I think it is not possible. (Plz see the
> >>>> figure in the attachment). When the delay is 200ms(means RTT=400ms).
> >>>> Besides, the TCP is extremely slow.
> >>>>
> >>>> ALL BW=20Mbps, DELAY= 0 ~ 200MS, Packet LOSS = 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 enough
> >>> to deal w/ the higher latency...
> >>>
> >>> Also, make sure your program isn't setting the recv buffer size as that
> >>> will disable the auto growing...
> >> I think the program sets the buffer to 2MB, which it also does for SCTP.
> >> 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."
> >
>
>