Clock Precision and Synchronization
The cluster discusses challenges in achieving high-precision clock accuracy, synchronization, drift, slew, and timing in hardware like CPUs, motherboards, and systems, including use cases, limitations, and comparisons to techniques like NTP or atomic clocks.
Activity Over Time
Top Contributors
Keywords
Sample Comments
feels like the requirements of precision over time (clockdrift) put limits on the usefulness of this method
This doesn't give more timing precision than previous techniques?
How long does it take to get clocks synchronized within a few nanoseconds?
Clock slew is unacceptable for many use cases. For keeping system time on a UNIX server or for astronaut watches, sure. For many other things you need a precise and accurate count of how many micro/nano/pico seconds have passed. You can’t just have one second suddenly be N nanoseconds longer and expect sensitive experiments to not be affected.
So the clock skew is high resolution but the clock rate is low. Makes sense.
What is the use case for microsecond-accurate timekeeping?
I'm struck by how hard it would be to track down a bug that depends on the consistency of the clockrate...
You run the risk of the computational equivalent of speedo not beeing 100% accurate, e.g. clock innacuracy.
on recent good hardware there is no problem being around 1ms accuracy.
Bugs like the ones you describe come down to timing.But it's not like "the old days" where for a specific target, there was only 1 chip/clockspeed so devs simply relied on it for timing since an RTC was or not available, or too slow to access.These days, it would be very hard to actually write code that relies on a specific clock-rate and work reliably. It's a lot easier and reliable to use the clock for time-sensitive stuff.