f



-64 second offset

Hi,

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[13533]: too many recvbufs allocated (30)
25 Jun 22:42:03 xntpd[13533]: synchronized to GPS_NMEA(1), stratum=0
25 Jun 22:41:00 xntpd[13533]: time reset (step) -63.434442 s
25 Jun 22:41:00 xntpd[13533]: 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

Sincerely,
J�nos T�th-�get�


0
J
6/26/2003 10:20:38 AM
comp.protocols.time.ntp 4895 articles. 2 followers. Post Follow

1 Replies
705 Views

Similar Articles

[PageSpeed] 14

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:
> Hi,
> 
> 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[13533]: too many recvbufs allocated (30)
> 25 Jun 22:42:03 xntpd[13533]: synchronized to GPS_NMEA(1), stratum=0
> 25 Jun 22:41:00 xntpd[13533]: time reset (step) -63.434442 s
> 25 Jun 22:41:00 xntpd[13533]: 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
> 
> Sincerely,
> J�nos T�th-�get�
> 
> 

-- 
blu

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

0
Brian
6/27/2003 1:42:32 PM
Reply: