Subject: Re: NTP Resolution
To: Andrew Gillham <gillhaa@ghost.whirlpool.com>
From: Aaron Brown <abrown@cs.berkeley.edu>
List: tech-kern
Date: 08/07/1997 19:54:07
[sorry to jump in on this so late, but...]

Andrew Gillham <gillhaa@ghost.whirlpool.com> writes:

> > An interesting result for that IPX - is there anyone else out there running
> > NetBSD 1.2 or -current with NTP on sparcs that can give us a few more data
> > points? The command being executed is
> > 
> > 	xntpdc -c loopi your.host.here
> 
> >From a LX: (1.2D from March 17)
> offset:               -0.000484 s
> frequency:            133.210 ppm
> poll adjust:          -30
> watchdog timer:       18 s
> 
> >From a SS10: (1.2G from July 28)
> offset:               -0.000483 s
> frequency:            29.421 ppm
> poll adjust:          18
> watchdog timer:       440 s
> 
[snip]
> Also, I plan to update the LX to -current ASAP, so I'll report if that 
> causes a significant change in ppm.
> 
> > Insofar as I know, the principle difference between the sun4c and sun4m is
> > the MMU (pmap) code...
> 
> Are you building your kernel with just the sun4c or sun4m code?

The timer code is different (different chips). But it should be
functionally eqivalent. At one point, there was a bug in the sun4m
timer-handling code that put in roughly an extra half microsecond (?)
per second on some machines; it was fixed several months ago, but I'm
not sure when (I think it was post-1.2, but I can't get to my logs to
check right now). So if you see egregiously horrible drifts on a
sun4m, make sure your kernel is up-to-date.

Another thing that could affect sun4m's is that the pmap module
was originally coded with lots of extra (and probably unneeded)
splpmap()'s (grep for "paranoia" in the code). Many of these
have since been removed, but if many of them are left, this could
be a source of increased clock interrupt latency.

--Aaron