NTP - Inaccurate timekeeping

NTP - Inaccurate timekeeping

Post by Clive Hampto » Sat, 29 Jul 2000 04:00:00



I have 3 Sun workstations running shareware NTP (DMntp, 4.0.72j -
smc.vnet.com) combined with Trimble GPS Units. Time jumps are frequent and
unacceptable. Ntp.drift file reports value of 512.00. Relevant output from
ntpq below:

pte-p3-2[365] ntp> ntpq
ntpq> peers
     remote           refid      st t when poll reach   delay   offset
disp
============================================================================
==
*GPS_NMEA(0)     .GPS.            0 -   22   64  377     0.00   49.976
8.43
ntpq> associations
ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1 21324  96f4   yes   yes  none  sys.peer   reachable 15
ntpq> cv
status=0202 clk_badformat, last_clk_badformat
device="NMEA GPS Clock", timecode=, poll=3345, noreply=0,
badformat=59651, baddata=0, fudgetime1=0.000, stratum=0, refid=GPS,
flags=0
ntpq> rv
status=04f4 leap_none, sync_uhf_clock, 15 events, event_peer/strat_chg
processor="sun4u", system="SunOS5.7", leap=00, stratum=1,
rootdelay=0.00, rootdispersion=12.97, peer=21324, refid=GPS,
reftime=bd2bce1c.eba27ae9  Fri, Jul 28 2000 10:17:16.920, poll=6,
clock=bd2bce45.0f1bac2d  Fri, Jul 28 2000 10:17:57.059, state=4,
phase=49.976, frequency=512.000, jitter=3.940, stability=4.512
ntpq> pstatus 21324
status=96f4 reach, conf, sel_sys.peer, 15 events, event_reach
srcadr=GPS_NMEA(0), srcport=123, dstadr=0.0.0.0, dstport=123, keyid=0,
stratum=0, precision=-20, rootdelay=0.00, rootdispersion=0.00,
refid=GPS, reftime=bd2bce1c.eb84cad5  Fri, Jul 28 2000 10:17:16.919,
delay=    0.00, offset=   49.98, jitter=3.731, dispersion=8.43,
reach=377, valid=7, hmode=3, pmode=4, hpoll=6, ppoll=6, leap=00,
flash=0x0<OK>, org=bd2bce1c.eb84cad5  Fri, Jul 28 2000 10:17:16.919,
rec=bd2bce1c.eba27ae9  Fri, Jul 28 2000 10:17:16.920,
xmt=bd2bce1c.5560c7c0  Fri, Jul 28 2000 10:17:16.333,
filtdelay=    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00,
filtoffset=  56.93   56.77   45.18   49.98   43.52   45.41   45.41   47.41,
filtdisp=18.13 18.89 9.83 7.10 9.78 8.40 9.36 11.00
ntpq>

Can anyone help please?

Clive Hampton

 
 
 

NTP - Inaccurate timekeeping

Post by Jon Baggot » Sat, 29 Jul 2000 04:00:00


Clive,

Since you're using Solaris 7, you're probably also using the built-in
precision kernel mode. Older versions of ntp4 have a bug whereby they
incorrectly initialize the kernel time structure leading to an initial
ridiculous drift estimation. Looks like that's what's happening to you. To
test this, disable kernel support by adding "disable kernel" to your
ntp.conf. If the problem goes away, update your ntp to a more recent version
(4.0.93 has the bug; 4.0.98k and later don't - I don't know exactly when it
got fixed). Also make sure you have the latest kernel patch from Sun (at
least 106541-9). It's probably a good idea to update your ntp anyhow -
4.0.72j is pretty old...

--
Jon Baggott
General Dynamics Electronic Systems
"The views expressed are the author's and do not necessarily reflect the
official position of GD or any of its subsidiaries"


