Re: [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub

Jonathan Behrens <behrensj@...>

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.


On Sun, May 30, 2021 at 8:26 AM Anup Patel <Anup.Patel@...> wrote:

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.





From: Jonathan Behrens <behrensj@...>
Sent: 29 May 2021 04:37
To: jscheid@...
Cc: Anup Patel <Anup.Patel@...>; tech-aia@...; tech-unixplatformspec@...; Atish Patra <Atish.Patra@...>; Greg Favor <gfavor@...>; Alistair Francis <Alistair.Francis@...>; Andrew Waterman <andrew@...>; John Hauser <jh.riscv@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] [tech-aia] RISC-V ACLINT specification is now hosted on RISC-V GitHub


If you're interested in reading about pure software approaches to clock synchronization, I recommend looking at 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.




On Fri, May 28, 2021 at 5:44 PM Josh Scheid via <> wrote:

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 resources, perhaps.


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 { to automatically receive all group messages.