On Mon, 16 Mar 2009, Peter Stuge 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 wel
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.
On Mon, 16 Mar 2009, Borey wrote:
> It seems, that this build is quite stable.
> Daniel, do you have a plan to create an "official" load (tar.gz archive).
Not yet. I want more testing done first and I have some further pending work
to do before I think it is ready for release.
In the mean time
2009/3/16 Borey :
> It seems, that this build is quite stable.
> Daniel, do you have a plan to create an "official" load (tar.gz archive).
>
> Thanks and regards.
> PS: Unfortunately, I don't have a even CVS access behind my proxy.
http://daniel.haxx.se/projects/libssh2/snapshots.html
---
It seems, that this build is quite stable.
Daniel, do you have a plan to create an "official" load (tar.gz archive).
Thanks and regards.
PS: Unfortunately, I don't have a even CVS access behind my proxy.
2009/3/16 E L
> >> Could that cause extra latency in applications that have several
> chann
>> 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? It would
> be really useful to get some fu
Daniel,
Thanks for all your work on this! I was just starting to poke around
at the this same problem on Friday and saw this thread. I'm using
Perl's Net::SSH2 to do multiple 10mb transfers every 5 minutes and I'm
getting overlapping processes. I'll grab the CVS and let you know how
it goes.
Than
Hi Daniel.
Do you have any estimation when ypou can commit your code and it will be
avaliable ?
Thanks.
2009/3/15 Daniel Stenberg
> On Sat, 14 Mar 2009, Daniel Stenberg wrote:
>
> > SFTP 37MB/s
> > SCP 40MB/s
> >
> > Using libssh2, I don't get above 600KB/s using SCP... It's so silly.
> Ther
On Mon, 16 Mar 2009, Borey wrote:
> Do you have any estimation when ypou can commit your code and it will be
> avaliable ?
It has already been committed! Please just update from CVS and give it a spin.
--
/ daniel.haxx.se
On Sun, 15 Mar 2009, Dan Fandrich wrote:
>> 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?
>
> Could that cause extra latency in applications that have several channels
> open
On Sun, Mar 15, 2009 at 07:53:42PM +0100, Daniel Stenberg wrote:
> 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?
Could that cause extra latency in applications that have several
On Sun, 15 Mar 2009, Daniel Stenberg wrote:
> Right now I'm at 20MB/s speed for SCP downloads but this code has some minor
> regression still that I need to fix before I can commit. SFTP is at 12MB/s.
It's really all about the channel window handling, and when we're talking raw
localhost transf
On Sat, 14 Mar 2009, Daniel Stenberg wrote:
> SFTP 37MB/s
> SCP 40MB/s
>
> Using libssh2, I don't get above 600KB/s using SCP... It's so silly. There's
> clearly something terribly wrong in there.
It was. My test program was stupid so it wrote all received data to stdout,
but due it being all
13 matches
Mail list logo
