[ANNOUNCEMENT] Updated: cygutils 1.4.16-5

[Mark Geisert]

The following packages have been uploaded to the Cygwin distribution:

* cygutils-1.4.16-5
* cygutils-extra-1.4.16-5
* cygutils-x11-1.4.16-5

This release fixes a couple of issues reported in -4test.  I decided
rather than respinning -4 as a non-test release, to just bump to -5.

Unicode capture from the Windows clipboard with getclip and Unicode
display to the Windows clipboard with putclip should now be working
properly.  Thank you to those who reported issues with the previous
builds, both privately and on the main Cygwin mailing list.

Excerpt from ChangeLog follows...
2021-08-24  Mark Geisert(release 1.4.16-5)

* src/clip/putclip.c: Fix broken Unicode support. Don't GlobalFree a
handle that's been transferred to the system by SetClipboardData().
Thanks to Christian Franke for that last bit.

2021-08-15  Mark Geisert(release 1.4.16-4test)

* Makefile.am: Add -lkernel32 to src_clip_getclip_LDADD.  This somehow
didn't make it into the released -3 package.  Thank you Takashi Yano.
* Fix maintainer build environment issues that caused cygstart crash
on non-AVX user systems: Thank you Takashi Yano, Brian Inglis, Achim
Gratz and user Jay Abel for reporting the issue.
* src/cygdrop/cygdrop.cc: Fix crash with recent gcc and fix printf
format strings. Thank you Christian Franke.

2021-07-05  Mark Geisert(release 1.4.16-3)

* src/clip/getclip.c: Add Unicode support.

I plan to update the public source repository for cygutils over the next
couple weeks.  Then after that it's revisiting the whole source tree to
make corrections to allow compilation with gcc 11.  That will be 1.4.17.
Cheers & Regards,

..mark

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

Updated: cygutils 1.4.16-5

[Mark Geisert]

The following packages have been uploaded to the Cygwin distribution:

* cygutils-1.4.16-5
* cygutils-extra-1.4.16-5
* cygutils-x11-1.4.16-5

This release fixes a couple of issues reported in -4test.  I decided
rather than respinning -4 as a non-test release, to just bump to -5.

Unicode capture from the Windows clipboard with getclip and Unicode
display to the Windows clipboard with putclip should now be working
properly.  Thank you to those who reported issues with the previous
builds, both privately and on the main Cygwin mailing list.

Excerpt from ChangeLog follows...
2021-08-24  Mark Geisert(release 1.4.16-5)

* src/clip/putclip.c: Fix broken Unicode support. Don't GlobalFree a
handle that's been transferred to the system by SetClipboardData().
Thanks to Christian Franke for that last bit.

2021-08-15  Mark Geisert(release 1.4.16-4test)

* Makefile.am: Add -lkernel32 to src_clip_getclip_LDADD.  This somehow
didn't make it into the released -3 package.  Thank you Takashi Yano.
* Fix maintainer build environment issues that caused cygstart crash
on non-AVX user systems: Thank you Takashi Yano, Brian Inglis, Achim
Gratz and user Jay Abel for reporting the issue.
* src/cygdrop/cygdrop.cc: Fix crash with recent gcc and fix printf
format strings. Thank you Christian Franke.

2021-07-05  Mark Geisert(release 1.4.16-3)

* src/clip/getclip.c: Add Unicode support.

I plan to update the public source repository for cygutils over the next
couple weeks.  Then after that it's revisiting the whole source tree to
make corrections to allow compilation with gcc 11.  That will be 1.4.17.
Cheers & Regards,

..mark

Request for catalogue

[David Liu via Cygwin]

Hello cygwin@cygwin.com

I am David from IMEX sourcing company. Our customer finds your product 
interesting, as such we request that you send an official catalogue so we can 
send PO. Also be informed that our company charges 4% of the value of goods 
bought from the supplier which will be included in the proforma invoice.

Thanks and best regards. we await your earliest reply.

David Liu
IMEX Sourcing service 
E-mail: 

o-lightin...@ovovs.com mailto:o-lightin...@ovovs.com

Phone: +86 1326532 2461
Wechat: markkyyo

https://imexsourcingservices.com/

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

Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?

[Takashi Yano via Cygwin]

