1. Tech-Unixplatformspec
  2. Topics

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

Jonathan

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.

 

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
Anup Patel
 

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
Josh Scheid
 

On Fri, May 28, 2021 at 4:01 PM Greg Favor <gfavor@...> wrote:

More recent ARM SBSA requires a 1 GHz counter resolution, but does not place any requirement on the actual measurable 'time" resolution (i.e. a minimum update frequency).  So one can have 1 ns resolution in the 'time' counter value, but the actual measurable granularity could be just 1 us.

Upping the standard counter resolution seems of little or secondary value.  It's the actual maximum granularity or resolution of measurable time that matters.  Which no one in RISC-V (or ARM SBSA) seems willing or wanting to require actual 1 ns resolution to time measurements.


Right, I'm attempting to refer to the effective timer resolution as opposed to the apparent timer unit period.

I'm just making explicit what this relaxation implies about capabilities in real systems.  Platforms should separately consider whether or not to allow this relaxation based on a threshold for effective timer resolution which must be available on compliant implementations of that platform.

-Josh
Josh Scheid
 

On Fri, May 28, 2021 at 4:07 PM Jonathan Behrens <behrensj@...> wrote:

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

At least at the platform level, the requirement of a single reference clock for all timers in a "system" (thus preventing first-order drift) may be a desirable requirement.

-Josh
Jonathan Behrens <behrensj@...>
 

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
Greg Favor
 

On Fri, May 28, 2021 at 2:44 PM Josh Scheid <jscheid@...> 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?

More recent ARM SBSA requires a 1 GHz counter resolution, but does not place any requirement on the actual measurable 'time" resolution (i.e. a minimum update frequency).  So one can have 1 ns resolution in the 'time' counter value, but the actual measurable granularity could be just 1 us.

Upping the standard counter resolution seems of little or secondary value.  It's the actual maximum granularity or resolution of measurable time that matters.  Which no one in RISC-V (or ARM SBSA) seems willing or wanting to require actual 1 ns resolution to time measurements.

Greg
Josh Scheid
 

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

1 - 7 of 7