RE: [chrony-dev] pps source is still marked as synchronised when no absolute clock sources are available

["Hattink, Tjalling (FINT)" <T.Hattink@xxxxxxxx>]

> From: Bill Unruh
> Sent: Wednesday, January 20, 2010 16:18
> 
> > On Wed, 20 Jan 2010, Hattink, Tjalling (FINT) wrote:
> > 
> > Hi,
> >
> > This is my report of a second issue I found when experimenting with 
> > Chrony. See the mail titled "makestep command sometimes makes chrony

> > stop reading its sources" for more background info.
> >
> > I use two reference sources for synchronising the system clock, a
SHM 
> > interface providing absolute time from a GPS card, and a PPS
interface 
> > providing precise relative time from a GPS card.
> 
> Are those separate GPS cards or the same card?

They come from the same GPS card.

> 
> >
> > The daemon providing the SHM interface only provides timestamps when

> > the GPS card is locked and its time is accurate. The PPS interface
is 
> > always providing sub-second timestamps.
> >
> > When chrony is started it does not discipline the system clock until

> > the SHM interface is marked synchronised. After the SHM source is 
> > correct it starts to look at the PPS clock and after a while the PPS

> > clock is used as main source. This is correct behaviour. Now I 
> > disconnect the antenna from the GPS card and the SHM interface stops

> > providing timestamps, as the GPS clock is unreliable. You can see in

> > the sources list that the SHM clock is marked unreachable. But the
PPS 
> > pulses are still provided and Chrony keeps using the PPS as 
> > synchronisation source. I think this is not correct behaviour.
Chrony 
> > should check if any absolute time source is reachable and
synchronised 
> > every time when a PPS signal comes in. If not it should also mark
the 
> > PPS sources unreachable. This behaviour is also shown by ntpd.
>
> 
> I disagree. chrony is able to keep time to an accuracy of 1/2 sec
between
> the pps pulses, even if some are missed. The local clock is assumed
not
> be jumping around by seconds at a time, or nothing, chrony, ntp, you,
> will every be able to discipline it. Anyway, you should always have
some
> other fallback source from the internet listed to make sure that the
the
> system does not suddenly jump. Ie, the theory is that once the time is
> within 1/2 sec then the pps clock can discipline the local clock,
using
> the ability of the local clock to discipline the time.
> 

I agree with you that chrony will be able to keep time between the pps
pulses. But in my situation I cannot blindly trust the incoming PPS
signal
being the correct time. When the GPS card has no lock it keeps
generating
PPS pulses from its own oscillator, but it will be free running and
drifting
fast as no GPS corrections come in. So somehow I have to tell chrony not
to
trust the PPS source anymore when GPS lock is gone. I used to do this
for
ntpd by making the SHM clock unreachable, but it works differenty in
chrony.
If you would like to always trust any incoming PPS signals, even if no
absolute reference source is available, maybe I can solve it by
implementing a chronyc command to disable specific reference clocks. 

Also the setup I use chrony in does not have internet access. It is an
isolated network where the server running chrony is providing ntp time
to all
the other connected devices. So I cannot use a backup NTP source, the
only
source is the GPS reference time.

Best regards,

Tjalling Hattink

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