From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) by sourceware.org (Postfix) with ESMTPS id E50823858C27 for ; Tue, 31 Aug 2021 19:51:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E50823858C27 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=cygwin.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=cygwin.com Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MA7Ss-1m9dTe2aqI-00BcVX for ; Tue, 31 Aug 2021 21:51:36 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 2F9DEA80D9C; Tue, 31 Aug 2021 21:51:36 +0200 (CEST) Date: Tue, 31 Aug 2021 21:51:36 +0200 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled? Message-ID: Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <20210831204541.2b56702cdcd2fae5e91ba8e2@nifty.ne.jp> <583ca127-02e7-6b3c-3732-6478c0f862e3@cornell.edu> <6dc7d21d-05c2-5cb2-f04c-935153d73214@cornell.edu> <0b2f7e89-5013-d99c-5425-925f98fc214f@cornell.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <0b2f7e89-5013-d99c-5425-925f98fc214f@cornell.edu> X-Provags-ID: V03:K1:lkM6MqEQKpAS+no7gXknuGS4Z+phmyatrzTVVMrvIZJtU95Va/J 7676uXpZRQPXaIlboQ0Nv7xDvWpQ5SF7XvD/hbbzLKdP9cHwKQpGPTGlcY4DUTwP0t+qsDG 2Dsz2R+ApwL513OX3VBi6WfgQ0fX7J4enGwFkDRZA6STe/HSe2Jfh87iEKaVKMfqiYifuov WGzBH6IzBOdhtmrQuk3Tw== X-UI-Out-Filterresults: notjunk:1;V03:K0:r5YuO3kbcvQ=:Izgh7/80YAnLSkxLRGwa4u hXigMHFfCTQHPNIKjtXPE6nL4lBo9uByKNttOR6gvzMAwJFiUBVj0kb/B9x6IjxgQywFld/b1 h6+vigyNd5H2f0HogRKu6uE7mj1XBH4P/sQODAyH0tujfWczdfI5iy3dp9DzHBpZExwWn5Fpz bjtPCtSd1TPTV90fhMtbScKKRsWTWaN4INpQY8UADzMSLPbP0I2N8aQttGDTLraK4EFncqPF0 akMFjt9ZIiJ429FX+eul6n+UN6c15eeUC9EWItK7dD+8CS8IkCKCPlsyzBX0uj60fp5dnp34Q /GebLEW3tI85HiayIZ2tnrydcBJzr+CKeyib87M7IzqjOhnVWJZMR4FX4MVyMsOzR2OfmoB1H dYPVK5Hkrh5sgZWcu3HQtgg9Y5stte+fK14DNh2XfRAsNvFif8flIhXExdHDbcEw6M7kNStrr trQUrdin49OhEUHikT4t0YwdvGorhcUFaQSWpqk2CbN6vC50WQ7/seNZzNxu9M+kxsY1+I56g 2M4SbkE64wJFlGT4yYFXpkUChkWTOllWEvqCgy06PH1hWTarIewCSPR8IXArabcmUoh+rhQbE 2fqCSPbY+aDUzQ3Z6MqFIU8KSYGnHpqd2JyH/vwGI68KbCfZs7Fn3lgZpo4iPO74N0EVeojZa FbPOYgg9fQV1V1M8364zzlxleFK9T94y3yY2VkQel6hdxoI4afJx1AjUjmV+ZjIc6aYlql3lh v4qHGAnZ1l+eIcbB+Mcw1clSv590ezht99zV35a9ZKjinAC+oy4a8++3sto= X-Spam-Status: No, score=-99.8 required=5.0 tests=BAYES_00, GOOD_FROM_CORINNA_CYGWIN, JMQ_SPF_NEUTRAL, KAM_DMARC_NONE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NEUTRAL, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin-developers@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin core component developers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 19:51:39 -0000 On Aug 31 14:54, Ken Brown wrote: > On 8/31/2021 1:30 PM, Corinna Vinschen wrote: > > On Aug 31 12:38, Ken Brown wrote: > > > And here's a really trivial comment about your patch to raw_write: Where you have > > > > > > len1 = fpli.InboundQuota - fpli.ReadDataAvailable; > > > > > > I think the code would be slightly clearer if you wrote > > > > > > len1 = fpli.WriteQuotaAvailable; > > > > D'oh! That was the idea. Aparently I forgot it in mid-air... > > One more thing. For a non-blocking write, according to POSIX, "A write > request for {PIPE_BUF} or fewer bytes shall have the following effect: if > there is sufficient space available in the pipe, write() shall transfer all > the data and return the number of bytes requested. Otherwise, write() shall > transfer no data and return -1 with errno set to [EAGAIN]." > > So I think the condition for breaking from the retry loop has to be changed from > > evt || !NT_SUCCESS (status) || io.Information > 0 > > to > > evt || !NT_SUCCESS (status) || io.Information > 0 || len <= PIPE_BUF Hmm. I wonder if we shouldn't untangle the raw_write code and handle blocking and non-blocking writes in two different branches of an if. That should make things much clearer, shouldn't it? > And I wonder if we've now uncovered a reason for using message mode: If the > pipe was created in byte mode, might we get a partial write when len <= > PIPE_BUF? I see the following under "Pipes" at > > https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-writefile > > "When writing to a non-blocking, byte-mode pipe handle with insufficient > buffer space, WriteFile returns TRUE with *lpNumberOfBytesWritten < > nNumberOfBytesToWrite." Good point. Corinna