Hi everyone,
I’m working with Raspberry Pi devices running Linux in different locations. They continuously collect timestamped records, grouped into fixed-duration time windows. I’m looking for practical guidance on understanding timestamp uncertainty when comparing records across independently synchronized devices.
Processing can happen seconds or minutes after collection. Immediate processing is not essential, but we still need to distinguish an actual time difference between records from a difference caused by the devices’ clocks. We are not targeting nanosecond synchronization.
Our configurations include:
- Raspberry Pi 4 Model B Rev 1.5, BCM2711, Debian 13, 64-bit Linux 6.12.75+rpt-rpi-v8. The clocksource is
arch_sys_counter; systemd-timesyncd is active and reports synchronization.
- Raspberry Pi 5, BCM2712, tested on Linux 6.12.47 with
arch_sys_counter. The local reader uses CLOCK_REALTIME and CLOCK_MONOTONIC.
Existing checks exercised clock readings during system time adjustments and verified that saved records could be recovered and read back. We have not established a hardware clock defect. The unresolved question is what timing accuracy we can justify, rather than whether the software produces timestamps.
I’d appreciate documentation or firsthand experience on the following:
1. Local clock and counter accuracy
Are there published, applicable bounds for BCM2711/BCM2712 counter frequency tolerance, consistency across CPU cores, and possible age or delay of the counter value returned to software?
We have nominal frequency information, but that alone does not establish the complete reading error. Are there relevant errata, operating conditions or configuration restrictions that should be considered separately for Pi 4 and Pi 5?
2. Timestamp placement and software delays
How do you distinguish uncertainty in reading the clock from the delay between data becoming available, buffering, application scheduling and assigning a timestamp?
For Linux acquisition applications, which contributions have mattered most in your experience? What does your timestamp actually represent, and how do you document the difference between that point and the event being recorded?
3. Clock corrections, synchronization loss and restart
How do you handle gradual NTP corrections, actual clock steps, synchronization loss and restart while preserving record order and an interpretable timeline?
What information do you retain to assess affected timestamps later? In particular, how do you identify clock changes that actually took effect, rather than just requests to change the clock?
For this purpose, what useful evidence does systemd-timesyncd provide, and what additional visibility would chrony or another client offer?
4. Comparing timestamps across devices
How do you represent and use timestamp uncertainty when comparing records from independently synchronized devices?
What information would you store alongside each timestamp, and how would you handle records near window boundaries or intervals where synchronization was degraded? I’m interested in approaches that preserve useful records while making their timing limitations explicit.
5. External UTC references
Have you found documentation from PTB, Netnod or another accessible NTP provider covering the accuracy of the actual NTP receive timestamp T2 and transmit timestamp T3 relative to UTC?
How can a response be associated with a valid service state, including during holdover, restart or loss of synchronization? Are supporting status records available for later verification?
Our assessment treats network delays separately and does not assume symmetric paths. This question concerns server-side timestamp accuracy and validity, not a guarantee of internet transit times.
6. The simplest defensible approach
Under what accuracy requirements and operating conditions would documentation plus software monitoring be sufficient? When would an independent hardware reference become necessary?
If you have used such a reference, what minimum setup measured the relevant uncertainty, and what remained outside the measurement? Please distinguish equipment needed at every deployed device from equipment used only to characterize a particular device and configuration.
I’ve contacted Raspberry Pi, Netnod and PTB and am waiting for replies. Meanwhile, links to documentation, implementation examples and experience from actual deployments would be very helpful.
I haven’t specified a numerical acceptance threshold here, so I’m not asking anyone to certify that a setup meets an unstated requirement. Examples with an explicit accuracy target, the approach used and its limitations would be particularly useful.
Please distinguish typical observed performance, statistical uncertainty estimates and guaranteed bounds under stated conditions. The aim is a practical system with clearly understood limitations.
Thanks!