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.

 

Regards,

Anup

 

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 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.

 

Jonathan

 

On Fri, May 28, 2021 at 5:44 PM Josh Scheid via lists.riscv.org <jscheid=ventanamicro.com@...> 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?

 

-Josh