On Wed, 25 Aug 2021 13:52:19 -0400
Ken Brown wrote:
> On 8/25/2021 7:18 AM, Takashi Yano via Cygwin wrote:
> > On Tue, 24 Aug 2021 12:49:52 -0700
> > Chris Roehrig wrote:
> >> I have a network of Windows, Linux and Mac machines and I use rsync to 
> >> synchronize various directories between them.
> >>
> >> I'm trying to figure out why my rsync transfers are so slow (<4 MB/s) only 
> >> when the remote endpoint is Cygwin rsync over sshd (with both a Linux or 
> >> Cygwin rsync client).   In all other scenarios, I get the full 100MB/s as 
> >> expected from gigabit ethernet.  This has been an ongoing problem for me 
> >> for a couple of years over several Windows and Cygwin versions, and I'd 
> >> like to try to fix it.
> >>
> >> If I run rsync --daemon --no-detach under mintty in the foreground on the 
> >> remote Windows endpoint,  I get the full 100 MB/s transfers, so it seems 
> >> like it has something to do with rsync.exe running in the background under 
> >> the cygrunsrv+sshd service (which was installed normally using 
> >> ssh-host-config).
> >>
> >> If I do:
> >>pv /dev/zero | ssh $WINHOST "cat > /dev/null"
> >> or even
> >>pv /dev/urandom | ssh $WINHOST md5sum
> >> I also get the full 100 MB/s transfers, so it doesn't look like sshd 
> >> itself is being throttled by bandwidth or CPU.
> >>
> >> The machines have less than 15% CPU utilization while transferring, with 
> >> each of the 4 cores less than 30%, so it doesn't look to be CPU issue.
> >> In Task Manager, sshd.exe and rsync.exe seem to be running normally using 
> >> only few percent CPU, and show Power Throttling=Disabled, Priority=Normal. 
> >>   Setting their Priority to High doesn't seem to change things.
> >>
> >> Looking in Resource Monitor on the remote endpoint, the network usage is 
> >> pretty much a flat horizontal line at about 18 Mbps (2.5 MB/s), so it sure 
> >> looks to me as if rsync is somehow being bandwidth-throttled when run in 
> >> the background under cygsshd.
> >>
> >> It's almost as if rsync has an implicit --bwlimit override when it is run 
> >> from cygrunsrv+sshd (I've tried --bwlimit=0 on the client which makes no 
> >> difference).
> >>
> >>
> >> Any ideas?Not sure where to go from here.
> > 
> > In cygwin, just scp is very slow.
> > 
> > The transfer speed in my environment is as follows.
> > The tests were done with 100MB of test.dat file.
> > 
> > (1-1) From cygwin-PC,
> > [yano@cygwin-PC ~]$ scp test.dat yano@linux-server:.
> > yano@linux-server's password:
> > test.dat  100%  100MB   4.0MB/s   00:24
> > [yano@cygwin-PC ~]$ scp yano@linux-server:test.dat .
> > yano@linux-server's password:
> > test.dat  100%  100MB   8.0MB/s   00:12
> > 
> > (1-2) From linux-server,
> > yano@linux-server:~$ scp yano@cygwin-PC:test.dat .
> > yano@cygwin-PC's password:
> > test.dat  100%  100MB   4.0MB/s   00:24
> > yano@linux-server:~$ scp test.dat yano@cygwin-PC:.
> > yano@cygwin-PC's password:
> > test.dat  100%  100MB   4.1MB/s   00:24
> > 
> > 
> > I looked into this problem, and noticed that this is caused
> > by cygwin pipe implementation. Pipe in cygwin is configured
> > with FILE_FLAG_OVERLAPPED.
> > 
> > If the pipe is configured without FILE_FLAG_OVERLAPPED,
> > the transfer speed is much improved as follows.
> > 
> > 
> > (2-1) From cygwin-PC,
> > [yano@cygwin-PC ~]$ scp test.dat yano@linux-server:.
> > yano@linux-server's password:
> > test.dat  100%  100MB  85.5MB/s   00:01
> > [yano@cygwin-PC ~]$ scp yano@linux-server:test.dat .
> > yano@linux-server's password:
> > test.dat  100%  100MB  69.7MB/s   00:01
> > 
> > (2-2) From linux-server,
> > yano@linux-server:~$ scp yano@cygwin-PC:test.dat .
> > yano@cygwin-PC's password:
> > test.dat  100%  100MB  80.1MB/s   00:01
> > yano@linux-server:~$ scp test.dat yano@cygwin-PC:.
> > yano@cygwin-PC's password:
> > test.dat  100%  100MB  57.7MB/s   00:01
> > 
> > I am not sure why this happens and how to fix this.
> 
> A couple years ago I had an idea for changing the pipe implementation to 
> avoid 
> overlapped I/O:
> 
>https://cygwin.com/pipermail/cygwin-patches/2019q2/009393.html
>https://cygwin.com/pipermail/cygwin-patches/2019q2/009423.html
> 
> I never followed up on it.  But if you think it might help with this problem, 
> I 
> could dust it off and try to finish it.

Interesting.

It will be also helpfull for:
https://cygwin.com/pipermail/cygwin/2021-March/247987.html
which seems to be the same issue with
https://stackoverflow.com/questions/10385424/good-alternatives-to-cygwin-cygwin-doesnt-support-natively-support-win32-app

However, I wonder why scp dislikes overlapped I/O.

-- 
Takashi Yano 

-- 
Problem reports:  https://cygwin.com/problems.html

Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?

[Mario Emmenlauer]

On 25.08.21 19:52, Ken Brown via Cygwin wrote:

A couple years ago I had an idea for changing the pipe implementation to avoid 
overlapped I/O:

   https://cygwin.com/pipermail/cygwin-patches/2019q2/009393.html
   https://cygwin.com/pipermail/cygwin-patches/2019q2/009423.html

I never followed up on it.  But if you think it might help with this problem, I 
could dust it off and try to finish it.


This sounds quite interesting! Do I assume correctly that these
changes may likely lead to a general improvement also in other
situations if the impact of the pipe is so big for this specific
case? Pipes are most likely used in quite a lot of scenarios?!

All the best,

Mario Emmenlauer

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

Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?

[Chris Roehrig]

It looks like there was a previous (2013) patch and attempt to add a 
pipe_nooverlap CYGWIN option that was rejected by the maintainers:

https://stackoverflow.com/questions/10385424/good-alternatives-to-cygwin-cygwin-doesnt-support-natively-support-win32-app

Is this something that can be revisited?It seems to be affecting pure-UNIX 
situations (in my case) which is Cygwin's core audience.

- Chris


On Wed Aug 25 2021, at 11:18 AM, Chris Roehrig  wrote:

