Menu
▾
▴
RE: [coLinux-users] success with scp
|
From: Sunil <fu...@ya...> - 2006-04-04 01:29:05
|
resending. last msg got rejected. Sunil <fu...@ya...> wrote: so, apply this patch to openssh-4.3p2 source and rebuild. http://www.psc.edu/networking/projects/hpn-ssh/openssh-4.3p1-hpn11.diff on colinux and any linux server: patch < openssh-4.3p1-hpn11.diff ./configure --prefix=/usr --sysconfdir=/etc/ssh make make install If you are gentoo, then useflag 'hpn' for openssh will get you this patch at no cost. on windows: install openssl, openssl-devel, minires, minires-devel, openssh-4.3p2 source package. cd /usr/src/openssh* patch < openssh-4.3p1-hpn11.diff ./configure --prefix=/usr --sysconfdir=/etc --with-ssl-dir=/usr make cygrunsrv -E sshd make install cygrunsrv -S sshd test it out. If you haven't applied the TCPWindowSize specific mods to linux and windows from my earlier emails, you can use scp -R <window size in KBytes> to test it. Throughput that I get is about 15-20MBytes per second, which I think is great. Particularly when 0.6.3 gave me like 2Mbytes in best of times. Sad part is that loopback didn't yield any benefit (except for in iperf tests where it gave 76/36Mbytes per sec upload/download). I think there is a bug to be caught somewhere. -Sunil PS: One more thing is that I am using 0.7.1 series. Sunil <fu...@ya...> wrote: well, there is more. scp/ssh actually throttles the bandwidth usage with its own flow control. And people have patches for fixing scp/ssh as the link below states: http://www.psc.edu/networking/projects/hpn-ssh/ somehow the cygwin based scp is bypassing this flow control. I will post later if this patch makes a difference to the thruput that scp gets. Sunil <fu...@ya...> wrote: All the parameters that I posted make iperf really fast now by default. 600mpbs from windows to colinux and 325mpbs (10 folds increase) the other way. But, scp refuses to become any faster, which seems more like local latency issue (scp forks ssh and pipes the reads of the file into ssh which actually does the network write), so I still get 3Mbytes per second. scp from windows to colinux, which does direct read of file and write on network, does about 15Mbytes per second. I am not able to explain this difference so far apart from the local latency I mentioned above. the thing is that this loopback driver (and other drivers) still seems to be limited by the physical NIC and what the negotiated thruput on it is. Autonegotiations force it to be 100Mbps duplex but if I force it to 1000Mbps (which is the actual speed of the NIC) it disconnects. So, if I have a router which is 1gbps, I might be able to increase thruput further....:-) Matt Dockerty <mat...@18...> wrote: Hi Sunil, I was finding it quite interesting, you seem to know more about networking than me. What are your conclusions? Did you find a reliable way to increase throughput above my posted results? -- Matt --------------------------------- From: Sunil [mailto:fu...@ya...] Sent: 31 March 2006 21:07 To: Matt Dockerty; 'colinux' Subject: RE: [coLinux-users] TcpWindowSize promise, this is last one from me on this issue...:-) the parameters which control the actual window sizes on XP SP2 are limited by: HKLM\system\currentcontrolset\services\afd\parameters\DefaultReceiveWindow HKLM\system\currentcontrolset\services\afd\parameters\DefaultSendWindow gotten from: http://technet2.microsoft.com/WindowsServer/en/Library/94d21089-411b-4bce-a823-49a77a46e7661033.mspx -Sunil Sunil <fu...@ya...> wrote: the reason why physical interface gives higher thruput with 64K compared to loopback is that the loopback has rtt of 15ms when using pcap-bridge while the physical one has an rtt of 0.45ms. If the loopback is using tuntap driver instead of winpcap in a bridged setup, the rtt is down to 0.45ms. so its the additional delay (introduced by winpcap??) which is bringing down the thruput for loopback. High b/w and high rtt is a disaster for thruput if the window size is small. A higher TCP window size compensates for this delay and corrects the thruput. Only if I could force xp to accept that...:( -Sunil Sunil <fu...@ya...> wrote: I have read the wiki a couple of times in full. I don't see any reason why, if I am able to configure two interfaces to make colinux and windows talk to each other and net, when people there have problem with even one, would it be network driver issue. as I have proven from the iperf data the problem lies in the part where TCP options negotiations happen between windows and colinux. When windows is initializing the connection, the negotiation is for a high window size, but when colinux is initializing the connection, the window size is not optimal but the default. Either colinux is not asking the right questions or windows is not responding with right answers. I have a feeling that it is the latter, and could be a bug with auto-tuning on windows side. With proper window sizes, both upload (550 Mbps) and download (350 Mbps) speeds are very much in the ballpark, at least not order of magnitude different. Can someone with XP SP1 try setting the TcpWindowSize (255500) and Tcp1323Opts (1) and confirm if the thruput improves on loopback? We are talking about 40Mbytes per second transfer rate which is close to many HDs of today. That is exciting, isn't it? If only XP will let us...:( --------------------------------- Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min. |