Interesting results. Daniel Stenberg wrote: > It's really all about the channel window handling, and when we're > talking raw localhost transfers we clearly need to set a very large > window to get close to top speed for SCP.
SCP itself is wrong and deprecated and bad in many ways, but oh well. > a pretty big window. This way, I can repeatedly transfer my 1GB file > over SCP at 38MB/s! (SFTP still left at only almost 14MB/s). I would like to discuss this with Chris Rapier at psc.edu who provides the hpn-ssh patch for OpenSSH-portable. hpn is for High Performance Networking, and it's a patch to maximize throughput in high bandwidth but not neccessarily short response time situations. > If I do the logic with *10 and *20 window instead, I don't get more > than ~25MB/s! If I use *300 and *600 I in fact get close to 40MB/s. > Which happens to be the openssh speed. I must confess this makes me > pretty content. > > Can anyone think of any particular downside with going with these > rather extreme window sizes as-is, or should we work on getting a > more clever scheme for them? Does libssh2 buffer the full windows? I think 12Mbyte buffers are far too fat to be OK in the general case! Daniel Stenberg wrote: > > Could that cause extra latency in applications that have several > > channels open at once? > > Hm, yes I guess it might - depending on how the server deals with > multiple channels. > > Does anyone have any test/use case that might fit this description? I will use libssh2 with multiple channels, probably two, maybe three, where one is for file transfer and the others for control. This will run over very fragile and convoluted links, performing remote update on (industrial) embedded systems. It's not finished yet, but I will do some libssh2 testing as it comes closer to being completed. > It would be really useful to get some further feedback, eyeballs > and general testing of my recent changes to make me feel really > good about them... It sounds like a good performance optimization but consuming so much memory is not a good thing especially for a low level library such as libssh2. The conclusion is that I am requesting a more clever scheme. One scheme would be libssh2 "windowing profiles" where I can explicitly specify that I want a fat high throughput connection, versus a slim moderate throughput one. Of course full auto is nicer but I would be happy with manual control. //Peter ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ libssh2-devel mailing list libssh2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libssh2-devel
