Re: Understand why system clock is bad even though chrony offsets look fine

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 |____ [email protected]
Canada V6T 1Z1 ____|____ and Gravity ______|_    theory.physics.ubc.ca/

On Mon, 20 May 2024, Miroslav Lichvar wrote:

> [CAUTION: Non-UBC Email]
>
> On Thu, May 16, 2024 at 06:01:10PM +0530, Abhijith Sethuraj wrote:
>> > Is this server synchronized to the same NTP server as the computer
>>> running the client application? What root distance does it report?
>> The server is synchronized to another NTP server that we don't have control
>> over. So, I don't think it's possible for me to give you the root distance.
>> It's safe to assume that the server's time is good, as they have a lot of
>> other clients apart from us and no one else reported any issues.
>
> This sounds like a stock exchange.
>
> Can you make a graph of the difference between the server and client
> timestamps you see in your application? You could specify a small
> offset correction in your chrony.conf to minimize the chance it will
> fall outside of the allowed range.
>
>> Sorry, I have one more question here. So, I have three sources here and one
>> among those is preferred (this server is in the same site as my client, the
>> other two are elsewhere). Looking through my measurements log, I see that
>> we're seeing a lot of testC failures for the duration of the issue. We're
>> polling the local server rapidly (minpoll, maxpoll of -4 and filter 5). Is

Why? That is terrible for determining the rate offset of the clock. It means
that whenever there is trouble determining the time, your clock will drift
terribly. And the source clock also experiences time offset errors, and this
means that your clock will experience both the remote clocks errors and its
own and the transmission time errors as well. For any pairs of clocks there is
an "optimum" poll rate to get the best time, and it almost certainly is not
poll -4.


>> it possible that since there are a lot of testC failures (almost 16
>> failures within a second, when the polling frequency should also be ~16
>> times) and since the other two sources are not preferred (also their
>> offsets would be bad compared to the local one), we try to use the freq

So you are trying to do chrony's job for it? Badly?

>> adjustment in driftfile till we get good packets from the preferred source
>> or till we choose one of the non-preferred sources as the best source?
>
> If NTP measurements of the selected source are failing some of the
> tests, the clock will not be updated (unless the fallbackdrift option
> is enabled) and it will drift on its own, mostly due to temperature
> changes.
>
> With such high polling rates you should consider enabling the
> maxdelayquant option. That should limit the length of the runs with
> failed test C.
>
> -- 
> Miroslav Lichvar
>
>
> -- 
> To unsubscribe email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org
> with "unsubscribe" in the subject.
> For help email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org
> with "help" in the subject.
> Trouble?  Email [email protected]
>
>

-- 
To unsubscribe email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org 
with "unsubscribe" in the subject.
For help email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org 
with "help" in the subject.
Trouble?  Email [email protected]