Does this happen every time? If so, try running xntpd with a few "-d" flags
to put it into debug mode. Let the reset happen and send the debug output.
Also send the clockstats file with all the lines since xntpd was started until
and including the one at the reset.
By the way, "slewalways" defaults to no, so you don't need that. And you
don't need the "prefer" keyword, and you don't need the "fudge" line, since
refclocks other than "local" default to stratum 0.
J�nos T�th-�get� wrote:
> I am trying to set up a stratum 1 server connected to a GPS receiver using
> the generic NMEA clock reference driver. (127.127.20.1)
> The target machine has a Solaris 8 system installed with the 109667-04 patch
> which includes the "slewalways yes | no" option.
> However I have some strange problems. The xntpd daemon synchronizes to the
> GPS receiver but with an approximate -64 second offset. The following log is
> output a while after I have used ntpdate to synchronize the system clock to
> a reliable server and then restarted the xntpd process.
> 25 Jun 22:42:03 xntpd: too many recvbufs allocated (30)
> 25 Jun 22:42:03 xntpd: synchronized to GPS_NMEA(1), stratum=0
> 25 Jun 22:41:00 xntpd: time reset (step) -63.434442 s
> 25 Jun 22:41:00 xntpd: synchronisation lost
> The step reset is happening at the same time a new line is inserted in the
> clockstat log (which happens every 64 second), with a GPRMC message with the
> corresponding UTC time for the new system time at time of reset. I have
> checked the output from the GPS receiver and it is correctly sending GPRMC
> messages with the right time at 1PPS rate. The message that is logged in the
> clockstat file is therefore 64 seconds old.
> I hope someone can explain this strange behaviour and preferrably present a
> solution for it.
> This the configuration I use:
> server 127.127.20.1 prefer
> fudge 127.127.20.1 stratum 0
> driftfile /var/ntp/ntp.drift
> slewalways no
> #disable pll
> statsdir /var/ntp/ntpstats/
> logconfig =syncall +clockall
> filegen clockstats file clockstats type day enable
> filegen loopstats file loopstats type day enable
> filegen peerstats file peerstats type day enable
> J�nos T�th-�get�
Brian's 12th rule of support: Supporting any technology
that has something called an "oid", will hurt.
Brian Utterback - Solaris Sustaining (NFS/Naming) - Sun Microsystems Inc.,
Ph/VM: 781-442-1343, Em:brian.utterback-at-ess-you-enn-dot-kom