3 ms·

He uses Chrony, which uses system time, and compares those times across different machines. Unless proper setup is done the benchmark is faulty.

Dylan16807 1y ago
Chrony is what's comparing the times. Zero code written by the author is running except to log the statistics chrony created. Are you accusing chrony of failing at one of its core purposes, comparing clocks between computers? What could the author do differently, assuming the author isn't expected to alter chrony's code?
- 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 ago
    But 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 ago
      Chrony 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 ago
      Even 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 ago
        The 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.

Dylan16807 1y ago

Chrony is what's comparing the times. Zero code written by the author is running except to log the statistics chrony created. Are you accusing chrony of failing at one of its core purposes, comparing clocks between computers? What could the author do differently, assuming the author isn't expected to alter chrony's code?

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 ago
  But 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 ago
    Chrony 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 ago
    Even 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 ago
      The 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.