ARM counter registers and get_cyclecount()

Mark Robert Vaughan Murray markm at FreeBSD.org
Sun Oct 20 23:01:06 UTC 2013


On 20 Oct 2013, at 23:49, Ian Lepore <ian at FreeBSD.org> wrote:

>> Last time I looked at binuptime(), it was not nearly as good in the low bits due to quantisation error.
>> 
> 
> Could you be thinking of getbinuptime()?  It returns the time as of the
> last tick, but binuptime() goes all the way to the hardware to return
> the time right now (and it handles counter rollover and such).  There
> may be faster clocks available, which still gives get_cyclecount() some
> value, but binuptime() as a fallback implementation isn't horrible if
> the timecounter is already using the fastest clock available (or at
> least using one that's reasonable fast).

I'm thinking of the numbers I see when I print the output of get_cyclecount() while harvesting stochastic events on various platforms.

> I think we've been here before, but:  get_cyclecount() is a HORRIBLE
> name.  I would be fairly reluctant to implement that using a clock that
> runs slower than the cpu clock, because you'd just be lying, and nothing
> about the name makes it clear that the result might be something other
> than what the name promises.  (And there aren't many arm SoCs that have
> a counter that fast.)

Sigh.

I'm not nearly as concerned with the name as I am with getting the fastest available hardware counter as I can find.

> There are other complexities that come to mind... things like clocks
> that run slower or even stop in power-saving modes, is that a problem?

Yup :-(. But if its fast and the highest-resolution non-quantised timing available, I guess I'll use it. What I don't want is numbers with lots of low bits being non random/skipped; I'd rather have a slower counter still incrementing from the bottom bit up. If its running at CPU/Instruction clock speed, it will do.

M
-- 
Mark R V Murray

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 353 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20131021/54518035/attachment.sig>


More information about the freebsd-arm mailing list