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

[Ken Brown]

On 8/30/2021 8:55 AM, Corinna Vinschen wrote:
> On Aug 30 21:04, Takashi Yano wrote:
>> On Mon, 30 Aug 2021 12:20:30 +0200
>> Corinna Vinschen wrote:
>>> [Move discussion to cygwin-developers]
>>>
>>> On Aug 30 17:02, Takashi Yano via Cygwin wrote:
>>>> [...]
>>>> Is naming the pipe really necessary?
>>>
>>> It's not, but CreatePipe is doing this anyway.
>>>
>>> "Anonymous pipes are implemented using a named pipe with a unique name."
>>> https://docs.microsoft.com/en-us/windows/win32/api/namedpipeapi/nf-namedpipeapi-createpipe
>>>
>>> The reason CreateNamedPipe was used in the first place was that
>>> FILE_READ_ATTRIBUTES isn't set by CreatePipe for the write side
>>> of the pipe, however, it creates full duplex pipe:
>>>
>>> https://cygwin.com/pipermail/cygwin-patches/2004q3/004912.html
>>>
>>> Given the fact that CreatePipe is implemented in terms of
>>> NtCreateNamedPipeFile anyway, why should the pipe created with
>>> NtCreateNamedPipeFile fail where the pipe created with CreatePipe works?
>>>
>>> The only reason can be some missing flag, I think.  Checking
>>> fhandler_pipe.cc::nt_create and comparing that with the default flags
>>> for files and other devices, it occurs to me that the SYNCHRONIZE stuff
>>> is missing.  So, Takashi, what if you call NtCreateNamedPipeFile like
>>> this in nt_create:
>>>
>>>    status = NtCreateNamedPipeFile (r, access | SYNCHRONIZE, &attr, &io,
>>> 				  FILE_SHARE_READ | FILE_SHARE_WRITE,
>>> 				  FILE_CREATE, FILE_SYNCHRONOUS_IO_NONALERT,
>>> 				  pipe_type, FILE_PIPE_BYTE_STREAM_MODE,
>>> 				  0, 1, psize, psize, &timeout);
>>>
>>> Does that fix the above problems, too?
>>
>> Yes it does! Now, if CYGWIN=pipe_byte is also set, the piping issue
>> of C# program is gone!
>>
>> In fact, I've already tested adding the SYNCHRONIZE access flag,
>> but it didn't solve the problem. It seems that the cause was
>> that FILE_SYNCHRONOUS_IO_NONALERT was missing.
>>
>> Thank you for figuring out the solution!
> 
> No worries.  The same should apply to the NtCreateFile side of the
> pipe, btw.

I'll add my thanks.  I should have checked the default flags that are typically 
used for other devices when I wrote nt_create.  I'm glad you caught this.

So I'll reinstate the use of nt_create and then let Takashi recheck everything.

Ken