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 |____ un...@physics.ubc.ca
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 <mlich...@redhat.com>
Sendt: 10. oktober 2019 16:24
Til: chrony-users@chrony.tuxfamily.org <chrony-users@chrony.tuxfamily.org>
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-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email listmas...@chrony.tuxfamily.org.
--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email listmas...@chrony.tuxfamily.org.