| Re: [chrony-users] Fatal error : adjtimex() failed |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
On Mon, 20 Aug 2012, Tomalak Geret'kal wrote:
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
Is it a secret which program you use?
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?
All sources MUST have a seconds source as well. Ie, PPS needs to be fed the
seconds by some other source. For you it was the GPS source I believe. That is
why that 1.6 second offset is so weird.
Also that line says that the last time it got a PPS signal was 43 minutes ago.
It should be say 15 sec ago instead. Your PPS source is not working at all.
>
> [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.
--
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.