From owner-freebsd-hackers Tue Dec 16 19:14:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA29734 for hackers-outgoing; Tue, 16 Dec 1997 19:14:15 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from ns2.cetlink.net (root@ns2.cetlink.net [209.54.54.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA29721 for ; Tue, 16 Dec 1997 19:14:01 -0800 (PST) (envelope-from jak@cetlink.net) Received: from hot1.auctionfever.com (ts1-cltnc-13.cetlink.net [209.54.58.13]) by ns2.cetlink.net (8.8.5/8.8.5) with SMTP id WAA12538; Tue, 16 Dec 1997 22:13:10 -0500 (EST) From: jak@cetlink.net (John Kelly) To: Mike Smith Cc: Greg Lehey , FreeBSD Hackers Subject: Re: 3com 3c509 card Date: Wed, 17 Dec 1997 04:14:07 GMT Message-ID: <34974b92.96107160@mail.cetlink.net> References: <199712170113.LAA00848@word.smith.net.au> In-Reply-To: <199712170113.LAA00848@word.smith.net.au> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id TAA29722 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 17 Dec 1997 11:43:07 +1030, Mike Smith wrote: > Well, for starters you aren't disclosing your measurement technique. Simple CPU percentages from top. > All you have established is that a known ~50% improvement in the CPU > utilisation of the driver has not affected the amount of CPU used for > your FTP transfer. If it's true that the driver is 50% more efficient with the SMC Ultra 16, then how is it possible that the FTP code performs worse to keep the total percentage about the same? Are you saying that the driver component is so small that the improvement is drowned out by the FTP? I think my next test will be to set up a "router" machine with 4 ethernet adapters, and saturate them all from other connected machines with all traffic passing through the router and none terminating in it to eliminate all processing load except the routing and SMC driver. > First thing anyone should learn; how to measure things. Whether you're > talking engineering, physics, chemistry or computing; if you don't know > what you're measuring, the numbers mean nothing. If I can't route 4 ethernet interfaces with SMC Ultras then a rigorous academic exercise has no value for my purposes. I just want a rough projection that's reasonably accurate. > CPU time spent in the driver; I'd have thought that was pretty obvious > from the above. Call microtime() on entry to driver functions, call it > again on exit, and add the difference to a counter. Extract the value > of the counter and relate it to the number of bytes transferred on the > interface. Be careful not to double-count time. Be sensitive to > per-datagram as opposed to per-byte overheads. That's what I meant, above. John