From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4048 invoked by alias); 8 Feb 2002 13:17:44 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Received: (qmail 3947 invoked from network); 8 Feb 2002 13:17:33 -0000 Received: from unknown (HELO extern11.lif.de) (149.233.74.11) by sources.redhat.com with SMTP; 8 Feb 2002 13:17:33 -0000 Received: from FW ([10.1.1.1]) by extern11.lif.de (8.11.6/8.9.3) with SMTP id g18DHV809492 for ; Fri, 8 Feb 2002 14:17:31 +0100 (MET) Received: from mail.hq.sag-el.com (mail.hq.sag-el.com [10.71.2.115]) by dns1.serv1.tessag.com (8.9.3 (PHNE_24419)/8.9.3) with ESMTP id OAA18731 for ; Fri, 8 Feb 2002 14:17:50 +0100 (MET) Received: from BRAMSCHE [10.68.28.101] by mail.hq.sag-el.com (SMTPD32-5.05) id A308E8B0096; Fri, 08 Feb 2002 14:30:48 +0100 From: "Ralf Habacker" To: "Corinna Vinschen" Subject: RE: unix domain socket with shared memory ? Date: Fri, 08 Feb 2002 05:17:00 -0000 Message-ID: <001f01c1b0a2$a76fd840$651c440a@BRAMSCHE> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <20020208125556.B12075@cygbert.vinschen.de> X-SW-Source: 2002-02/txt/msg00404.txt.bz2 > -----Original Message----- > From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf > Of Corinna Vinschen > Sent: Friday, February 08, 2002 12:56 PM > To: cygwin > Subject: Re: unix domain socket with shared memory ? > > > On Thu, Feb 07, 2002 at 11:55:31PM +0100, Ralf Habacker wrote: > > One question: Does unix domain sockets uses localhost address ? net.cc:cygwin_socketpair() seems to > use first an ip > > adress of zero and later the loopback address. Could this have an effect ? > > Nope. It's probably more secure to use INADDR_LOOPBACK here but > it has nothing to do with speed. > > > I have tried to replace the locations using INADDR_ANY with htonl (INADDR_LOOPBACK) but recognized no changes. > > I would have lost a bet if that had changed anything. I should add, it does not have any changes relating to the benchmark results. :-) > > If you look a little deeper you can see, that the read() in unix domain socket benchmark returns only > 32708 bytes > > > > 1966 1981317 [main] bw_unix 1788 _read: 32708 = read (3, 0xA012048, 65536), errno 0 > > > > while the read() in the tcp benchmark returns 65416 > > > > 2573 7229513 [main] bw_tcp 1792 _read: 65416 = read (3, 0xA012048, 65536), errno 0 > > > > and thats may be a reason for the performance difference. > > Hmm, perhaps. I've just checked in a fix which perhaps changes > that disproportion. Could you please check with the latest from > CVS aggain? > Yes, i will try. > > The main difference between the two benchmarks are the used device /dev/sockstream against /dev/tcp. > > But don't ask me about the reason why, now I'm left > > That's easily to see in the sources. net.cc? > I have assumed, that there are perhaps some hided implementation difference, which causes this buffer size difference. :- > > returned stable after a few (about 10) returns with the full buffer size of 65536 in the main > benchmark loop. Could > > this be a bug in the winsock code or is it be caused by timing differences, because not all data is send early > > enough ? (There are 119 bytes missed) > > Dunno. Winsock overhead, perhaps. > > > BTW2: > > > I'm a bit surprised by your results, though. > > I'm additional surprised that the native unix domain sockets performance under cygwiwn is only 7% of the linux > > performance with the same hardware, while the tcp performance seems to be acceptable (64% of the linux > > performance). So my main target is to speed this up. :-) > > That's not a surprise. AF_LOCAL sockets are naturally equaly slow > or slower than AF_INET sockets on Cygwin (why? Exercise for the > reader!) while they are a completely independent implementation > on Linux or other OSes. Your're right, it's not a suprise for someone who know how cygwin implements AF_LOCAL :-), but of the sight from linux, this isn't expected I'm porting kde, which comes from linux or other unix and the contained libs and apps expects a faster implementation of AF_LOCAL. And because I'm trying to speed up kde running, this optimation looks good to me. My question is now, what do you think about this idea with a shared memory implementation of AF_LOCAL ? Ralf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/