Re: [chrony-users] Possible bug in PPS support

[Bill Unruh <unruh@xxxxxxxxxxxxxx>]

If you really need 20usec, then relying on one gps is certainly a bad
decision. You should have two or three machines all with independent gps
sources so you could catch one of them going rogue, or quitting.

You seem to be saying that having no time source whatsoever is better than
having one which may be off by 20us? I think you need to set out the real
conditions that you need in detail ("We need accuracy to 20us" could be
because it was a number that some administrator with absolutely no idea of
time came up with, or it could be a legal requirement, or it could be "we
should be able to do that" kind of requirement) They impliment a system which
can with some confidence deliver that. There are of course no guarentees. A
nuke over the building would severely degrade the accuracy of the clocks in a
way that was totally unpredictable beforehand. Or a power failure. etc.



William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

On Mon, 23 Oct 2017, Rob Janssen wrote:

> Miroslav Lichvar wrote:
> > On Mon, Oct 23, 2017 at 10:24:54AM -0700, Bill Unruh wrote:
> > > On Mon, 23 Oct 2017, Rob Janssen wrote:
> > > > You don't support my calculation that if the clock apparently wandered
> > > > away 3400us
> > > Again, no evidence of that 3400 us.
> > If I understand it correctly, 3.4ms was the offset of the NTP source
> > 13 hours after the PPS stopped working. The stddev of the NTP source
> > from sourcestats is ~50 microseconds, so if the offset was originally
> > better than 1.6ms (there are 3 different sources in the original
> > report with -0.1ms, 1.5ms, 1.5ms offsets), it drifted at least by
> > ~1.8ms in that time.
>
> Yes, I forgot that there was a systematic 1.4 ms offset at the time the PPS 
> sync was
> active so after it ran unsynced for 13h and had a 3.4 ms offset the drift was 
> more like
> 2ms instead of 3.4ms.
> However, that still is 2 orders of magnitude more than we can allow.  So we 
> certainly
> need to alert on this condition, we cannot just freewheel for 13 hours and 
> assume the
> time is still accurate enough.
>
> I am now testing with the root delay/dispersion.   A couple of minutes after 
> the PPS
> has been removed, the root delay remains at 0.000000001 seconds but the root 
> dispersion
> now has increased to 0.000662125 seconds.  That certainly is a value that is 
> immediately
> affected by the lack of sync, however I need to determine a threshold value 
> for the
> monitoring alert.
> The tracking also shows "System time     : 0.000000009 seconds fast of NTP 
> time"
> but I cannot believe the time is still that accurate.
>
> I understand now that the 10ms value shown in "chronyc sources" is based on 
> the 20ms
> roundtriptime of the network towards the NTP source.  This time is quite 
> constant as
> indicated by the low Std Dev but the fixed RTT apparently makes chrony 
> believe the
> network is dodgy (as Bill expresses it).  The only thing dodgy about it is 
> that for this
> particular site there is a systematic offset in the propagation time 
> from/towards the
> site of 1.4 ms resulting in the 1.4ms offset observed when PPS is available, 
> probably
> caused by asymmetric routing.  Other than that, it is quite stable. It is a 
> network
> designed for distribution of audio and video to transmitter sites, well 
> dimensioned with
> guaranteed bandwidth and not overloaded at any time.
>
> Rob
>
>
> --
> 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.

--
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.