Chris G. Demetriou writes:
>They do have something to do with it, but they don't _prove_ it.
>
>Those numbers provide an upper bound on their interrupt handling time,
>at least on that hardware.  You need the interrupt to be delivered to
>take the timestamp.

I've read the source code.  The path in the FreeBSD sio driver is
longer than the path I was measuring, which was just to entry of my
driver.  One of the technicians and I spent a day gathering different
traces and collecting statistics of interrupt, driver, and kernel
latency.

Once again, in slow motion
     machine A  runs FreeBSD.
     machine B  runs NetBSD

     Machine A is reported by a highly esteemed researcher as
     doing interrupt dispatch and driver processing at a
     certain speed.

     I have measuerd machine B at doing just interrupt dispatch.  My
     numbers show machine B takes longer to do that than it takes for
     machine A to do slightly more.
     Machine A  has slower hardware than machine B (100 vs 133 Mhz).

     I conclude FreeBSD performs better at this task than FreeBSD.

That proves it to *my* satisfaction.

I also have numbers in my lab book showing ttcp throughput tests get a
5% speedup, purely from using FreeBSD's Pentium-tuned bcopy.  that's
just the kernel bcopy; Freebsd's tuned, merged copyin/bcopy and
copyout/copy would win even more.

Both of these back up my original observation, that FreeBSD has
somewhat better low-level performance than NetBSD.  The head-to-head
comparisons I did do were with Linux, which on the whole was slightly
better still at these specific low-level tasks.

I do note that nobody has even hinted at numbers that prove otherwise.
If anyone has any I'd be very glad to see them.  

Anyone who wants more comprehensive data can either measure it for
themselves, or arrange a rearch contract.  Time is not free.  It takes
tiem to do an lmbench or an hbench or a similar study


>Showing some numbers for FreeBSD and saying that he's never gotten
>close to them with any NetBSD system isn't particularly great
>argument, but neither is showing no numbers whatsoever and asserting
>that NetBSD's performance must be as good.

Hang on a minute, there.  I didnt say that.  I may have some numbers
somewhere showing the effect of using the fast interrupts from just
after Charles ``gc''ed it.  I didnt count that beacuse it hasn't been
part of NetBSD for ages, wasnt when I used it, and hadn't been used at
all for ages beyond that.  I'm not sure I even have the data.