Date: Wed, 17 Dec 1997 04:14:07 GMT From: jak@cetlink.net (John Kelly) To: Mike Smith <mike@smith.net.au> Cc: Greg Lehey <grog@lemis.com>, FreeBSD Hackers <hackers@FreeBSD.ORG> Subject: Re: 3com 3c509 card Message-ID: <34974b92.96107160@mail.cetlink.net> In-Reply-To: <199712170113.LAA00848@word.smith.net.au> References: <199712170113.LAA00848@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 17 Dec 1997 11:43:07 +1030, Mike Smith <mike@smith.net.au> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34974b92.96107160>