Since we seem to be going around a few times on this I'm going to
summarize the current hardware and software configuration of the system
so we're all on the same starting point.
The GPS data is read by gpsd on /dev/gps0 which is a symlink to /dev/ttya.
The PPS_ATOM is reading /dev/pps0 which is a symlink to /dev/ttyb.
So two serial ports handling two different parts of the available GPS
signals.
The GPS PPS signal is stable. I have kept an eye on it externally
including when I've had trouble with ntpd and I have not seen any
evidence of trouble with the source.
The OS is NetBSD 5.1 on sparc sun4c (IPX). The oscillator on the system
appears to be fine. It did not drift far from its set time with no
clock discipline. The system load is minimal, running only ntpd and
gpsd plus the standard base system processes.
The current clock configuration of ntpd has the following:
server 0.us.pool.ntp.org iburst
server 1.us.pool.ntp.org iburst
server 0.north-america.pool.ntp.org iburst
server ntp1.gatech.edu
server rolex.usg.edu
server 127.127.22.0 minpoll 4 maxpoll 4
fudge 127.127.22.0 flag2 1 flag3 0 flag4 1 refid PPS
server 127.127.28.0 minpoll 7 noselect
fudge 127.127.28.0 stratum 4 time1 -0.6 flag4 1 refid GPSD
Note that the SHM refclock (the GPSD) is set to noselect. It has been
this way for quite a while. All the problems I have been having do not
involve GPSD in any way because it is always noselect. I will be using
it later on ntpd but I want to get PPS working first. Until then it
will stay noselect. Unless the noselect directive is being ignored by
ntpd my understanding is that it shouldn't matter if the refclock is
present in the configuration.
I have configured PPS_ATOM one of three ways for testing. It has been
in noselect, flag 3 disabled, and flag 3 enabled.
Now, under dev version p239, PPS did in fact work fine for a short
period of time. After about an hour the system would sync to PPS and I
would get the 'o' code. But after some hours of use ntpd would spin out
of control with huge multi-second offsets and the clock would tick out
of control. This happened with either flag3 setting.
Now I have version p256 because of the snprintf bug in NetBSD's libc.
The configure flag --enable-c99-snprintf didn't work properly in p239
but does work in p256. I needed that flag to work around the libc bug.
Under this new version, PPS does not work AT ALL. At no time does it
ever sync to PPS regardless of the flag3 setting. More interesting is
the fact that p256 reports twice the jitter on the PPS signal that p239
did even though none of the hardware or OS components have changed. The
only thing that's different is ntpd. With flag3 cleared (no kernel
discipline), p256 refuses to ever select PPS regardless of the quality
of its signal. It is always marked a false ticker. By comparison p239
didn't have this problem. Version p256 will spin out of control with
multi-second offsets if flag3 is enabled. This is the same behavior as
version p239.
I am seeing many sys_fuzz messages in version p256 as well.
So that's where things sit right now.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
