Re: [chrony-users] Understand why system clock is bad even though chrony offsets look fine

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

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
> 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
> 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@xxxxxxxxxxxxxxxxxxxx 
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.