7 ms·

There are so many inaccurate technical details here I wouldn't know where to begin, let alone write a blog post. Sigh.

jmpman 1y ago
I would be extremely interested in reading your blog post. Fascinating topic.
ainiriand 1y ago
Unfortunately I think the same as you. The provided details in the blog post are by no means any way of doing any sort of time benchmark or network i/o benchmark. For starters, he is comparing times from tsc enabled hardware (x86_i64), with raspberry pi which are arm. Network i/o benchmarking on linux should be done with system calls to the network cards or input devices and not through the kernel drivers etc...
- Avamander 1y ago
  > For starters, he is comparing times from tsc enabled hardware (x86_i64), with raspberry pi which are arm. Well, that TSC-enabled hardware also has other peripherals (like SMBUS as mentioned in the article) that on the other hand introduce errors into the system. I personally use a RPi4 with its external oscillators replaced with a TXCO. Some sellers on AliExpress even have kits for "audiophiles" that let you do this. It significantly improved clock stability and holdover. So much so that "chronyc tracking" doesn't show enough decimal places to display frequency error or skew. It's unfortunate though that the NIC does not do timestamping. (My modifications are similar to these: https://raspberrypi.stackexchange.com/a/109074 https://raspberrypi.stackexchange.com/a/109074) I'd love to find an alternative cheap (microcontroller-based) implementation that could beat it.
  - mwpmaybe 1y ago
    The CM5's NIC has timestamping, but not sure if there's a TXCO hack for it.
pastage 1y ago
Saying this is actually the only same thing to do. I personally will not care for sub 200 microseconds and think it was a good article if read critically. I think it does describe why you should not do that at the moment if you have lots of nodes that need to sync consistently. Having a shared 10Mhz reference clock is great and that gives you a pretty good consistent beat. I never managed to sync other physical sensors to that so the technical gotchas are too much for me. There is madness in time. Edit: changing some orders of magnitude honestly I feel happy if my systems are at 10ms.
- ainiriand 1y ago
  In my opinion when you want such precision, you need to stablish strict constraints to the measurements, for example memory fences: https://www.kernel.org/doc/Documentation/memory-barriers.txt https://www.kernel.org/doc/Documentation/memory-barriers.txt If you do not do this, the times will never be consistent. The author produced a faulty benchmark.
  - Dylan16807 1y ago
    What benchmark? The only numbers he's measuring himself are on the oscilloscope. Everything else is being measured by chrony. Unless you're talking about a different post on the blog?
    - ainiriand 1y ago
      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?

I would be extremely interested in reading your blog post. Fascinating topic.

Unfortunately I think the same as you. The provided details in the blog post are by no means any way of doing any sort of time benchmark or network i/o benchmark. For starters, he is comparing times from tsc enabled hardware (x86_i64), with raspberry pi which are arm. Network i/o benchmarking on linux should be done with system calls to the network cards or input devices and not through the kernel drivers etc...

Avamander 1y ago
> For starters, he is comparing times from tsc enabled hardware (x86_i64), with raspberry pi which are arm. Well, that TSC-enabled hardware also has other peripherals (like SMBUS as mentioned in the article) that on the other hand introduce errors into the system. I personally use a RPi4 with its external oscillators replaced with a TXCO. Some sellers on AliExpress even have kits for "audiophiles" that let you do this. It significantly improved clock stability and holdover. So much so that "chronyc tracking" doesn't show enough decimal places to display frequency error or skew. It's unfortunate though that the NIC does not do timestamping. (My modifications are similar to these: https://raspberrypi.stackexchange.com/a/109074 https://raspberrypi.stackexchange.com/a/109074) I'd love to find an alternative cheap (microcontroller-based) implementation that could beat it.
- mwpmaybe 1y ago
  The CM5's NIC has timestamping, but not sure if there's a TXCO hack for it.

pastage 1y ago

Saying this is actually the only same thing to do. I personally will not care for sub 200 microseconds and think it was a good article if read critically. I think it does describe why you should not do that at the moment if you have lots of nodes that need to sync consistently. Having a shared 10Mhz reference clock is great and that gives you a pretty good consistent beat. I never managed to sync other physical sensors to that so the technical gotchas are too much for me. There is madness in time. Edit: changing some orders of magnitude honestly I feel happy if my systems are at 10ms.

ainiriand 1y ago
In my opinion when you want such precision, you need to stablish strict constraints to the measurements, for example memory fences: https://www.kernel.org/doc/Documentation/memory-barriers.txt https://www.kernel.org/doc/Documentation/memory-barriers.txt If you do not do this, the times will never be consistent. The author produced a faulty benchmark.
- Dylan16807 1y ago
  What benchmark? The only numbers he's measuring himself are on the oscilloscope. Everything else is being measured by chrony. Unless you're talking about a different post on the blog?
  - ainiriand 1y ago
    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?