| Re: [chrony-users] Understand why system clock is bad even though chrony offsets look fine |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
The only way you can find the time error of a computer is to have a more
accurate time available. Using network clocks to determine the error is
subject to huge uncertainties. Get a cheap gps timeing receiver ( they are
about $50), and compare your system time against that.
The root distance is the maimum that yur clock could deviate from that source.
it is NOT a good measure of the error of your system closk. It assumes tht the
transmission from your system to the root source is instantaneous and return
is the whole or the root distance (or vice versa) Clearly a very bed set of
assumptions, But its purpose is NOT to estimate the error of your system, but
the worst case scenarion. If you want beter, get a better root source ( as I
said gps receivers are almost a dime a dozen, but if your system is at the
bottom of a gold mine shaft, then the gps route is not the wat to go.
I have no idea why your system would crash. Sounds to me like really
incompentnt programming.
Note that using that timestamp inside a packet is probably one of the bad ways
of determining the time. That was why Mills developed ntp protocol.
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 |____ unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 ____|____ and Gravity ______|_ theory.physics.ubc.ca/
On Tue, 14 May 2024, Abhijith Sethuraj wrote:
[CAUTION: Non-UBC Email]> 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
ntp is precisely designed to lessen that tranport error, often by factors of
10 or more. The tranport delay is usually approxomate;y symmetric. And tat is
used\to correct the transport delays. Why are you trying to second guess
chrony (or ntp)?
do you think is a good indication to catch these issues? Should we look at frequency/freq adjustment of system clock? So
Unfortunately in ignorance you are assuming you know better than Mills,
Curnoe, Lichvar,... THey have spent huge amounts of time trying to figure out
how best to set the system clock to a remote accurate time source.
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
As I said, get a better local time source(eg gps) is the way. Or get an oven
controlled high accuracy crystal time source which you can connect to gps.
~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.