- [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub
Re: [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub
Jonathan Behrens <behrensj@...>
toggle quoted messageShow quoted text
I would suggest just removing the mtime synchronization code sample, and replacing it with a reminder that clocks have to be synchronized. There's nothing all that subtle about the code so I don't think folks would have a huge issue figuring it out themselves if they happen to be in the super specific case where it is needed.
The mtime synchronization code sample is only for reference. A platform can have it’s own way (hardware/software) of synchronizing MTIME registers. The code sample shows a simple approach to synchronize MTIME registers assuming MTIMER devices
are running at same frequency and clock drift is taken care in hardware.
I think we need some text to explicitly state expectations around clock drift handling.
If you're interested in reading about pure software approaches to clock synchronization, I recommend looking at
https://www.usenix.org/conference/nsdi18/presentation/geng. They focus on synchronizing clocks between different servers in the same datacenter which if anything is a harder problem.
The main issue I see with the mtime synchronization code sample in the linked spec is that it doesn't do anything to address clock drift. The linked paper claims that CPU clocks can drift by 10 microseconds/second or more, so unless you
have dedicated hardware to prevent drift (in which case why are you bothering with software at all?) you are very rapidly going to observe time readings that differ by more than one tick even if they start out consistent.
One other issue with the "mtime" synchronization by SW approach is that this effectively places an upper limit on the achievable timer unit resolution. It'd be some equation based on the ordered access latency of the reference and target
Has this been explicitly considered? What is the expected upper limit and where should the platform be moving towards in the future? Would further work be needed to enable >=1GHz timer resolution?
Join email@example.com to automatically receive all group messages.