First, confirm that PPS signals are being received by your system. A little
test program written by our own Jonathan Stone will help:
http://www.clock.org/~fair/ppstest.c
Second ... oh, dear. This is where things get messy, and you have to understand
some of how the guts of ntpd work. Also, understand the limitations of GPS
(where is your unit's antenna? how much sky can it see?). I have an old unit
(should really replace it), with a fair bit of wander in it (wander? Yeah, it's
a fixed mount, and the lat/long coordinates change) ... and not every NMEA
sentence has a checksum on it as required by standard, and as now required by
the ntpd refclock drivers.
If you read the refclock documentation carefully, you will see that ntpd won't
actually select the PPS clock - it will select the GPS (if ntpd thinks it's
good enough compared to your network servers/peers) and use PPS to discipline
it. At least, that's what I read in the docs.
It would be good to just run your system without the GPS reference initially (just leave it unconfigured, or
configured for a high stratum (say, 5), but using a set of close-by (minimum network delay) stratum 1 servers
for about a week so that ntpd can figure out how badly your IPX system clock drifts (recorded in
/var/db/ntp.drift, also reported in the output of ntptime(8) as "frequency", or "ntpdc -c
loopi [host]" also as "frequency"). The worse that is, the harder everything else is.
My GPS receiver is currently attached to accurate.clock.org, if you'd like to
take a look with ntpq(8), and ntpdc(8). I don't recommend anyone sync from it
for now.
Erik<fair%netbsd.org@localhost>