4 ms·
If those times are produced on different architectures, then yes, the comparison can never be accurate enough since the underlying measurement mechanisms differ
by ainiriand 1y ago
If those times are produced on different architectures, then yes, the comparison can never be accurate enough since the underlying measurement mechanisms differ fundamentally. While the author goes to great lengths to demonstrate very small time differences, I believe the foundation of their comparison is already flawed from the start. I do not want to generate any polemic sorry!
- Dylan16807 1y agoBut you do or don't think chrony knows how to do the memory barriers and everything else properly? Making the sync work across existing heterogenous hardware is the goal of the exercise. That can't be a disqualifier.
- ainiriand 1y agoChrony is an incredible piece of software, but I am afraid that in this case it is used incorrectly, unless more details are provided. Benchmarking across threadripper AMD, raspberrypi arm, and LeoNTP servers cannot be done lightly. I do not see how going down to the nanosecond scale can be done in this way, without more details, sorry. This is only my opinion and I know it is not very useful here.
- ainiriand 1y agoEven the author acknowledges that when they say: It’s easy to fire up Chrony against a local GPS-backed time source and see it claim to be within X nanoseconds of GPS, but it’s tricky to figure out if Chrony is right or not.
- Dylan16807 1y agoThe thing is, any offset or jitter that can't be picked up over the network is irrelevant to what the author is trying to accomplish. And if it can be picked up over the network, I don't see why Chrony is the wrong thing to measure with. "system time as distorted by getting it to/from the network" is exactly what is supposed to be measured here.