> On Wed Aug 25 2021, at 10:52 AM, Ken Brown via Cygwin  
> wrote:
>> A couple years ago I had an idea for changing the pipe implementation to 
>> avoid overlapped I/O:
>> 
>> https://cygwin.com/pipermail/cygwin-patches/2019q2/009393.html
>> https://cygwin.com/pipermail/cygwin-patches/2019q2/009423.html
>> 
>> I never followed up on it.  But if you think it might help with this 
>> problem, I could dust it off and try to finish it.
>> 
>> Ken
> 
> I'm not familiar enough with the innards of rsync, sshd or cygwin to know how 
> this would work.
> Is it possible to have a new CYGWIN environment option to switch the pipe 
> behaviour without requiring changes to the ssh or rsync source code (and 
> without breaking any existing stuff)?
> 
> - Chris
> 
> 
> 
>> On 8/25/2021 7:18 AM, Takashi Yano via Cygwin wrote:
>>> On Tue, 24 Aug 2021 12:49:52 -0700
>>> Chris Roehrig wrote:
 I have a network of Windows, Linux and Mac machines and I use rsync to 
 synchronize various directories between them.
 
 I'm trying to figure out why my rsync transfers are so slow (<4 MB/s) only 
 when the remote endpoint is Cygwin rsync over sshd (with both a Linux or 
 Cygwin rsync client).   In all other scenarios, I get the full 100MB/s as 
 expected from gigabit ethernet.  This has been an ongoing problem for me 
 for a couple of years over several Windows and Cygwin versions, and I'd 
 like to try to fix it.
 
 If I run rsync --daemon --no-detach under mintty in the foreground on the 
 remote Windows endpoint,  I get the full 100 MB/s transfers, so it seems 
 like it has something to do with rsync.exe running in the background under 
 the cygrunsrv+sshd service (which was installed normally using 
 ssh-host-config).
 
 If I do:
pv /dev/zero | ssh $WINHOST "cat > /dev/null"
 or even
pv /dev/urandom | ssh $WINHOST md5sum
 I also get the full 100 MB/s transfers, so it doesn't look like sshd 
 itself is being throttled by bandwidth or CPU.
 
 The machines have less than 15% CPU utilization while transferring, with 
 each of the 4 cores less than 30%, so it doesn't look to be CPU issue.
 In Task Manager, sshd.exe and rsync.exe seem to be running normally using 
 only few percent CPU, and show Power Throttling=Disabled, Priority=Normal. 
   Setting their Priority to High doesn't seem to change things.
 
 Looking in Resource Monitor on the remote endpoint, the network usage is 
 pretty much a flat horizontal line at about 18 Mbps (2.5 MB/s), so it sure 
 looks to me as if rsync is somehow being bandwidth-throttled when run in 
 the background under cygsshd.
 
 It's almost as if rsync has an implicit --bwlimit override when it is run 
 from cygrunsrv+sshd (I've tried --bwlimit=0 on the client which makes no 
 difference).
 
 
 Any ideas?Not sure where to go from here.
>>> In cygwin, just scp is very slow.
>>> The transfer speed in my environment is as follows.
>>> The tests were done with 100MB of test.dat file.
>>> (1-1) From cygwin-PC,
>>> [yano@cygwin-PC ~]$ scp test.dat yano@linux-server:.
>>> yano@linux-server's password:
>>> test.dat  100%  100MB   4.0MB/s   00:24
>>> [yano@cygwin-PC ~]$ scp yano@linux-server:test.dat .
>>> yano@linux-server's password:
>>> test.dat  100%  100MB   8.0MB/s   00:12
>>> (1-2) From linux-server,
>>> yano@linux-server:~$ scp yano@cygwin-PC:test.dat .
>>> yano@cygwin-PC's password:
>>> test.dat  100%  100MB   4.0MB/s   00:24
>>> yano@linux-server:~$ scp test.dat yano@cygwin-PC:.
>>> yano@cygwin-PC's password:
>>> test.dat  100%  100MB   4.1MB/s   00:24
>>> I looked into this problem, and noticed that this is caused
>>> by cygwin pipe implementation. Pipe in cygwin is configured
>>> with FILE_FLAG_OVERLAPPED.
>>> If the pipe is configured without FILE_FLAG_OVERLAPPED,
>>> the transfer speed is much improved as follows.
>>> (2-1) From cygwin-PC,
>>> [yano@cygwin-PC ~]$ scp test.dat yano@linux-server:.
>>> yano@linux-server's password:
>>> test.dat  100%  100MB  85.5MB/s   00:01
>>> [yano@cygwin-PC ~]$ scp yano@linux-server:test.dat .
>>> yano@linux-server's password:
>>> test.dat  100%  100MB  69.7MB/s   00:01
>>> (2-2) From linux-server,
>>> yano@linux-server:~$ scp 

Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?

[Chris Roehrig]

On Wed Aug 25 2021, at 10:52 AM, Ken Brown via Cygwin  wrote:
> A couple years ago I had an idea for changing the pipe implementation to 
> avoid overlapped I/O:
> 
>  https://cygwin.com/pipermail/cygwin-patches/2019q2/009393.html
>  https://cygwin.com/pipermail/cygwin-patches/2019q2/009423.html
> 
> I never followed up on it.  But if you think it might help with this problem, 
> I could dust it off and try to finish it.
> 
> Ken

