Date: Sun, 20 Oct 2013 17:58:03 -0600 From: Ian Lepore <ian@FreeBSD.org> To: Mark Robert Vaughan Murray <markm@FreeBSD.org> Cc: freebsd-arm <freebsd-arm@FreeBSD.org> Subject: Re: ARM counter registers and get_cyclecount() Message-ID: <1382313483.92499.136.camel@revolution.hippie.lan> In-Reply-To: <25608D4E-C299-498A-8F77-3548D711F419@FreeBSD.org> References: <0D53AF4E-9EC4-42E1-8D9E-1ECB87A9CCE6@FreeBSD.org> <1382306602.92499.117.camel@revolution.hippie.lan> <78B77E93-BE2E-4CA2-9D1B-F994B795FABB@FreeBSD.org> <1382309355.92499.127.camel@revolution.hippie.lan> <25608D4E-C299-498A-8F77-3548D711F419@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2013-10-21 at 00:01 +0100, Mark Robert Vaughan Murray wrote: > On 20 Oct 2013, at 23:49, Ian Lepore <ian@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 On the very newest arm boards I have there are counters that can run as fast as 66 MHz (cpu runs at 800-1000 MHz). That's by far the fastest I've seen yet. On older boards it's likely to be a few MHz at best. It's a pity you don't think the names are important. IMO, the names of things are at least as important as the implementation (and often more so, because they're harder to change and that puts a greater premium on getting them right). -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1382313483.92499.136.camel>