[1.7.0-50] scp progress counter flies through first 175 MB or so

[Andrew Schulman-3]

Here's an odd one.

Using openssh 5.2p1-2 with Cygwin 1.7.0-50, when I scp any file, the
progress counter appears to show ridiculously fast transfer rates, e.g.
about 50 MB/s over a 750 KB/s connection, for the first 175 MB or so. After
that the counter settles down to normal speed.  Then when the counter
reaches the end, it "hangs" at 100% for the remaining time while the copy
finishes.

At first I thought that the copy itself was being corrupted in the first
175 MB, but I'm no longer able to reproduce that.  I believe now that the
copy is good and it's only the progress counter that's wrong.

When I revert to Cygwin 1.7.0-49, this problem doesn't occur.

Thanks,
Andrew.


--
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

[Corinna Vinschen-2]

On Jun 24 13:17, Andrew Schulman wrote:

> Here's an odd one.
>
> Using openssh 5.2p1-2 with Cygwin 1.7.0-50, when I scp any file, the
> progress counter appears to show ridiculously fast transfer rates, e.g.
> about 50 MB/s over a 750 KB/s connection, for the first 175 MB or so. After
> that the counter settles down to normal speed.  Then when the counter
> reaches the end, it "hangs" at 100% for the remaining time while the copy
> finishes.
>
> At first I thought that the copy itself was being corrupted in the first
> 175 MB, but I'm no longer able to reproduce that.  I believe now that the
> copy is good and it's only the progress counter that's wrong.
>
> When I revert to Cygwin 1.7.0-49, this problem doesn't occur.

I can reproduce that copying a file via scp from a Windows machine to
a Linux box.

It looks like the pipes between the local scp and the local ssh are now
exchanging the data quicker at the start than the ssh socket can send
them to the remote machine.  On my XP machine, scp advances quickly by
about 260 Megs (hard to tell, maybe it's exaclty 256 Megs for some
reason?), then keeps the advance roughly at that value until scp
finished.  At the end scp is just waiting for ssh which still has to
send the 256/260 Megs of data.

This is really weird, given that Cygwin does not create such a big
buffer for the pipe.  Consequentially Task Manager claims that the
memory is neither taken by scp, nor by ssh.  Both processes have normal
VM sizes < 10 Megs.  Per Task manager the memory is paged Kernel Memory.
A strange side effect is that the entire time taken by the data
transmission is longer than with -49, by almost exactly the time it
takes to empty the big kernel cache.

Puzzeling.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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

[Christopher Faylor-8]

On Thu, Jun 25, 2009 at 12:10:39PM +0200, Corinna Vinschen wrote:

>On Jun 24 13:17, Andrew Schulman wrote:
>> Here's an odd one.
>>
>> Using openssh 5.2p1-2 with Cygwin 1.7.0-50, when I scp any file, the
>> progress counter appears to show ridiculously fast transfer rates, e.g.
>> about 50 MB/s over a 750 KB/s connection, for the first 175 MB or so. After
>> that the counter settles down to normal speed.  Then when the counter
>> reaches the end, it "hangs" at 100% for the remaining time while the copy
>> finishes.
>>
>> At first I thought that the copy itself was being corrupted in the first
>> 175 MB, but I'm no longer able to reproduce that.  I believe now that the
>> copy is good and it's only the progress counter that's wrong.
>>
>> When I revert to Cygwin 1.7.0-49, this problem doesn't occur.
>
>I can reproduce that copying a file via scp from a Windows machine to
>a Linux box.
>
>It looks like the pipes between the local scp and the local ssh are now
>exchanging the data quicker at the start than the ssh socket can send
>them to the remote machine.  On my XP machine, scp advances quickly by
>about 260 Megs (hard to tell, maybe it's exaclty 256 Megs for some
>reason?), then keeps the advance roughly at that value until scp
>finished.  At the end scp is just waiting for ssh which still has to
>send the 256/260 Megs of data.
>
>This is really weird, given that Cygwin does not create such a big
>buffer for the pipe.  Consequentially Task Manager claims that the
>memory is neither taken by scp, nor by ssh.  Both processes have normal
>VM sizes < 10 Megs.  Per Task manager the memory is paged Kernel Memory.
>A strange side effect is that the entire time taken by the data
>transmission is longer than with -49, by almost exactly the time it
>takes to empty the big kernel cache.
>
>Puzzeling.

