| Re: [chrony-users] chrony switch source issue |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
- To: chrony-users@xxxxxxxxxxxxxxxxxxxx
- Subject: Re: [chrony-users] chrony switch source issue
- From: Miroslav Lichvar <mlichvar@xxxxxxxxxx>
- Date: Tue, 3 Jan 2023 09:37:06 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1672735033; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1AZWhgpykF2uzTWv/ddXLjFUWhi32IarrArEBiI2DRQ=; b=ab/QMryQkRJhJaHANDhig5Qisk8RF0ZSk9352dyM4H4fZNztfMGdrsgYFg+dBKFal/Il0c jJWhUKF4eb7QXpgyIBbgW8WwL+z6ISnu/+EWA3GWN+HF1zku9/WYVegMg6TZaUbjQfY9ri lCrTUByc3ZxIr9RqMq8R55haF4PDGHI=
On Tue, Jan 03, 2023 at 07:41:21AM +0000, Bernstein, Amit wrote:
> And BTW, its still running for 18 hours and still chrony didn't change sources
>
> MS Name/IP address Stratum Poll Reach LastRx Last sample
> ===============================================================================
> #? PHC0 0 4 0 18h -1284us[ -150ns] +/- 87ns
> ^+ gotoro.hojmark.net 2 10 377 784 -1645us[-1645us] +/- 61ms
> ^+ animine.org 2 10 377 446 -1107us[-1107us] +/- 72ms
> ^+ mx.ack512.net 2 10 377 814 +4038us[+4038us] +/- 104ms
> ^* t2.time.bf1.yahoo.com 2 10 377 815 +2050us[+2079us] +/- 38ms
This shows an NTP source being selected.
> I understand, but the behavior doesn't seem right, PHC device with nsec accuracy returns an error for 1 hour, and chrony refuses to replace the source to a usec accuracy NTP source?
It doesn't matter that it is no longer providing new measurements. It
provided some measurements before, they still agree with new
measurements from other sources and their spans still overlap.
> This means chrony still "thinks" that an error response to a PHC device retrieved for 1 hour has better accuracy than NTP? That doesn't make sense.
Your NTP sources claim to be accurate only to tens of milliseconds.
The estimated skew of the PHC source is negligible (10 ppb). The
default maxclockerror is 1 ppm. That's 3.6 milliseconds per hour. It
needs multiple hours to become comparable with the NTP sources.
> If I set the PHC device to return zero instead of a real time, it takes couple of seconds for chrony to identify the timing issue and replace the source to NTP. I think this behavior should occur with PHC device error also.
With an offset of ~53 years that source is immediately marked as a
falseticker. That's a different case than being unreachable.
> Maybe the "smallest interval" you mention is wrongly calculated on PHC error?
There is no special handling of PHC reading errors. If it persist, it
will be handled as an unreachable source, same as an NTP source is
handled when the network is down.
--
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.