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

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.