I'm running a 1.2.1 system on an IPC attached to a GPS receiver, and
NetBSD/sparc seems fine.

The 'frequency' reported by xntp3 is the estimated clock error, and
I don't understand why you think the steady-state value of this has
anything to do with interrupt latency.  If a crystal is ~72 ppm slow,
then xntp3 needs to add ~72 us every second to keep the clock right,
and even perfect interrupt latency won't change this.

Interrupt latency (and latency in waking up a user-space process after
a packet arrives) will cause variance in the offset measurements.
To examine this more closely, I recommend that people try my "Time
Surveying" package:

  ftp://ftp.udel.edu:21/pub/ntp/time-surveying-0.92.tar.gz
  ftp://ftp.udel.edu:21/pub/ntp/time-surveying-doc.tar

This will allow you to examine the jitter in received timestamps,
after detangling effects of the clock being adjusted.  On the IPC, the
total jitter (including serial port issues - this is a 9600 bps
timecode over a serial port) is about 1 ms.


        Greg Troxel <gdt@bbn.com>