I'm not familiar enough with the innards of rsync, sshd or cygwin to know how 
this would work.
Is it possible to have a new CYGWIN environment option to switch the pipe 
behaviour without requiring changes to the ssh or rsync source code (and 
without breaking any existing stuff)?

- Chris



> On 8/25/2021 7:18 AM, Takashi Yano via Cygwin wrote:
>> On Tue, 24 Aug 2021 12:49:52 -0700
>> Chris Roehrig wrote:
>>> I have a network of Windows, Linux and Mac machines and I use rsync to 
>>> synchronize various directories between them.
>>> 
>>> I'm trying to figure out why my rsync transfers are so slow (<4 MB/s) only 
>>> when the remote endpoint is Cygwin rsync over sshd (with both a Linux or 
>>> Cygwin rsync client).   In all other scenarios, I get the full 100MB/s as 
>>> expected from gigabit ethernet.  This has been an ongoing problem for me 
>>> for a couple of years over several Windows and Cygwin versions, and I'd 
>>> like to try to fix it.
>>> 
>>> If I run rsync --daemon --no-detach under mintty in the foreground on the 
>>> remote Windows endpoint,  I get the full 100 MB/s transfers, so it seems 
>>> like it has something to do with rsync.exe running in the background under 
>>> the cygrunsrv+sshd service (which was installed normally using 
>>> ssh-host-config).
>>> 
>>> If I do:
>>> pv /dev/zero | ssh $WINHOST "cat > /dev/null"
>>> or even
>>> pv /dev/urandom | ssh $WINHOST md5sum
>>> I also get the full 100 MB/s transfers, so it doesn't look like sshd itself 
>>> is being throttled by bandwidth or CPU.
>>> 
>>> The machines have less than 15% CPU utilization while transferring, with 
>>> each of the 4 cores less than 30%, so it doesn't look to be CPU issue.
>>> In Task Manager, sshd.exe and rsync.exe seem to be running normally using 
>>> only few percent CPU, and show Power Throttling=Disabled, Priority=Normal.  
>>>  Setting their Priority to High doesn't seem to change things.
>>> 
>>> Looking in Resource Monitor on the remote endpoint, the network usage is 
>>> pretty much a flat horizontal line at about 18 Mbps (2.5 MB/s), so it sure 
>>> looks to me as if rsync is somehow being bandwidth-throttled when run in 
>>> the background under cygsshd.
>>> 
>>> It's almost as if rsync has an implicit --bwlimit override when it is run 
>>> from cygrunsrv+sshd (I've tried --bwlimit=0 on the client which makes no 
>>> difference).
>>> 
>>> 
>>> Any ideas?Not sure where to go from here.
>> In cygwin, just scp is very slow.
>> The transfer speed in my environment is as follows.
>> The tests were done with 100MB of test.dat file.
>> (1-1) From cygwin-PC,
>> [yano@cygwin-PC ~]$ scp test.dat yano@linux-server:.
>> yano@linux-server's password:
>> test.dat  100%  100MB   4.0MB/s   00:24
>> [yano@cygwin-PC ~]$ scp yano@linux-server:test.dat .
>> yano@linux-server's password:
>> test.dat  100%  100MB   8.0MB/s   00:12
>> (1-2) From linux-server,
>> yano@linux-server:~$ scp yano@cygwin-PC:test.dat .
>> yano@cygwin-PC's password:
>> test.dat  100%  100MB   4.0MB/s   00:24
>> yano@linux-server:~$ scp test.dat yano@cygwin-PC:.
>> yano@cygwin-PC's password:
>> test.dat  100%  100MB   4.1MB/s   00:24
>> I looked into this problem, and noticed that this is caused
>> by cygwin pipe implementation. Pipe in cygwin is configured
>> with FILE_FLAG_OVERLAPPED.
>> If the pipe is configured without FILE_FLAG_OVERLAPPED,
>> the transfer speed is much improved as follows.
>> (2-1) From cygwin-PC,
>> [yano@cygwin-PC ~]$ scp test.dat yano@linux-server:.
>> yano@linux-server's password:
>> test.dat  100%  100MB  85.5MB/s   00:01
>> [yano@cygwin-PC ~]$ scp yano@linux-server:test.dat .
>> yano@linux-server's password:
>> test.dat  100%  100MB  69.7MB/s   00:01
>> (2-2) From linux-server,
>> yano@linux-server:~$ scp yano@cygwin-PC:test.dat .
>> yano@cygwin-PC's password:
>> test.dat  100%  100MB  80.1MB/s   00:01
>> yano@linux-server:~$ scp test.dat yano@cygwin-PC:.
>> yano@cygwin-PC's password:
>> test.dat  100%  100MB  57.7MB/s   00:01
>> I am not sure why this happens and how to fix this.
> 
> 
> 
> -- 
> Problem reports:  https://cygwin.com/problems.html
> FAQ:  https://cygwin.com/faq/
> Documentation:https://cygwin.com/docs.html
> Unsubscribe info: 

Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?

[Ken Brown via Cygwin]

On 8/25/2021 7:18 AM, Takashi Yano via Cygwin wrote:

On Tue, 24 Aug 2021 12:49:52 -0700
Chris Roehrig wrote:

I have a network of Windows, Linux and Mac machines and I use rsync to 
synchronize various directories between them.

I'm trying to figure out why my rsync transfers are so slow (<4 MB/s) only when 
the remote endpoint is Cygwin rsync over sshd (with both a Linux or Cygwin rsync 
client).   In all other scenarios, I get the full 100MB/s as expected from gigabit 
ethernet.  This has been an ongoing problem for me for a couple of years over 
several Windows and Cygwin versions, and I'd like to try to fix it.

