Re: [chrony-users] Fatal error : adjtimex() failed

["Tomalak Geret'kal" <tom@xxxxxxxxx>]

On 20/08/2012 22:44, Bill Unruh wrote:
> On Mon, 20 Aug 2012, Tomalak Geret'kal wrote:
>
> > And when it *does* start up successfully, I find that 
> > after some time (this varies, but on last observation was 
> > around ten minutes after startup) my GPS source is being 
> > selected over my PPS source (after a "no majority" 
> > event), and the PPS source is apparently never selected 
> > again.
> >
> > Aug 20 20:35:07 sw200319 daemon.info chronyd[2098]: 
> > chronyd version 1.26 starting
> > Aug 20 20:35:07 sw200319 daemon.info chronyd[2098]: Linux 
> > kernel major=2 minor=6 patch=21
> > Aug 20 20:35:07 sw200319 daemon.info chronyd[2098]: 
> > hz=100 shift_hz=7 freq_scale=0.99902439 
> > nominal_tick=10000 slew_delta_tick=833 max_tick_bias=1000
> > Aug 20 20:35:07 sw200319 daemon.err chronyd[2098]: Could 
> > not open IPv6 NTP socket : Address family not supported 
> > by protocol
> > Aug 20 20:35:07 sw200319 daemon.err chronyd[2098]: Could 
> > not open IPv6 command socket : Address family not 
> > supported by protocol
> > Aug 20 20:35:07 sw200319 daemon.info chronyd[2098]: 
> > Frequency -32.801 +- 0.047 ppm read from /etc/chrony.drift
> > Aug 20 20:37:00 sw200319 daemon.info chronyd[2098]: 
> > Selected source GPS
> > Aug 20 20:37:34 sw200319 daemon.info chronyd[2098]: 
> > Selected source PPS0
> > [..]
> > Aug 20 20:44:19 sw200319 daemon.info chronyd[2098]: Can't 
> > synchronise: no majority
> > Aug 20 20:45:56 sw200319 daemon.info chronyd[2098]: 
> > Selected source GPS
>
> Hmm. How are you feeding the shm? The PPS source cannot 
> give you the seconds.
> It is only accurate to the nsec, but completely oblivious 
> to seconds, so you
> have to do something to feed it the seconds. That could be 
> the gps itself, or
> some other source.

The SHM is fed by a known-good process that works with ntpd 
and also here with chrony when I can get it to start up. As 
you can see from the syslog, the SHM source was selected 
successfully.

> > [sw200319 /root]# chronyc sources
> > 210 Number of sources = 2
> > MS Name/IP address           Stratum Poll LastRx Last sample
> > ============================================================================ 
> >
> > #? PPS0                          0    4    43m  -1607ms[ 
> > +400ms] +/-  155ms
> > #* GPS                           0    4     16    -14ms[  
> > -14ms] +/-   60ms
>
> That indicates that the PPS is almost 2 seconds out from 
> the gps. a few 10s or
> even 100s of ms I could understand, but this indicates 
> that the pps source is
> getting the wrong seconds information.
>
> Also a fluctuation of 400ms or even 155 ms is pretty huge.
But as you point out yourself, PPS is oblivious to 
time-of-day as it provides only *timing*. My understanding 
is that this value in "chronyc sources" is actually just an 
artefact of the PPS not having been used to discipline usage 
of the SHM source for a full 43 minutes, so it's showing the 
result of jitter in the NMEA input?

> > [sw200319 /root]# cat /etc/chrony.conf
> > allow
> > refclock PPS /dev/pps0 lock GPS
>
> Hmm. that should lock to the gps signal,
>
> > refclock SHM 0 offset 0.5 delay 0.1 refid GPS
>
> Try putting in a "noselect" in that line, since you do not 
> want the system to
> use the GPS time except to give the seconds to PPS.

*nods* Way ahead of you. :) I hadn't spotted that this would 
not prevent the PPS source (which is "lock"ed to the GPS 
source) from working. IMO this could use expanding in the 
user guide.

Cheers

Tom

--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.