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

[Ken Brown]

On 8/30/2021 10:12 AM, Corinna Vinschen wrote:
> On Aug 30 09:41, Ken Brown wrote:
>> On 8/30/2021 9:20 AM, Corinna Vinschen wrote:
>>> On Aug 30 15:00, Corinna Vinschen wrote:
>>>> On Aug 30 10:27, Corinna Vinschen wrote:
>>>>> [Moving discussion to cygwin-developers]
>>>>>
>>>>> On Aug 29 11:57, Ken Brown via Cygwin wrote:
>>>>>> Corinna, do you still see any benefit to switching to PIPE_NOWAIT?  AFAICT,
>>>>>> it wouldn't decrease the code size at this point, so the only question is
>>>>>> whether it might improve performance.
>>>>>
>>>>> Pipes are already using PIPE_NOWAIT aka FILE_PIPE_COMPLETE_OPERATION
>>>>> mode, see set_pipe_non_blocking.  The problem is that it's not used for
>>>>> blocking pipes.  Rather, blocking pipes use overlapped IO.  Overlapped
>>>>> IO is conceptually upside-down from the POSIX concept of non-blocking.
>>>>> Also, the information returned in FilePipeLocalInformation is historically
>>>>> borderline.  For kicks, see
>>>>> https://cygwin.com/pipermail/cygwin-patches/2004q4/005002.html
>>>>>
>>>>> So my suggestion is to try switching to non-blocking Windows pipes
>>>>> entirely, even for blocking pipes on the user level.  It works nicely
>>>>> for sockets.
>>>>
>>>> On second thought, I'm not so sure how to block on non-blocking pipes
>>>> on writing.  Assuming a write fails because the buffer is full, we
>>>> don't have a waitable object to wait on.  Unless the pipe handle is
>>>> signalled if writing is allowed, but that would be a first in Windows.
>>>> So in theory this would still require overlapped IO.  Does that still
>>>> work as desired if the pipe mode is non-blocking?  I don't think I ever
>>>> tried that...
>>>
>>> That probably doesn't make sense.  If WriteFile returns without writing
>>> something, what should overlapped io be waiting on?
>>
>> The approach I've taken on the topic/pipe branch is to stop using overlapped
>> I/O and to always keep the blocking mode of the Windows pipe in sync with
>> the blocking mode of the fhandler.  This seems to work pretty well so far,
>> although problems could certainly show up after further testing.
> 
> Erm... afaics, fhandler_pipe::raw_read and fhandler_pipe::raw_write are
> still using overlapped IO on blocking sockets.  Otherwise, how'd you
> handle signals?
> 
> Just to be clear, Windows pipes can be read/write in three modes:
> 
> - non-blocking	 (FILE_PIPE_COMPLETE_OPERATION)
> - synchronous	 (FILE_PIPE_QUEUE_OPERATION, non-overlapped)
> - asynchronous   (FILE_PIPE_QUEUE_OPERATION, overlapped)

OK, I've been thoroughly confused about what "overlapped" means.  I thought it 
meant specifying FILE_FLAG_OVERLAPPED and a pointer to an OVERLAPPED structure, 
both of which (I thought) only made sense when using the Win32 API rather than 
the NT API.

I *think* I understand what you mean now.  By using an event in the calls to 
NtReadFile and NtWriteFile in the blocking case, I'm selecting asynchronous 
mode, right?

Ken