On Wed, 06 Aug 1997 01:33:02 -0700  Jonathan Stone wrote:

> 
> "Erik E. Fair" (Time Keeper) <fair@clock.org> writes:
> 
>  >Perhaps the scheduler? I wonder how much of the variation in NTP is the
>  >vagaries of the existing scheduler; a re-examination of its assumptions in
>  >the light of both modern systems architecture, and the various uses that
>  >the system gets put to would be a very good thing to do. We should also
>  >give a thought to adding some facility for making real-time scheduling
>  >latency guarantees for things like the NTP daemon, CD-R writers, X window
>  >system managers, and so on.
> 
> Yes, yes, and yes :).
> 
> I got into NetBSD because it let me collect kernel profiles with a
> this-decade-ish TCP (as opposed to, say, the last-decade-ish TCP in Ultrix)
> 
> I've done more pmax microbenchmarking and tuning since finishing the
> mips3 merge. _Wall_ time for a kernel build on a mips3 (r4000, r4400)
> has improved by over 10%.  lmbench numbers (modified, one of the
> programs doens't compile on mips with GCC) have improved by up to 50%.
> The current NTP problem is an anomaly that has me puzzled.

Just as a mini data point (and I don't know what your '10% improvement'
is measured on, but I'm seeing about a 40% improvement between a
5000/240 and a 5000/260 for a kernel build (make clean depend all, from
around 55 minutes to around 32 minutes).  With both of these machines,
everything but the root fs is NFS.

I'm curious about where you saw the 10% improvement.  I'd certainly hope
the a 5000/150 is more than 10% faster than a 5000/133 for a kernel
build.

Simon.