Is ssh using non-blocking pipes opened for write?  Until a week or two
ago, Cygwin didn't support those and treated the non-blocking write as a
blocking write.

cgf

--
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

[Corinna Vinschen-2]

On Jun 25 10:05, Christopher Faylor wrote:

> On Thu, Jun 25, 2009 at 12:10:39PM +0200, Corinna Vinschen wrote:
> >On Jun 24 13:17, Andrew Schulman wrote:
> >> Here's an odd one.
> >>
> >> Using openssh 5.2p1-2 with Cygwin 1.7.0-50, when I scp any file, the
> >> progress counter appears to show ridiculously fast transfer rates, e.g.
> >> about 50 MB/s over a 750 KB/s connection, for the first 175 MB or so. After
> >> that the counter settles down to normal speed.  Then when the counter
> >> reaches the end, it "hangs" at 100% for the remaining time while the copy
> >> finishes.
> >>
> >> At first I thought that the copy itself was being corrupted in the first
> >> 175 MB, but I'm no longer able to reproduce that.  I believe now that the
> >> copy is good and it's only the progress counter that's wrong.
> >>
> >> When I revert to Cygwin 1.7.0-49, this problem doesn't occur.
> >
> >I can reproduce that copying a file via scp from a Windows machine to
> >a Linux box.
> >
> >It looks like the pipes between the local scp and the local ssh are now
> >exchanging the data quicker at the start than the ssh socket can send
> >them to the remote machine.  On my XP machine, scp advances quickly by
> >about 260 Megs (hard to tell, maybe it's exaclty 256 Megs for some
> >reason?), then keeps the advance roughly at that value until scp
> >finished.  At the end scp is just waiting for ssh which still has to
> >send the 256/260 Megs of data.
> >
> >This is really weird, given that Cygwin does not create such a big
> >buffer for the pipe.  Consequentially Task Manager claims that the
> >memory is neither taken by scp, nor by ssh.  Both processes have normal
> >VM sizes < 10 Megs.  Per Task manager the memory is paged Kernel Memory.
> >A strange side effect is that the entire time taken by the data
> >transmission is longer than with -49, by almost exactly the time it
> >takes to empty the big kernel cache.
> >
> >Puzzeling.
>
> Is ssh using non-blocking pipes opened for write?  Until a week or two
> ago, Cygwin didn't support those and treated the non-blocking write as a
> blocking write.

scp switches the pipes to non-blocking and then tries to do blocking io
on its own, using the poll() function.  It calls a function called scpio
which basically work like this:

  scpio (io_function, fd, buf, size)
  {
    for (offset = 0; offset < size;) {
      r = io_function (fd, buf + offset, size - offset);
      [...]
      if (r < 0) {
        if (errno == EINTR)
          continue;
        if (errno == EAGAIN || errno == EWOULDBLOCK) {
          poll (fd, 1, -1) /* Use poll() for blocking */
          continue;
        }
        [...]
      }
      offset += r;
    }
  }

Looks like scp now stumbles over the pipe select() implementation.

