[ NTP clock drift measurement facts]

Yup, I agree with all that too.


>All this stuff aside, I still think working on improving NetBSD's interrupt
>latency in both the MD and MI code is a good idea, for this, for PPP over
>serial lines, and everything else. The point of this thread was to find tools
>and techniques for identifying specific parts of the kernel that need
>improvement in this regard.


I agree, better tools to find interrupt hotspots are needed. 

I think a very effective tool would actually be a kernel profiler that
ran at a hardware priority above even splclock() and splmalloc() (aka
splimp()), instead of at or below splclock(), as spl(9) suggests.

But you would at least see where the time is going -- except for code
at splhigh().  In fact, it looks like you'd get exactly this on a
sparc already, if statclock() really runs at intrlevel 14.

Charles has substantially reduced splhigh() usage, so this might be a
very useful tool for finding interrupt hotspots if you run it long
enough, and you know what routines are likely to be running at or
above the tty driver.