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

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

> Root distance is an estimate of the maximum error. The actual error is
> usually much smaller, but if you don't have something more accurate to
> measure it, you won't know

I see, thanks. That's helpful to know.

> You need a better server for the application server and client to
> minimize the maximum error. It needs to be closer to get a smaller
> root delay and have a better reference clock or better implementation
> to get a smaller root dispersion. Ideally, it should run chrony with
> hardware timestamping

Yup, so the client is behaving suboptimally because it doesn't support hardware timestamping. We'll be replacing the hardware soon.

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? Please let me know if my understanding is incorrect.

Just to be clear, all the questions that I asked are just for my own understanding and to make sure that I'm debugging this issue in the right way, by consulting experts on the subject.

Thanks,

Abhijith

On Wed, May 15, 2024 at 12:40 PM MUZZULINI Frank <Frank.MUZZULINI@xxxxxxxxxxxxxx> wrote:

If you have no control of the server, how do you even know that your time is off and not the server’s time? An application should never crash due to an unexpected timestamp in a received packet, that’s bad programming.

Apart from that, if your machine synchronises itself over the internet, 50us is well within the accuracy that you can achieve. If you really need to compare timestamps with microsec resolution, both systems should synchronise to the same local NTP source, preferably a GPS receiver.

Regards,

Frank

From: Abhijith Sethuraj <abhijithsethuraj4@xxxxxxxxx>
Sent: Tuesday, 14 May, 2024 1:05 PM
To: chrony-users@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [chrony-users] Understand why system clock is bad even though chrony offsets look fine

*EXTERNAL source*

> How did you measure that 50us error? Can you use that source of time

> for synchronization?

Unfortunately, we can't use that as a source. This difference is what an application noticed when it was looking at a timestamp that's there inside a data packet (think of it as tx timestamp from a server that we don't have control over) and what's obtained from system clock via gettimeofday() right when it received the data packet. The reason why we noticed this was because the timestamp from system clock turned out to be lesser than the tx timestamp, which makes the app crash. The network delays through switches and servers likely come to around 50us, which is how we measured it. What do you think is a good indication to catch these issues? Should we look at frequency/freq adjustment of system clock? So far we were only relying on offsets from ref clock, but this issue made us think of time error (root distance) as well. Is there anything else that you would recommend we monitor on our end to catch these issues? Also, if root distance is ~1ms, does that imply that the value of current time that I get from gettimeofday() essentially has an error of ~1ms or is this just inferring to the error in measurements from source (and that the user-space app need not consider this)?

Thanks,

Abhijith

On Mon, Apr 22, 2024 at 12:05 PM Miroslav Lichvar <mlichvar@xxxxxxxxxx> wrote:

On Fri, Apr 19, 2024 at 02:44:21AM +0530, Abhijith Sethuraj wrote:
> Hello,
>
> I'm noticing issues with my system clock being inaccurate by almost 50us,
> even though "System time" in `chronyc tracking` shows offsets in the order
> of ns. This was noticed by an application that tried to get current time by
> calling `gettimeofday()`.

How did you measure that 50us error? Can you use that source of time
for synchronization?

> Root delay : 0.000073557 seconds
>
> Root dispersion : 0.000997235 seconds

Root distance (half of root delay + root dispersion) is over 1
millisecond here. That's an estimate of maximum clock error due to
asymmetries and clock instability.

> almost similar to "root dispersion"? Also, what recommendations do you have
> for monitoring chrony, so that I can catch this before it affects my app?
> Also, are there any config tweaks that I can try out here to help me?

You need a better server, one that has a smaller root dispersion and
hardware timestamping on both the server and client to get the maximum
error below 50 microseconds.

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