If I run rsync --daemon --no-detach under mintty in the foreground on the 
remote Windows endpoint,  I get the full 100 MB/s transfers, so it seems like 
it has something to do with rsync.exe running in the background under the 
cygrunsrv+sshd service (which was installed normally using ssh-host-config).

If I do:
pv /dev/zero | ssh $WINHOST "cat > /dev/null"
or even
pv /dev/urandom | ssh $WINHOST md5sum
I also get the full 100 MB/s transfers, so it doesn't look like sshd itself is 
being throttled by bandwidth or CPU.

The machines have less than 15% CPU utilization while transferring, with each 
of the 4 cores less than 30%, so it doesn't look to be CPU issue.
In Task Manager, sshd.exe and rsync.exe seem to be running normally using only 
few percent CPU, and show Power Throttling=Disabled, Priority=Normal.   Setting 
their Priority to High doesn't seem to change things.

Looking in Resource Monitor on the remote endpoint, the network usage is pretty 
much a flat horizontal line at about 18 Mbps (2.5 MB/s), so it sure looks to me 
as if rsync is somehow being bandwidth-throttled when run in the background 
under cygsshd.

It's almost as if rsync has an implicit --bwlimit override when it is run from 
cygrunsrv+sshd (I've tried --bwlimit=0 on the client which makes no difference).


Any ideas?Not sure where to go from here.


In cygwin, just scp is very slow.

The transfer speed in my environment is as follows.
The tests were done with 100MB of test.dat file.

(1-1) From cygwin-PC,
[yano@cygwin-PC ~]$ scp test.dat yano@linux-server:.
yano@linux-server's password:
test.dat  100%  100MB   4.0MB/s   00:24
[yano@cygwin-PC ~]$ scp yano@linux-server:test.dat .
yano@linux-server's password:
test.dat  100%  100MB   8.0MB/s   00:12

(1-2) From linux-server,
yano@linux-server:~$ scp yano@cygwin-PC:test.dat .
yano@cygwin-PC's password:
test.dat  100%  100MB   4.0MB/s   00:24
yano@linux-server:~$ scp test.dat yano@cygwin-PC:.
yano@cygwin-PC's password:
test.dat  100%  100MB   4.1MB/s   00:24


I looked into this problem, and noticed that this is caused
by cygwin pipe implementation. Pipe in cygwin is configured
with FILE_FLAG_OVERLAPPED.

If the pipe is configured without FILE_FLAG_OVERLAPPED,
the transfer speed is much improved as follows.


(2-1) From cygwin-PC,
[yano@cygwin-PC ~]$ scp test.dat yano@linux-server:.
yano@linux-server's password:
test.dat  100%  100MB  85.5MB/s   00:01
[yano@cygwin-PC ~]$ scp yano@linux-server:test.dat .
yano@linux-server's password:
test.dat  100%  100MB  69.7MB/s   00:01

(2-2) From linux-server,
yano@linux-server:~$ scp yano@cygwin-PC:test.dat .
yano@cygwin-PC's password:
test.dat  100%  100MB  80.1MB/s   00:01
yano@linux-server:~$ scp test.dat yano@cygwin-PC:.
yano@cygwin-PC's password:
test.dat  100%  100MB  57.7MB/s   00:01

I am not sure why this happens and how to fix this.


A couple years ago I had an idea for changing the pipe implementation to avoid 
overlapped I/O:


  https://cygwin.com/pipermail/cygwin-patches/2019q2/009393.html
  https://cygwin.com/pipermail/cygwin-patches/2019q2/009423.html

I never followed up on it.  But if you think it might help with this problem, I 
could dust it off and try to finish it.


Ken

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

Re: Bug: Emojis () are replaced by unicode replacement character (�) on Windows Terminal

[Brian Inglis]

On 2021-08-25 07:50, Thomas Wolff wrote:

Am 25.08.2021 um 13:48 schrieb Rafael Kuhn via Cygwin:

Using the shell that comes embedded with 'Git for windows' (that includes
Cygwin) and opening it in Windows Terminal, there's a bug that 
prevents me

from pasting types of unicode characters like emojis in the terminal.

I've opened a ticket in the git-for-windows repo and after testing 
over the

problem they concluded it was Cygwin's problem and told me to report it
here (ticket link below).
https://github.com/git-for-windows/git/issues/3281

The complete description of the problem from people that understand it 
more

than I actually do is in the ticket.

I'm including cygcheck.out like your guide suggests.
Thank you for your time, cheers.

I doubt this is a cygwin issue. Do any emojis run in that environment? 
Does it work in the "Git Bash" terminal? Why would you run git bash in 
Windows Terminal?


Works Just Fine For Me under mintty, configured with charset encoding 
UTF-8 (for Windows cmd use chcp 65001 IIRC), font DejaVu Sans Mono 
(Cygwin package dejavu-fonts).


Depending on your font selection, you may have to add fallbacks, using 
Windows font linking (below); using e.g. GNU Unifont (Cygwin package 
unifont-fonts), Unicode BMP Fallback SIL font, and Apple's Unicode Last 
Resort font; see:


https://en.wikipedia.org/wiki/Fallback_font


https://docs.microsoft.com/en-us/globalization/input/font-technology#font-linking

MS has added Seguiemj.ttf "Segoe UI Emoji" containing some recent emojis 
to recent Windows.


NOTE: Cygwin font installation only makes it available to Cygwin console 
graphics (e.g. gnuplot, R) and GUI apps using libfontconfig, it does not 
make it available to Windows apps, you have to install the OTF/TTF files 
manually from Explorer as usual.


--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

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

Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?

[Chris Roehrig]

The FILE_FLAG_OVERLAPPED avenue looks promising. I get exactly the same 
results as you using 'scp':   4MB/s in either direction (with either remote 
endpoint.)

I guess the next step is to install a build environment and build rsync and 
sshd ...





On Wed Aug 25 2021, at 4:18 AM, Takashi Yano via Cygwin  
wrote:

> On Tue, 24 Aug 2021 12:49:52 -0700
> Chris Roehrig wrote:
>> I have a network of Windows, Linux and Mac machines and I use rsync to 
>> synchronize various directories between them.
>> 
>> I'm trying to figure out why my rsync transfers are so slow (<4 MB/s) only 
>> when the remote endpoint is Cygwin rsync over sshd (with both a Linux or 
>> Cygwin rsync client).   In all other scenarios, I get the full 100MB/s as 
>> expected from gigabit ethernet.  This has been an ongoing problem for me for 
>> a couple of years over several Windows and Cygwin versions, and I'd like to 
>> try to fix it.
>> 
>> If I run rsync --daemon --no-detach under mintty in the foreground on the 
>> remote Windows endpoint,  I get the full 100 MB/s transfers, so it seems 
>> like it has something to do with rsync.exe running in the background under 
>> the cygrunsrv+sshd service (which was installed normally using 
>> ssh-host-config).
>> 
>> If I do:
>>  pv /dev/zero | ssh $WINHOST "cat > /dev/null"
>> or even
>>  pv /dev/urandom | ssh $WINHOST md5sum
>> I also get the full 100 MB/s transfers, so it doesn't look like sshd itself 
>> is being throttled by bandwidth or CPU.
>> 
>> The machines have less than 15% CPU utilization while transferring, with 
>> each of the 4 cores less than 30%, so it doesn't look to be CPU issue.
>> In Task Manager, sshd.exe and rsync.exe seem to be running normally using 
>> only few percent CPU, and show Power Throttling=Disabled, Priority=Normal.   
>> Setting their Priority to High doesn't seem to change things.
>> 
>> Looking in Resource Monitor on the remote endpoint, the network usage is 
>> pretty much a flat horizontal line at about 18 Mbps (2.5 MB/s), so it sure 
>> looks to me as if rsync is somehow being bandwidth-throttled when run in 
>> the background under cygsshd.
>> 
>> It's almost as if rsync has an implicit --bwlimit override when it is run 
>> from cygrunsrv+sshd (I've tried --bwlimit=0 on the client which makes no 
>> difference).
>> 
>> 
>> Any ideas?Not sure where to go from here. 
> 
> In cygwin, just scp is very slow.
> 
> The transfer speed in my environment is as follows.
> The tests were done with 100MB of test.dat file.
> 
> (1-1) From cygwin-PC,
> [yano@cygwin-PC ~]$ scp test.dat yano@linux-server:.
> yano@linux-server's password:
> test.dat  100%  100MB   4.0MB/s   00:24
> [yano@cygwin-PC ~]$ scp yano@linux-server:test.dat .
> yano@linux-server's password:
> test.dat  100%  100MB   8.0MB/s   00:12
> 
> (1-2) From linux-server,
> yano@linux-server:~$ scp yano@cygwin-PC:test.dat .
> yano@cygwin-PC's password:
> test.dat  100%  100MB   4.0MB/s   00:24
> yano@linux-server:~$ scp test.dat yano@cygwin-PC:.
> yano@cygwin-PC's password:
> test.dat  100%  100MB   4.1MB/s   00:24
> 
> 
> I looked into this problem, and noticed that this is caused
> by cygwin pipe implementation. Pipe in cygwin is configured
> with FILE_FLAG_OVERLAPPED.
> 
> If the pipe is configured without FILE_FLAG_OVERLAPPED,
> the transfer speed is much improved as follows.
> 
> 
> (2-1) From cygwin-PC,
> [yano@cygwin-PC ~]$ scp test.dat yano@linux-server:.
> yano@linux-server's password:
> test.dat  100%  100MB  85.5MB/s   00:01
> [yano@cygwin-PC ~]$ scp yano@linux-server:test.dat .
> yano@linux-server's password:
> test.dat  100%  100MB  69.7MB/s   00:01
> 
> (2-2) From linux-server,
> yano@linux-server:~$ scp yano@cygwin-PC:test.dat .
> yano@cygwin-PC's password:
> test.dat  100%  100MB  80.1MB/s   00:01
> yano@linux-server:~$ scp test.dat yano@cygwin-PC:.
> yano@cygwin-PC's password:
> test.dat  100%  100MB  57.7MB/s   00:01
> 
> I am not sure why this happens and how to fix this.
> Any idea?
> 
> -- 
> Takashi Yano 
> 
> -- 
> Problem reports:  https://cygwin.com/problems.html
> FAQ:  https://cygwin.com/faq/
> Documentation:https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


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

Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?

[Chris Roehrig]

It was set to "Programs".Changing it to "Background services"  didn't make 
a difference.

TCPOptimizer can adjust 2 registry entries that I think are related to that 
Windows Setting:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows 
NT\CurrentVersion\Multimedia\SystemProfile]
"NetworkThrottlingIndex"=dword:000a
"SystemResponsiveness"=dword:0014

