Call for TESTING (was Re: [1.7.0-50] scp progress counter flies through first 175 MB or so)

[Warren Young]

I scp'd a 1.6 GB file back and forth to a Linux server over GigE to a 
fast new RAID-10.  I tested 1.7.0-50 and 20090629.

Results:

On a 32-bit XP box, 1.7.0-50 gives about 15 MByte/sec for both upload 
and download.  (This box can't really hit GigE speeds due to crappy 
cabling and a low-quality switch.)  On switching to the snapshot, the 
download speed is about the same, but upload is cut to 4-5 MB/sec.

On a 64-bit Vista box, 1.7.0-50 gives inconsistent behavior.  Download 
behaves as it should: ~45 MB/sec here, due to better switch and cabling. 
  But, uploading with scp gives the reported behavior: the scp status 
fills out to 100% very fast but then scp doesn't finish running for 
quite a while.  It's like it's buffering a big fraction of the 1.6 GB, 
which isn't impossible, since this box has 12 GB of RAM.  (Core i7, 
DDR3, wheee!)

After switching to the snapshot on that Vista-64 box, the scp progress 
display becomes useful, growing steadily as scp runs.  Unfortunately, my 
upload speed is down to around 5 MB/sec here, just as on the XP box.

A different non-Cygwin scp client I have here can manage much faster 
transfer speeds, so I can rule out disk and network bottlenecks.  The 
slowdowns are in Cygwin itself or the Cygwin scp port.

I can rule out a problem in the general network I/O handling: changing 
the DLL doesn't seem to affect ttcp results materially.  It's either scp 
or the way scp uses cygwin1.dll.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple