From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <36317a1c639a29012001659155659336@plan9.bell-labs.com> From: presotto@plan9.bell-labs.com To: 9fans@cse.psu.edu Subject: Re: [9fans] network throughput measurements MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-dqdcbiztjwpgzlgtnpvazcfdud" Date: Fri, 8 Mar 2002 16:46:34 -0500 Topicbox-Message-UUID: 61fcf2d6-eaca-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-dqdcbiztjwpgzlgtnpvazcfdud Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit >actually we were more interested in measuring the latency p9 imposes >on transmission, i.e. the time it takes for the first byte to start >appearing on the network... + > buf = mallocz(i, 1); > tbegin = nsec(); > for(j = 0; j < 10000; j++) > write(fd, buf, i); > tend = nsec(); I'm not complaining, I like seeing numbers. However, these two statements don't jibe. > at one point the receiver side was printing the total number of bytes > received, which was in line with calculations, so no huge discrepancy > there.. I'm actually interested in the number of bytes/packet seen on the receiver. All you measured what the amount of time to queue the messages on the sender, not the time to send them, the average time for each byte to make the journey, or the time to get the first byte to the wire. If all you want to do to improve the numbers for plan 9, we can do it trivially by just making sure we buffer all the 1 byte writes before sending anything out. Then you're just measuring the time for 10000 1 byte writes which is moderately quick. However, I suspect that's not what you want to speed up. I suspect that the BSD stack is doing significantly better than we are at ganging bytes/packet and hence causes fewer interrupts, runs up the IP stack, system calls, etc. --upas-dqdcbiztjwpgzlgtnpvazcfdud Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Fri Mar 8 16:30:53 EST 2002 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Fri Mar 8 16:30:51 EST 2002 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 949C519980; Fri, 8 Mar 2002 16:30:48 -0500 (EST) Delivered-To: 9fans@cse.psu.edu Received: from acl.lanl.gov (plan9.acl.lanl.gov [128.165.147.177]) by mail.cse.psu.edu (CSE Mail Server) with SMTP id DEFC61999B for <9fans@cse.psu.edu>; Fri, 8 Mar 2002 16:28:40 -0500 (EST) To: 9fans@cse.psu.edu Subject: Re: [9fans] network throughput measurements From: andrey mirtchovski MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-Id: <20020308212840.DEFC61999B@mail.cse.psu.edu> Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Help: List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Fri, 8 Mar 2002 14:29:03 -0700 actually we were more interested in measuring the latency p9 imposes on transmission, i.e. the time it takes for the first byte to start appearing on the network... yes, this is not the best way to measure performance, but it was a good exercise before porting netpipe natively to p9. the results seemed interesting enough to "publish" :) at one point the receiver side was printing the total number of bytes received, which was in line with calculations, so no huge discrepancy there.. andrey --upas-dqdcbiztjwpgzlgtnpvazcfdud--