The first rate-limits IP packets; the second reserves a percent (0-100) 
of CPU scheduling for background tasks.   Changing either of those values made 
no difference.  I think the CPU scheduling reservation only applies when 
there's CPU contention (not on an idle system) so I wouldn't expect it to make 
a difference when CPU/core usage is low.



On Tue Aug 24 2021, at 8:20 PM, Mark Geisert  wrote:

> NightStrike via Cygwin wrote:
>> Older versions of windows had a setting to optimize the OS for either
>> background services or foreground applications. One of the things this did
>> was throttle network usage. I don't know if windows 10 has the same setting
>> though.
> 
> Yes, it does.  Getting to it is a pain.  Search the "Settings" thingy for 
> "Advanced system settings".  That will bring up the System Properties dialog 
> you used to be able to get to from the Control Panel.  Click the Advanced 
> tab.  Under Performance, click Settings... .  Click the Advanced tab there.  
> Right in that dialog there's a Processor Scheduling box where you select for 
> best performance of "Programs" or "Background services".
> 
> It would be interesting to hear what it's currently set to before you try 
> changing it.  Try to keep all your testcases the same so we're dealing with 
> apples to apples.
> 
> ..mark
> 
> -- 
> Problem reports:  https://cygwin.com/problems.html
> FAQ:  https://cygwin.com/faq/
> Documentation:https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


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