Btw., scp knows a `-l bandwidth' parameter to allow to specify a maximum
throughput.  If you set this to a value which corresponds to the maximum
throughput of the sending socket in ssh, then you can "optimize" the
problem away and you're back to the old timings.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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

[Christopher Faylor-8]

On Thu, Jun 25, 2009 at 04:36:51PM +0200, Corinna Vinschen wrote:

>On Jun 25 10:05, Christopher Faylor wrote:
>> On Thu, Jun 25, 2009 at 12:10:39PM +0200, Corinna Vinschen wrote:
>> >On Jun 24 13:17, Andrew Schulman wrote:
>> >> Here's an odd one.
>> >>
>> >> Using openssh 5.2p1-2 with Cygwin 1.7.0-50, when I scp any file, the
>> >> progress counter appears to show ridiculously fast transfer rates, e.g.
>> >> about 50 MB/s over a 750 KB/s connection, for the first 175 MB or so. After
>> >> that the counter settles down to normal speed.  Then when the counter
>> >> reaches the end, it "hangs" at 100% for the remaining time while the copy
>> >> finishes.
>> >>
>> >> At first I thought that the copy itself was being corrupted in the first
>> >> 175 MB, but I'm no longer able to reproduce that.  I believe now that the
>> >> copy is good and it's only the progress counter that's wrong.
>> >>
>> >> When I revert to Cygwin 1.7.0-49, this problem doesn't occur.
>> >
>> >I can reproduce that copying a file via scp from a Windows machine to
>> >a Linux box.
>> >
>> >It looks like the pipes between the local scp and the local ssh are now
>> >exchanging the data quicker at the start than the ssh socket can send
>> >them to the remote machine.  On my XP machine, scp advances quickly by
>> >about 260 Megs (hard to tell, maybe it's exaclty 256 Megs for some
>> >reason?), then keeps the advance roughly at that value until scp
>> >finished.  At the end scp is just waiting for ssh which still has to
>> >send the 256/260 Megs of data.
>> >
>> >This is really weird, given that Cygwin does not create such a big
>> >buffer for the pipe.  Consequentially Task Manager claims that the
>> >memory is neither taken by scp, nor by ssh.  Both processes have normal
>> >VM sizes < 10 Megs.  Per Task manager the memory is paged Kernel Memory.
>> >A strange side effect is that the entire time taken by the data
>> >transmission is longer than with -49, by almost exactly the time it
>> >takes to empty the big kernel cache.
>> >
>> >Puzzeling.
>>
>> Is ssh using non-blocking pipes opened for write?  Until a week or two
>> ago, Cygwin didn't support those and treated the non-blocking write as a
>> blocking write.
>
>scp switches the pipes to non-blocking and then tries to do blocking io
>on its own, using the poll() function.  It calls a function called scpio
>which basically work like this:
>
>  scpio (io_function, fd, buf, size)
>  {
>    for (offset = 0; offset < size;) {
>      r = io_function (fd, buf + offset, size - offset);
>      [...]
>      if (r < 0) {
> if (errno == EINTR)
>  continue;
> if (errno == EAGAIN || errno == EWOULDBLOCK) {
>  poll (fd, 1, -1) /* Use poll() for blocking */
>  continue;
> }
> [...]
>      }
>      offset += r;
>    }
>  }
>
>Looks like scp now stumbles over the pipe select() implementation.

Yes.  Grumble.  That's a bad interaction between non-blocking writes and
our stupid-thanks-to-Microsoft select implementation.  I think I can
work around this particular problem though.  I'll get to that this
weekend.

cgf

--
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

[Corinna Vinschen-2]

On Jun 25 16:36, Corinna Vinschen wrote:

> On Jun 25 10:05, Christopher Faylor wrote:
> > Is ssh using non-blocking pipes opened for write?  Until a week or two
> > ago, Cygwin didn't support those and treated the non-blocking write as a
> > blocking write.
>
> scp switches the pipes to non-blocking and then tries to do blocking io
> on its own, using the poll() function.  It calls a function called scpio
> which basically work like this:
>
>   scpio (io_function, fd, buf, size)
>   {
>     for (offset = 0; offset < size;) {
>       r = io_function (fd, buf + offset, size - offset);
>       [...]
>       if (r < 0) {
> if (errno == EINTR)
>  continue;
> if (errno == EAGAIN || errno == EWOULDBLOCK) {
>  poll (fd, 1, -1) /* Use poll() for blocking */
>  continue;
> }
> [...]
>       }
>       offset += r;
>     }
>   }
>
> Looks like scp now stumbles over the pipe select() implementation.

I re-activated the old experimental pipe select code using
NtQueryInformationFile and the result is tha scp is more or less back to
normal.  It's still using a good amount of kernel memory, about 64 Megs,
but it appears to be working much better with this select implementation.
I'm just not sure if that's now really useful as a generic write select on
pipes.

Btw., while playing with this I also tried something like this:

$ cmd
C:\cygwin\home\corinna> type file | ssh linux-box 'cat > file'

This *seems* to do something and it finishes writing at one point without
error message, but only the first 192K of the file are written to the
server.  The rest just disappears.  This is independent of the aforementioned
select method.

However, this works fine:

$ cmd /c type file | ssh linux-box 'cat > file'

AFAICS the difference is just who created the pipe.  In the working case
the pipe got created by Cygwin, in the non-working case it has been
created by cmd.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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

[Corinna Vinschen-2]

On Jun 25 16:58, Corinna Vinschen wrote:
> Btw., while playing with this I also tried something like this:
>
> $ cmd
> C:\cygwin\home\corinna> type file | ssh linux-box 'cat > file'

Ouch!  Ouch, ouch, ouch!

I used single quotes rather than double quotes.

Whom do I have to pay to remove this from the mailing list archives
again?


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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

[Christopher Faylor-8]

On Thu, Jun 25, 2009 at 05:06:06PM +0200, Corinna Vinschen wrote:

>On Jun 25 16:58, Corinna Vinschen wrote:
>> Btw., while playing with this I also tried something like this:
>>
>> $ cmd
>> C:\cygwin\home\corinna> type file | ssh linux-box 'cat > file'
>
>Ouch!  Ouch, ouch, ouch!
>
>I used single quotes rather than double quotes.
>
>Whom do I have to pay to remove this from the mailing list archives
>again?

:-)

So what actually happened?  Did you create a file called " file' "?  Does
this work ok if you use double quotes?

cgf

--
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

[Corinna Vinschen-2]

On Jun 25 11:21, Christopher Faylor wrote:

> On Thu, Jun 25, 2009 at 05:06:06PM +0200, Corinna Vinschen wrote:
> >On Jun 25 16:58, Corinna Vinschen wrote:
> >> Btw., while playing with this I also tried something like this:
> >>
> >> $ cmd
> >> C:\cygwin\home\corinna> type file | ssh linux-box 'cat > file'
> >
> >Ouch!  Ouch, ouch, ouch!
> >
> >I used single quotes rather than double quotes.
> >
> >Whom do I have to pay to remove this from the mailing list archives
> >again?
>
> :-)
>
> So what actually happened?  Did you create a file called " file' "?  Does
> this work ok if you use double quotes?

Yes and yes.  I can't explain the 192K size of the file on the remote
side.  I'm too embarrassed to check but it was almost surly a PEBKAC.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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

[Christopher Faylor-8]

On Thu, Jun 25, 2009 at 10:50:05AM -0400, Christopher Faylor wrote:
>On Thu, Jun 25, 2009 at 04:36:51PM +0200, Corinna Vinschen wrote:
>>Looks like scp now stumbles over the pipe select() implementation.
>
>Yes.  Grumble.  That's a bad interaction between non-blocking writes and
>our stupid-thanks-to-Microsoft select implementation.  I think I can
>work around this particular problem though.  I'll get to that this
>weekend.

This should be fixed in the latest snapshot.  I hated to do it because I
think I've throttled pipe reads and writes somewhat but it should be
more correct now.

However, the new implementation may play more nicely with things like
rsync which hang on pipe writes.

Btw, Corinna, were you proposing turning the "FIXME" code in peek_pipe
back on?  I don't think I ever saw it fail myself after my last round
of tweaks but I don't remember what the exact problem was.  Did it
fail on some version of Windows NT/2000/XP/2003/2008/7?

cgf

--
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

[Corinna Vinschen-2]

On Jun 28 15:31, Christopher Faylor wrote:

> On Thu, Jun 25, 2009 at 10:50:05AM -0400, Christopher Faylor wrote:
> >On Thu, Jun 25, 2009 at 04:36:51PM +0200, Corinna Vinschen wrote:
> >>Looks like scp now stumbles over the pipe select() implementation.
> >
> >Yes.  Grumble.  That's a bad interaction between non-blocking writes and
> >our stupid-thanks-to-Microsoft select implementation.  I think I can
> >work around this particular problem though.  I'll get to that this
> >weekend.
>
> This should be fixed in the latest snapshot.  I hated to do it because I
> think I've throttled pipe reads and writes somewhat but it should be
> more correct now.
>
> However, the new implementation may play more nicely with things like
> rsync which hang on pipe writes.
>
> Btw, Corinna, were you proposing turning the "FIXME" code in peek_pipe
> back on?

I'm a bit wary to do that, but...

>   I don't think I ever saw it fail myself after my last round
> of tweaks but I don't remember what the exact problem was.  Did it
> fail on some version of Windows NT/2000/XP/2003/2008/7?

...I just searched for the old threads and here's where the problem
starts:
http://cygwin.com/ml/cygwin/2004-09/msg00416.html

That led to:
http://cygwin.com/ml/cygwin-patches/2004-q3/msg00091.html

And then there was the Unison problem:
http://cygwin.com/ml/cygwin/2004-09/msg01131.html

Which was subsequently discussed here:
http://cygwin.com/ml/cygwin-patches/2004-q3/msg00133.html

I tested sftp with big files (Gigs) and it appears to work fine with the
FIXME code switched back to life.  I tested the unison command using
Cygwin's unison 2.31.4-2 under tcsh and it worked fine.  I tested
various combinations with pipes created by a native application and with
native applications on send and receive side of a Cygwin pipe and all my
testcases worked as expected.

So, maybe we should really give it a try again.  


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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

[Corinna Vinschen-2]

On Jun 29 11:28, Corinna Vinschen wrote:

> On Jun 28 15:31, Christopher Faylor wrote:
> > Btw, Corinna, were you proposing turning the "FIXME" code in peek_pipe
> > back on?
>
> I'm a bit wary to do that, but...
>
> >   I don't think I ever saw it fail myself after my last round
> > of tweaks but I don't remember what the exact problem was.  Did it
> > fail on some version of Windows NT/2000/XP/2003/2008/7?
>
> ...I just searched for the old threads and here's where the problem
> starts:
> http://cygwin.com/ml/cygwin/2004-09/msg00416.html
>
> That led to:
> http://cygwin.com/ml/cygwin-patches/2004-q3/msg00091.html
>
> And then there was the Unison problem:
> http://cygwin.com/ml/cygwin/2004-09/msg01131.html
>
> Which was subsequently discussed here:
> http://cygwin.com/ml/cygwin-patches/2004-q3/msg00133.html
>
> I tested sftp with big files (Gigs) and it appears to work fine with the
> FIXME code switched back to life.  I tested the unison command using
> Cygwin's unison 2.31.4-2 under tcsh and it worked fine.  I tested
> various combinations with pipes created by a native application and with
> native applications on send and receive side of a Cygwin pipe and all my
> testcases worked as expected.
>
> So, maybe we should really give it a try again.  

Btw., I also tried the rsync of 9000 files with the FIXME code active
and it worked a couple of times in a row without fail.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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

[Christopher Faylor-8]

On Mon, Jun 29, 2009 at 11:53:22AM +0200, Corinna Vinschen wrote:

>On Jun 29 11:28, Corinna Vinschen wrote:
>>On Jun 28 15:31, Christopher Faylor wrote:
>>>Btw, Corinna, were you proposing turning the "FIXME" code in peek_pipe
>>>back on?
>>
>>I'm a bit wary to do that, but...
>>
>>>I don't think I ever saw it fail myself after my last round of tweaks
>>>but I don't remember what the exact problem was.  Did it fail on some
>>>version of Windows NT/2000/XP/2003/2008/7?
>>
>>...I just searched for the old threads and here's where the problem
>>starts: http://cygwin.com/ml/cygwin/2004-09/msg00416.html
>>
>>That led to: http://cygwin.com/ml/cygwin-patches/2004-q3/msg00091.html
>>
>>And then there was the Unison problem:
>>http://cygwin.com/ml/cygwin/2004-09/msg01131.html
>>
>>Which was subsequently discussed here:
>>http://cygwin.com/ml/cygwin-patches/2004-q3/msg00133.html
>>
>>I tested sftp with big files (Gigs) and it appears to work fine with
>>the FIXME code switched back to life.  I tested the unison command
>>using Cygwin's unison 2.31.4-2 under tcsh and it worked fine.  I tested
>>various combinations with pipes created by a native application and
>>with native applications on send and receive side of a Cygwin pipe and
>>all my testcases worked as expected.
>>
>>So, maybe we should really give it a try again.
>
>Btw., I also tried the rsync of 9000 files with the FIXME code active
>and it worked a couple of times in a row without fail.

I did make a change subsequent to your turning off this code.  Maybe
that was enough to get things working.  Either that or, if you are using
the trunk code, maybe you aren't hitting this at all anymore since there
are overlapped I/O accomodations.

Anyway, I wouldn't mind giving the code another try if you are up for
it.  Although I didn't write the code originally, it has always bothered
me that it didn't work because it seems like it should have.

Shall I turn it on, create a snapshot, and then ask our legion of
testers to try it?

cgf

--
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

[Corinna Vinschen-2]

On Jun 29 10:23, Christopher Faylor wrote:

> On Mon, Jun 29, 2009 at 11:53:22AM +0200, Corinna Vinschen wrote:
> >On Jun 29 11:28, Corinna Vinschen wrote:
> >>On Jun 28 15:31, Christopher Faylor wrote:
> >>>Btw, Corinna, were you proposing turning the "FIXME" code in peek_pipe
> >>>back on?
> >>[...]
> >>I tested sftp with big files (Gigs) and it appears to work fine with
> >>the FIXME code switched back to life.  I tested the unison command
> >>using Cygwin's unison 2.31.4-2 under tcsh and it worked fine.  I tested
> >>various combinations with pipes created by a native application and
> >>with native applications on send and receive side of a Cygwin pipe and
> >>all my testcases worked as expected.
> >>
> >>So, maybe we should really give it a try again.
> >
> >Btw., I also tried the rsync of 9000 files with the FIXME code active
> >and it worked a couple of times in a row without fail.
>
> I did make a change subsequent to your turning off this code.  Maybe
> that was enough to get things working.  Either that or, if you are using
> the trunk code, maybe you aren't hitting this at all anymore since there
> are overlapped I/O accomodations.
>
> Anyway, I wouldn't mind giving the code another try if you are up for
> it.  Although I didn't write the code originally, it has always bothered
> me that it didn't work because it seems like it should have.
>
> Shall I turn it on, create a snapshot, and then ask our legion of
> testers to try it?

Sure, go ahead.  I would even go so far as to create a new -51 test
release to get some more testing of this.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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

[Christopher Faylor-8]

On Mon, Jun 29, 2009 at 10:23:48AM -0400, Christopher Faylor wrote:

>On Mon, Jun 29, 2009 at 11:53:22AM +0200, Corinna Vinschen wrote:
>>On Jun 29 11:28, Corinna Vinschen wrote:
>>>On Jun 28 15:31, Christopher Faylor wrote:
>>>>Btw, Corinna, were you proposing turning the "FIXME" code in peek_pipe
>>>>back on?
>>>
>>>I'm a bit wary to do that, but...
>>>
>>>>I don't think I ever saw it fail myself after my last round of tweaks
>>>>but I don't remember what the exact problem was.  Did it fail on some
>>>>version of Windows NT/2000/XP/2003/2008/7?
>>>
>>>...I just searched for the old threads and here's where the problem
>>>starts: http://cygwin.com/ml/cygwin/2004-09/msg00416.html
>>>
>>>That led to: http://cygwin.com/ml/cygwin-patches/2004-q3/msg00091.html
>>>
>>>And then there was the Unison problem:
>>>http://cygwin.com/ml/cygwin/2004-09/msg01131.html
>>>
>>>Which was subsequently discussed here:
>>>http://cygwin.com/ml/cygwin-patches/2004-q3/msg00133.html
>>>
>>>I tested sftp with big files (Gigs) and it appears to work fine with
>>>the FIXME code switched back to life.  I tested the unison command
>>>using Cygwin's unison 2.31.4-2 under tcsh and it worked fine.  I tested
>>>various combinations with pipes created by a native application and
>>>with native applications on send and receive side of a Cygwin pipe and
>>>all my testcases worked as expected.
>>>
>>>So, maybe we should really give it a try again.
>>
>>Btw., I also tried the rsync of 9000 files with the FIXME code active
>>and it worked a couple of times in a row without fail.
>
>I did make a change subsequent to your turning off this code.  Maybe
>that was enough to get things working.  Either that or, if you are using
>the trunk code, maybe you aren't hitting this at all anymore since there
>are overlapped I/O accomodations.
>
>Anyway, I wouldn't mind giving the code another try if you are up for
>it.  Although I didn't write the code originally, it has always bothered
>me that it didn't work because it seems like it should have.
>
>Shall I turn it on, create a snapshot, and then ask our legion of
>testers to try it?

I'm going to assume the answer is yes and I'm leaving for a little
while, I'm generating a snapshot now.

So what I'd appreciate from the Cygwin community is to read the URLs
above and then try out the snapshot.  We're trying to find out if it is
worth turning on some code in Cygwin which improves the handling of
pipes.  This snapshot has the code on.

I'd like to get as much OS coverage as possible so if you could reply
here with:

1) Windows version NT3.5/NT4/XP/2000/2003/2008/7, etc.

2) Success/failure.  Success would be no hangs.  Failure would be a hang
or a Cygwin "panic".

3) Any additional notes like "seems faster", "seems slower", "no
change".

If a failure is noted then please give as many details as possible.

The snapshot will be available at http://cygwin.com/snapshots/ with today's
(2009-06-29) date.

cgf

--
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

[Christopher Faylor-8]

On Mon, Jun 29, 2009 at 04:38:40PM +0200, Corinna Vinschen wrote:

>On Jun 29 10:23, Christopher Faylor wrote:
>> On Mon, Jun 29, 2009 at 11:53:22AM +0200, Corinna Vinschen wrote:
>> >On Jun 29 11:28, Corinna Vinschen wrote:
>> >>On Jun 28 15:31, Christopher Faylor wrote:
>> >>>Btw, Corinna, were you proposing turning the "FIXME" code in peek_pipe
>> >>>back on?
>> >>[...]
>> >>I tested sftp with big files (Gigs) and it appears to work fine with
>> >>the FIXME code switched back to life.  I tested the unison command
>> >>using Cygwin's unison 2.31.4-2 under tcsh and it worked fine.  I tested
>> >>various combinations with pipes created by a native application and
>> >>with native applications on send and receive side of a Cygwin pipe and
>> >>all my testcases worked as expected.
>> >>
>> >>So, maybe we should really give it a try again.
>> >
>> >Btw., I also tried the rsync of 9000 files with the FIXME code active
>> >and it worked a couple of times in a row without fail.
>>
>> I did make a change subsequent to your turning off this code.  Maybe
>> that was enough to get things working.  Either that or, if you are using
>> the trunk code, maybe you aren't hitting this at all anymore since there
>> are overlapped I/O accomodations.
>>
>> Anyway, I wouldn't mind giving the code another try if you are up for
>> it.  Although I didn't write the code originally, it has always bothered
>> me that it didn't work because it seems like it should have.
>>
>> Shall I turn it on, create a snapshot, and then ask our legion of
>> testers to try it?
>
>Sure, go ahead.  I would even go so far as to create a new -51 test
>release to get some more testing of this.

How about if we do that after seeing what happens with the snapshot
(especially since I already sent the email :-|)?

If we get good preliminary reports then a new version is certainly
called for.

--
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

[Corinna Vinschen-2]

On Jun 29 10:42, Christopher Faylor wrote:

> On Mon, Jun 29, 2009 at 04:38:40PM +0200, Corinna Vinschen wrote:
> >On Jun 29 10:23, Christopher Faylor wrote:
> >> On Mon, Jun 29, 2009 at 11:53:22AM +0200, Corinna Vinschen wrote:
> >> >On Jun 29 11:28, Corinna Vinschen wrote:
> >> >>On Jun 28 15:31, Christopher Faylor wrote:
> >> >>>Btw, Corinna, were you proposing turning the "FIXME" code in peek_pipe
> >> >>>back on?
> >> >>[...]
> >> >>I tested sftp with big files (Gigs) and it appears to work fine with
> >> >>the FIXME code switched back to life.  I tested the unison command
> >> >>using Cygwin's unison 2.31.4-2 under tcsh and it worked fine.  I tested
> >> >>various combinations with pipes created by a native application and
> >> >>with native applications on send and receive side of a Cygwin pipe and
> >> >>all my testcases worked as expected.
> >> >>
> >> >>So, maybe we should really give it a try again.
> >> >
> >> >Btw., I also tried the rsync of 9000 files with the FIXME code active
> >> >and it worked a couple of times in a row without fail.
> >>
> >> I did make a change subsequent to your turning off this code.  Maybe
> >> that was enough to get things working.  Either that or, if you are using
> >> the trunk code, maybe you aren't hitting this at all anymore since there
> >> are overlapped I/O accomodations.
> >>
> >> Anyway, I wouldn't mind giving the code another try if you are up for
> >> it.  Although I didn't write the code originally, it has always bothered
> >> me that it didn't work because it seems like it should have.
> >>
> >> Shall I turn it on, create a snapshot, and then ask our legion of
> >> testers to try it?
> >
> >Sure, go ahead.  I would even go so far as to create a new -51 test
> >release to get some more testing of this.
>
> How about if we do that after seeing what happens with the snapshot
> (especially since I already sent the email :-|)?
>
> If we get good preliminary reports then a new version is certainly
> called for.

Fine with me.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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

[Chris Sutcliffe-2]

> The snapshot will be available at http://cygwin.com/snapshots/ with today's
> (2009-06-29) date.

I have tested with a 695 MB file and validated that scp and lftp work
as expected with a constant throughput.

Chris

--
Chris Sutcliffe
http://emergedesktop.org

--
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

[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

[Corinna Vinschen-2]

On Jun 29 12:59, Warren Young wrote:

> 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.

I just had a look into this and I think I found a way to raise the
outbound transfer rates somewhat.  The outbound speed is always slower
than the inbound speed, no matter what I try.  However, I'm now at a
point where it might be more acceptable.

One of my test machines, a 2K8 32 bit box has the following scp
transfer rates under 1.5.25:

  inbound:  17.2 MB/s
  outbound:  3.5 MB/s

With the latest snapshot:

  inbound:  21.5 MB/s
  outbound:  4.2 MB/s

With the latest from CVS:

  inbound:  21.5 MB/s
  outbound: 11.5 MB/s

What's still not clear is why the ssh process takes so much CPU.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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