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

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Tue, May 14, 2024 at 04:35:14PM +0530, Abhijith Sethuraj wrote:
> > 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.

Is this server synchronized to the same NTP server as the computer
running the client application? What root distance does it report?

> 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)?

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.

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.

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