Re: Bug: Emojis () are replaced by unicode replacement character (�) on Windows Terminal

[Thomas Wolff]

Am 25.08.2021 um 13:48 schrieb Rafael Kuhn via Cygwin:

Using the shell that comes embedded with 'Git for windows' (that includes
Cygwin) and opening it in Windows Terminal, there's a bug that prevents me
from pasting types of unicode characters like emojis in the terminal.

I've opened a ticket in the git-for-windows repo and after testing over the
problem they concluded it was Cygwin's problem and told me to report it
here (ticket link below).
https://github.com/git-for-windows/git/issues/3281

The complete description of the problem from people that understand it more
than I actually do is in the ticket.

I'm including cygcheck.out like your guide suggests.
Thank you for your time, cheers.

I doubt this is a cygwin issue. Do any emojis run in that environment? 
Does it work in the "Git Bash" terminal? Why would you run git bash in 
Windows Terminal?


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

Re: Terminal occasionally shows duplicate command text when it is split over multiple lines

[Thomas Wolff]

Am 25.08.2021 um 08:42 schrieb Ray Satiro via Cygwin:

On 8/23/2021 6:15 PM, Thomas Wolff wrote:

Am 23.08.2021 um 23:52 schrieb Ray Satiro via Cygwin:

I'm using cygwin x86 updated yesterday and when I paste in commands
that are split over multiple lines sometimes an arbitrary line will
show more than once, even though it is not actually part of the
command more than once. For example here's a command:

echo foo \bar \baz \qux

And here's the terminal output when I paste it in:

$ echo foo \qux

bar \> baz \> quxfoo bar baz qux

$ echo foo \baz \> bar \> baz \> quxfoo bar baz qux

Please provide a clear test case. How exactly would your clipboard
have multiple lines? Your example is only one line.


My mail client did that. Here I'll try again:

echo foo \
bar \
baz \
qux


$ echo foo \
baz \
qux

bar \
baz \
qux

foo bar baz qux


Cannot reproduce this with mouse-pasting (middle mouse button). It does 
occur occasionally when pasting with Shift+Insert at keyboard repeat 
rate. I guess it's some kind of race condition, the initial part may get 
output earlier than the further parts are echoed. So it would not be a 
terminal issue.

Thomas

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

Bug: Emojis () are replaced by unicode replacement character (�) on Windows Terminal

[Rafael Kuhn via Cygwin]

Using the shell that comes embedded with 'Git for windows' (that includes
Cygwin) and opening it in Windows Terminal, there's a bug that prevents me
from pasting types of unicode characters like emojis in the terminal.

I've opened a ticket in the git-for-windows repo and after testing over the
problem they concluded it was Cygwin's problem and told me to report it
here (ticket link below).
https://github.com/git-for-windows/git/issues/3281

The complete description of the problem from people that understand it more
than I actually do is in the ticket.

I'm including cygcheck.out like your guide suggests.
Thank you for your time, cheers.


cygcheck.out
Description: Binary data

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

Fw: App and Web security

[Jacklyn Shaw via Cygwin]

Hi Cygwin,

I am writing this to request a proposal for your Business. We are an IT
based Company from USA who deals in Website Security, Mobile Security &
Cyber security, Governance Risk & Compliance Services With my Cyber Security
Specialist.

Let me know what you think.

PS: - if you are interested, then I can send you our past work details,
company information Etc. 

Thanks

Jacklyn Shaw


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

Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?

[Takashi Yano via Cygwin]

