| Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
You could tell us what the problem, for yourself, would be solved, not
hypothetical cases or problems. That 16 sec is an extremely hypothetical
situation, with the clock actually out by far less than that because of of the
very hypothetical "error" that 16 sec represents. Every new adjustable item
increases the chance of bugs, of confusing the user ("Why not make it a
nanosecond instead of 16 sec and make sure my server is sevinv extrememly
accurate time").
Now if you were to present an actual use case that you had run into where it
would have made a difference, it would be strongr argument.
William G. Unruh __|__Hagler Fellow, Distinguished |_Tel:UBC +1(604)822-3273
Physics&Astronomy _|__ Research Prof, IQSE |__ US +1(979)7399950
UBC, Vancouver,BC _|_ TAMU4242, 578 University Dr |_ unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 ____|__College Stn, Tx, USA 77843 _|_www.theory.physics.ubc.ca
I cannot reply to emails from outlook or hotmail or other microsoft domains.
On Thu, 3 Jul 2025, Christoph Schittel wrote:
[CAUTION: Non-UBC Email]
Miroslav Lichvar schrieb am Donnerstag, 3. Juli 2025 09:19:17 (+02:00):
On Wed, Jul 02, 2025 at 09:59:39PM +0200, Christoph Schittel wrote:
> Could you add an option to force STA_UNSYNC when reaching a settable
limit?
Can you please explain the use case?
At the time the limit of 16s was implemented in the kernel, this was an
reasonable choice. Today for many applications even a (possible) deviation of
1s or less may be regarded as too big and the system should be signaling it
by setting STA_UNSYNC. Reading David R. Mills documentation reads like the
syncing service should set STA_UNSYNC. The kernel setting it, when maxerror
reaches 16s was just meant as last resort.
(Remote) monitoring services could benefit, because hosts with sync problems
could be very easily detected. E.g. NAGIOS instead monitors the clock
difference between itself and remote hosts. This implies the monitoring host
has the "right" time. This could be improved by reading remote hosts
STA_UNSYNC, if it will be set when needed (which should be the admin's
choice, not the kernel's).
regards,
Christoph
--
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.
--
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.