From owner-freebsd-hackers  Tue Dec 16 17:24:39 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id RAA20106
          for hackers-outgoing; Tue, 16 Dec 1997 17:24:39 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA19587
          for <hackers@FreeBSD.ORG>; Tue, 16 Dec 1997 17:19:00 -0800 (PST)
          (envelope-from mike@word.smith.net.au)
Received: from word (localhost [127.0.0.1])
	by word.smith.net.au (8.8.8/8.8.5) with ESMTP id LAA00848;
	Wed, 17 Dec 1997 11:43:07 +1030 (CST)
Message-Id: <199712170113.LAA00848@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Greg Lehey <grog@lemis.com>
cc: Mike Smith <mike@smith.net.au>, John Kelly <jak@cetlink.net>,
        FreeBSD Hackers <hackers@FreeBSD.ORG>
Subject: Re: 3com 3c509 card 
In-reply-to: Your message of "Wed, 17 Dec 1997 11:38:01 +1030."
             <19971217113801.53802@lemis.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 17 Dec 1997 11:43:07 +1030
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> >> I tested with an FTP transfer and consumed about 45% CPU in both
> >> cases.
> >>
> >> I wonder if I'm doing something wrong.
> >
> > Well, for starters you aren't disclosing your measurement technique.
> > It sounds to me as though it's not measuring the relative CPU consumed
> > per bytes/datagrams transferred by the driver though.
> >
> > 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.  This should tell you something about how efficient
> > the driver is in the first place, especially compared with the other
> > operations involved in the transfer.
> >
> > 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.
> 
> It's easy to say that sort of thing.  Now how about explaining what he
> should be looking for?

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.

An earlier poster described a substantial performance improvement 
between 2.1 and 2.2 on a slow system; I believe this had to to with 
changes in the mbuf management code (clustering?).

mike