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 ______|_ 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-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.
