Hi
A co-worker is having performance problems when doing Linux to Solaris
transfers on WAN's.
> -------- Original Message --------
> Subject: linux to solaris tcp issues
> Date: Fri, 24 Nov 2000 16:05:57 +0100
> From: Brian Tierney <bltierney@xxxxxxx>
> Organization: CERN/LBNL
>
>
> Hello all:
>
> I have noticed a rather dramatic performance problem with TCP with
> a Linux sender and a non-Linux receiver, and wonder if this is a known
> problem, and if there is a solution. Higher latency and/or higher
> congestion makes the problem worse.
>
>
> Here are some results:
>
> local 100BT network: Linux to Solaris = Solaris to Linux = 90 Mbps
> (i.e.: no problems (also no congestion))
>
> ANL to LBL (45 ms RTT): Linux to Linux: 50 Mbps
> Solaris to Linux: 50 Mbps
> Linux to Solaris: 3 Mbps
>
>
> LBL to CERN: (180 ms RTT) : Linux to Linux: 25 Mbps
> Solaris to Linux: 25 Mbps
> Linux to Solaris: .5 Mbps
> Linux to FreeBSD: .5 Mbps
> Solaris to solaris: 25 Mbps
>
>
> I have tested this with Linux 2.2.12, 2.2.14, 2.2.16, 2.2.17 and
> 2.4.0-test6 kernels on the sender, and Solaris 2.6 and 2.7 for the
> receiver, and the results are the same.
>
> I am using iperf for the testing, and have triple checked that the TCP
> buffers are set correctly. http://dast.nlanr.net/Projects/Iperf/index.html
>
>
> For a sample tcpdump output showing this, see:
> http://www-didc.lbl.gov/tierney/tmp/tcpdump-solaris-vs-linux.out.gz
>
> This file has 2 simultaneous streams from a linux box, 1 to a linux and the
> other to a
> solaris host.
>
> The important tcptrace output files for this run are:
> http://www-didc.lbl.gov/tierney/tmp/linux-to-linux.xpl.gz
> http://www-didc.lbl.gov/tierney/tmp/linux-to-solaris.xpl.gz
>
>
> Thanks for any insight you might have into this. I can't believe that this
> isn't a more well-known issue.
>
>
>
> -------- Original Message --------
> Subject: Re: linux to solaris tcp issues
> Date: Fri, 24 Nov 2000 10:08:37 PST
> From: Vern Paxson <vern@xxxxxxxxxx>
> To: Brian Tierney <bltierney@xxxxxxx>
>
>
> Well, the problem is that the sender is miscomputing its RTO, setting it to
> a value that's much too low (according to the standard). This appears to
> work Linux-Linux because the Linux delayed ack is very small (also not a
> good idea!). Solaris uses a larger delayed ack (looks like around 50 msec,
> still quite small) and that's enough to push the RTT above the RTO. This
> just needs to happen once when you have a lot of data in flight and its
> disaster, the entire flight gets retransmitted and the congestion response
> is drastic.
>
> > (Sorry if this is a well know problem with a well known
> > solution. If so, let me know!).
>
> Not that I know of, though I agree you'd think it would be. A while ago
> there was a similar sort of bug in Solaris (ironically) that wasn't widely
> known, either, even though it spelled disaster any time the RTT got above a
> couple hundred msec.
>
> Vern
>
>
> --
> ------------------------------------------------------------------------
> Brian L. Tierney, Lawrence Berkeley National Laboratory (LBNL)
> 1 Cyclotron Rd. MS: 50B-2239, Berkeley, CA 94720
> tel: 510-486-7381 fax: 510-495-2998 efax: 603-719-5047
> bltierney@xxxxxxx http://www-didc.lbl.gov/~tierney
>
> currently on leave from LBNL to CERN:
> CERN, IT/PDP, Bldg 31, 2-013, 1211 Geneva 23, Switzerland
> tel: +41 22 76 74543 fax: +41 22 76 77155
> ------------------------------------------------------------------------
--
Pekka Pietikainen
|