Re: Sv: Sv: [chrony-users] Multi-source: No source change from unreachab

On Sat, Oct 12, 2019 at 5:33 AM Joanna Yurdal <jyu@xxxxxxxxxxxx> wrote:

PTP gets time from GPS and has a good crystal to keep the time. With PTP it is easier since it can be used to sync all devices. Even if clock will not be accurate it will be same for all synced devices. We have a redundancy on network and equipment so we should still have NTP. We are using GPS also but there are cases where it is being jammed and where we operate inside without the GPS coverage. As mentioned before when using NTP we always use it with GPS pulse.

There can be always a failure but having multiple technologies it is always safer that one will work.

From: Bill Unruh <unruh@xxxxxxxxxxxxxx>
Sent: Friday, 11 October 2019, 14:04
To: chrony-users@xxxxxxxxxxxxxxxxxxxx
Subject: Re: Sv: Sv: [chrony-users] Multi-source: No source change from unreachable to reachable one

What is your ntp source and how are you going to make sure it will give you
that kind of accoracy In particular if you are using PTP, are you sure that if
that source goes down, you will not also lose your network to ntp? Ie isn't a
completetly independent GPS a necessity? And what gives the time to PTP?

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 Fri, 11 Oct 2019, Joanna Yurdal wrote:

> We need accuracy below ms at all times, since we are taking images of fast moving objects from different devices. We can tolerate a loss of synchronization for a short time due to adjustment to the new source, but even small delay over a several minutes period of time makes our measurements inaccurate.
> In general we are using PTP to get the accuracy.
> If NTP is used we get are using GPS to help achieve the sync we need ( we cannot use GPS as source just yet, since it is not wired to a Linux pin on some hardware)
> Anyhow thank you all for all the valuable input.
> /Joanna
>
> Fra: Bill Unruh <unruh@xxxxxxxxxxxxxx>
>
> Sendt: 11. oktober 2019 03:58
>
> Til: chrony-users@xxxxxxxxxxxxxxxxxxxx <chrony-users@xxxxxxxxxxxxxxxxxxxx>
>
> Emne: Re: Sv: [chrony-users] Multi-source: No source change from unreachable to reachable one
>
>
>
>
>
>
>
>
> 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 Thu, 10 Oct 2019, chuang213 wrote:
>
>
>
>> This is similar to "chrony switch to low stratum very slow
>
>> "
> https://www.mail-archive.com/chrony-users@xxxxxxxxxxxxxxxxxxxx/msg01974.html
>
>>
>
>> The presumption not to switch clock source often is that the frequency of system crystal is not drift during the period. This might be true
>
>> if the temperature does not change or the system crystal uses a good TCXO/OCXO.
>
>>
>
>> But if the presumption is not there, 10 minutes is long enough that the system clock might drift a lot.
>
>
>
> a) if there is a temp fluctn problem, a linear fit will be bad and the number
>
> of samples saved for the fit will be small, and the system will transition
>
> faster.
>
> b) A large temp effect would be 10PPM. that would mean the system would lose
>
> or gain 1 sec per day, 40ms/hr, 8ms/10 min. Is that intollerable?
>
>
>
>
>
>>
>
>> Frank Huang
>
>>
>
>> On Thu, Oct 10, 2019 at 10:12 AM Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:
>
>>        Why such a short fallover demand? Do you really not care which source controls
>
>>        your clock? chrony operates by
>
>>        accumulating a series of time comparisons, and using a fit to determine the
>
>>        current offset. Usually from ntp one is operating a a poll of something like
>
>>        6-10, or 64-1000 seconds (1-8min) between samples and it accumulates many
>
>>        samples. For an shm it usually accumulates a number of samples (eg 16)
>
>>        and uses the median, with some fraction of the samples thown out for each
>
>>        chrony sample . thus it accumulates one sample per 1/4 min. 10 min is
>
>>        40 samples.
>
>>
>
>>        Why would you have as short a fallover time requirement? Have you really
>
>>        thought through the maths of the clock time to determine what the best
>
>>        strategy is when one of the clocks diappears? If the clock is stable, then the
>
>>        number of samples used is large. If unstable then small.
>
>>
>
>>        Now whether newest from lost source compared to oldest used from good ntp
>
>>        source is the best selection is perhaps not entirely clear. Maybe newest from
>
>>        unreachable with middle one of the ntp source would be better. It needs to be
>
>>        carefully thought through. The problem is that often the unreachable source is
>
>>        only unreachable for a while.
>
>>
>
>>        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 Thu, 10 Oct 2019, Joanna Yurdal wrote:
>
>>
>
>>        > In last test I have made the unreachable source was selected for 10 min. After that I have stopped the test since it is way
>
>>        too long for our failover requirements.
>
>>        > I will not have the system access for a while but I can write more description and provide debug logs at later time.
>
>>        >
>
>>        > Fra: Miroslav Lichvar <mlichvar@xxxxxxxxxx>
>
>>        >
>
>>        > Sendt: 10. oktober 2019 16:24
>
>>        >
>
>>        > Til: chrony-users@xxxxxxxxxxxxxxxxxxxx <chrony-users@xxxxxxxxxxxxxxxxxxxx>
>
>>        >
>
>>        > Emne: Re: [chrony-users] Multi-source: No source change from unreachable to reachable one
>
>>        >
>
>>        >
>
>>        >
>
>>        >
>
>>        > On Thu, Oct 10, 2019 at 01:53:03PM +0000, Joanna Yurdal wrote:
>
>>        >
>
>>        >> chrony.conf:
>
>>        >
>
>>        >> refclock SHM 0 poll 2 dpoll 0 refid PTP0 precision 1.0e-9 delay 1.0e-04 prefer
>
>>        >
>
>>        >> server 192.168.3.103 iburst minpoll 2
>
>>        >
>
>>        >
>
>>        >
>
>>        >> When SHM source looses reachability, each second both s-> last_sample_ago and max_reach_sample_ago are increased by one
>
>>        >
>
>>        >
>
>>        >> The condition never becomes true and the unreachable(invalid) source remains the selected source forever.
>
>>        >
>
>>        >
>
>>        >
>
>>        > No, it shouldn't be selected forever. How long did you wait?
>
>>        >
>
>>        >
>
>>        >
>
>>        > With each sample dropped by the (reachable) NTP source
>
>>        >
>
>>        > max_reach_sample_ago should get smaller and at some point the SHM
>
>>        >
>
>>        > source should become "stale" and be unselected, if it doesn't happen
>
>>        >
>
>>        > earlier due to increased root distance.
>
>>        >
>
>>        >
>
>>        >
>
>>        >> I did not really understand the intention for this a comparison.
>
>>        >
>
>>        >> Was it indented to compare newest sample from unreachable source with the newest sample from reachable source instead?
>
>>        >
>
>>        >
>
>>        >
>
>>        > No, it's supposed to compare the newest sample of the unreachable
>
>>        >
>
>>        > source with oldest sample of a reachable source to determine if the
>
>>        >
>
>>        > spans of the two sources still overlap.
>
>>        >
>
>>        >
>
>>        >
>
>>        > --
>
>>        >
>
>>        > Miroslav Lichvar
>
>>        >
>
>>        >
>
>>        >
>
>>        > --
>
>>        >
>
>>        > 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.
>
>>        >
>
>>
>
>>
>
>>
> --
> 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.
>