On Tue, 24 Aug 2021 12:49:52 -0700
Chris Roehrig wrote:
> I have a network of Windows, Linux and Mac machines and I use rsync to 
> synchronize various directories between them.
> 
> I'm trying to figure out why my rsync transfers are so slow (<4 MB/s) only 
> when the remote endpoint is Cygwin rsync over sshd (with both a Linux or 
> Cygwin rsync client).   In all other scenarios, I get the full 100MB/s as 
> expected from gigabit ethernet.  This has been an ongoing problem for me for 
> a couple of years over several Windows and Cygwin versions, and I'd like to 
> try to fix it.
> 
> If I run rsync --daemon --no-detach under mintty in the foreground on the 
> remote Windows endpoint,  I get the full 100 MB/s transfers, so it seems like 
> it has something to do with rsync.exe running in the background under the 
> cygrunsrv+sshd service (which was installed normally using ssh-host-config).
> 
> If I do:
>   pv /dev/zero | ssh $WINHOST "cat > /dev/null"
> or even
>   pv /dev/urandom | ssh $WINHOST md5sum
> I also get the full 100 MB/s transfers, so it doesn't look like sshd itself 
> is being throttled by bandwidth or CPU.
> 
> The machines have less than 15% CPU utilization while transferring, with each 
> of the 4 cores less than 30%, so it doesn't look to be CPU issue.
> In Task Manager, sshd.exe and rsync.exe seem to be running normally using 
> only few percent CPU, and show Power Throttling=Disabled, Priority=Normal.   
> Setting their Priority to High doesn't seem to change things.
> 
> Looking in Resource Monitor on the remote endpoint, the network usage is 
> pretty much a flat horizontal line at about 18 Mbps (2.5 MB/s), so it sure 
> looks to me as if rsync is somehow being bandwidth-throttled when run in the 
> background under cygsshd.
> 
> It's almost as if rsync has an implicit --bwlimit override when it is run 
> from cygrunsrv+sshd (I've tried --bwlimit=0 on the client which makes no 
> difference).
> 
> 
> Any ideas?Not sure where to go from here. 

In cygwin, just scp is very slow.

The transfer speed in my environment is as follows.
The tests were done with 100MB of test.dat file.

(1-1) From cygwin-PC,
[yano@cygwin-PC ~]$ scp test.dat yano@linux-server:.
yano@linux-server's password:
test.dat  100%  100MB   4.0MB/s   00:24
[yano@cygwin-PC ~]$ scp yano@linux-server:test.dat .
yano@linux-server's password:
test.dat  100%  100MB   8.0MB/s   00:12

(1-2) From linux-server,
yano@linux-server:~$ scp yano@cygwin-PC:test.dat .
yano@cygwin-PC's password:
test.dat  100%  100MB   4.0MB/s   00:24
yano@linux-server:~$ scp test.dat yano@cygwin-PC:.
yano@cygwin-PC's password:
test.dat  100%  100MB   4.1MB/s   00:24


I looked into this problem, and noticed that this is caused
by cygwin pipe implementation. Pipe in cygwin is configured
with FILE_FLAG_OVERLAPPED.

If the pipe is configured without FILE_FLAG_OVERLAPPED,
the transfer speed is much improved as follows.


(2-1) From cygwin-PC,
[yano@cygwin-PC ~]$ scp test.dat yano@linux-server:.
yano@linux-server's password:
test.dat  100%  100MB  85.5MB/s   00:01
[yano@cygwin-PC ~]$ scp yano@linux-server:test.dat .
yano@linux-server's password:
test.dat  100%  100MB  69.7MB/s   00:01

(2-2) From linux-server,
yano@linux-server:~$ scp yano@cygwin-PC:test.dat .
yano@cygwin-PC's password:
test.dat  100%  100MB  80.1MB/s   00:01
yano@linux-server:~$ scp test.dat yano@cygwin-PC:.
yano@cygwin-PC's password:
test.dat  100%  100MB  57.7MB/s   00:01

I am not sure why this happens and how to fix this.
Any idea?

-- 
Takashi Yano 

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

Re : cygwin.com : High quality website traffic at an affordable price...

[Carol Trenik]

Hello* cygwin.com * Owner,



My name is *Carol Trenik*, and I'm an SEO Specialist.



Most of the people share their anger and frustration once they get my
email. But let me show you how there are so many bugs (like broken links,
pages that returned 4XX status code upon request, images with no ALT text,
pages with no meta description tag, not having an unique meta description,
having too long title, etc.), found in * cygwin.com *.



I have a large professional team which can fix all the above issues
immediately at an *affordable price.* I guarantee you will see a drastic
change in your Google search ranking once these are fixed.

If this is something you are *interested* in, then allow me to send you a *no
obligation audit report.*



Waiting for your response!!!



Best Regards,

*Carol Trenik,*

SEO Specialist

--

*P.S1*: Our pricing for fixing the issues would cost *$200(one time).*
[image: beacon]

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

Re: Terminal occasionally shows duplicate command text when it is split over multiple lines

[Ray Satiro via Cygwin]

On 8/23/2021 6:15 PM, Thomas Wolff wrote:
> Am 23.08.2021 um 23:52 schrieb Ray Satiro via Cygwin:
>> I'm using cygwin x86 updated yesterday and when I paste in commands
>> that are split over multiple lines sometimes an arbitrary line will
>> show more than once, even though it is not actually part of the
>> command more than once. For example here's a command:
>>
>> echo foo \bar \baz \qux
>>
>> And here's the terminal output when I paste it in:
>>
>> $ echo foo \qux
>>> bar \> baz \> quxfoo bar baz qux
>> $ echo foo \baz \> bar \> baz \> quxfoo bar baz qux
> Please provide a clear test case. How exactly would your clipboard
> have multiple lines? Your example is only one line. 


My mail client did that. Here I'll try again:

echo foo \
bar \
baz \
qux


$ echo foo \
baz \
qux
> bar \
> baz \
> qux
foo bar baz qux


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