Quote:> I have 3 Sun workstations running shareware NTP (DMntp, 4.0.72j -
> smc.vnet.com) combined with Trimble GPS Units. Time jumps are frequent and
> unacceptable. Ntp.drift file reports value of 512.00. Relevant output from
> ntpq below:

> pte-p3-2[365] ntp> ntpq
> ntpq> peers
>      remote           refid      st t when poll reach   delay   offset
> disp

============================================================================
> ==
> *GPS_NMEA(0)     .GPS.            0 -   22   64  377     0.00   49.976
> 8.43
> ntpq> associations
> ind assID status  conf reach auth condition  last_event cnt
> ===========================================================
>   1 21324  96f4   yes   yes  none  sys.peer   reachable 15
> ntpq> cv
> status=0202 clk_badformat, last_clk_badformat
> device="NMEA GPS Clock", timecode=, poll=3345, noreply=0,
> badformat=59651, baddata=0, fudgetime1=0.000, stratum=0, refid=GPS,
> flags=0
> ntpq> rv
> status=04f4 leap_none, sync_uhf_clock, 15 events, event_peer/strat_chg
> processor="sun4u", system="SunOS5.7", leap=00, stratum=1,
> rootdelay=0.00, rootdispersion=12.97, peer=21324, refid=GPS,
> reftime=bd2bce1c.eba27ae9  Fri, Jul 28 2000 10:17:16.920, poll=6,
> clock=bd2bce45.0f1bac2d  Fri, Jul 28 2000 10:17:57.059, state=4,
> phase=49.976, frequency=512.000, jitter=3.940, stability=4.512
> ntpq> pstatus 21324
> status=96f4 reach, conf, sel_sys.peer, 15 events, event_reach
> srcadr=GPS_NMEA(0), srcport=123, dstadr=0.0.0.0, dstport=123, keyid=0,
> stratum=0, precision=-20, rootdelay=0.00, rootdispersion=0.00,
> refid=GPS, reftime=bd2bce1c.eb84cad5  Fri, Jul 28 2000 10:17:16.919,
> delay=    0.00, offset=   49.98, jitter=3.731, dispersion=8.43,
> reach=377, valid=7, hmode=3, pmode=4, hpoll=6, ppoll=6, leap=00,
> flash=0x0<OK>, org=bd2bce1c.eb84cad5  Fri, Jul 28 2000 10:17:16.919,
> rec=bd2bce1c.eba27ae9  Fri, Jul 28 2000 10:17:16.920,
> xmt=bd2bce1c.5560c7c0  Fri, Jul 28 2000 10:17:16.333,
> filtdelay=    0.00    0.00    0.00    0.00    0.00    0.00    0.00
0.00,
> filtoffset=  56.93   56.77   45.18   49.98   43.52   45.41   45.41
47.41,
> filtdisp=18.13 18.89 9.83 7.10 9.78 8.40 9.36 11.00
> ntpq>

> Can anyone help please?

> Clive Hampton



 
 
 

NTP - Inaccurate timekeeping

Post by David Wooll » Sun, 30 Jul 2000 04:00:00




> I have 3 Sun workstations running shareware NTP (DMntp, 4.0.72j -

What's wrong with using it as freeware?  More importantly, if you
are paying for it, why aren't you being given support?

Quote:> smc.vnet.com) combined with Trimble GPS Units. Time jumps are frequent and

I assume these are time standards, not navigation devices.  Navigational
units have very high latencies in reporting the time.  (The relative
stability suggests that these are time transfer devices.)

Quote:> unacceptable. Ntp.drift file reports value of 512.00. Relevant output from
> ntpq below:

That's off scale for SunOS, so you need to specify the OS more accurately.
SunOS has a feature to reset the software clock from the time of day clock
which must be disabled.  This may apply to other Sun operating systems.

What tickadj correction have you applied?

The fact that you have a round power of two frequency and it is more than
the maximum frequency offset for the typical system with a tick adjustment
of 5 microsends per 0.01 seconds, makes me think that the kernel loop
theory may be right.