From: Philip (philip.lawrence3@btinternet.com)
Date: Sun Mar 21 2004 - 04:53:00 EST
The window size I guess was a red herring, it seems we all use a 64KB
window from the ftp server and the large value that I observed on the
ethereal trace was not reproduceable.
My real problem is that Tru64 cannot use a 25Mbps MPLS WAN link at
anything like the rate of Windows or Linux. We upgraded our WAN link
recently from 10Mbps SMDS to 25Mpbs MPLS. An overnight 12GB transfer
used to complete within 4 hours now takes 9+ hours; however Linux and
Windows can use the new link at a much faster rate than the old link.
In the tcpdump traces I can see regular 1.2/1.4 second pauses in a Tru64
ftp client - Tru64 ftp server, but the traces of Linux ftp client and
Windows ftp client to Tru64 server show pauses of 0.2 seconds.
This results in transfer rates as follows:
Tru64 ~400KB/sec
Windows ~900KB/sec
Linux ~1.5MB/sec
The pauses I assume are Tru64 backing off and waiting for retransmit
timers when congested. Tru64 looks like it doesn't do the same
calculations as other OS's and gets a different time span to back off.
At the suggestion of HP I have slowed down the transfer rate by adding a
host route with a -limit flag to reduce the data rate over the link.
This had no effect on the 1.5 sec delays, but can slow down the data
transfer rate.
Tried various permutations of values in various kernel subsystems
without much impact
changing tcp_rexmit_interval_min made no difference
increasing ipmaxqlen made no difference
tcp_rxmitthresh=1 forces a fast retransmit at every DUP ACK and swamps
the WAN at 100% usage but I can get my 12GB file transfer in under 5
hours.
Tru64 V5.1A PK#6, anyone suggest anything I could try to stop Tru64 from
backing off so much.I have been blaming the WAN link characteristics but
if other OS's can handle it OK then why not Tru64?
Thanks and regards
Phil Lawrence
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:54 EDT