Date: Sun, 20 Oct 2013 16:49:15 -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: <1382309355.92499.127.camel@revolution.hippie.lan> In-Reply-To: <78B77E93-BE2E-4CA2-9D1B-F994B795FABB@FreeBSD.org> References: <0D53AF4E-9EC4-42E1-8D9E-1ECB87A9CCE6@FreeBSD.org> <1382306602.92499.117.camel@revolution.hippie.lan> <78B77E93-BE2E-4CA2-9D1B-F994B795FABB@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2013-10-20 at 23:30 +0100, Mark Robert Vaughan Murray wrote: > On 20 Oct 2013, at 23:03, Ian Lepore <ian@FreeBSD.org> wrote: > > > On Sun, 2013-10-20 at 17:13 +0100, Mark Robert Vaughan Murray wrote: > >> Hi folks > >> > >> I asked a similar question to this a month or so ago, then got involved in other work, so apologies for the repetition! > >> > >> The random(4) device benefits from having a decent hardware get_cyclecount() implementation. In i386 and arm, we have a stopgap version that uses binuptime(), which is slow and prone to quantisation error. > >> > >> I've hacked up a minimalist hardware version for ARMv6/RPI (which is the only ARM I have access to, and I'm keen to use it for other things as well), and I'm looking for improvement advice and/or commit blessing. > >> > >> Things it could conceivably do better: > >> > >> 1) The counter is 32 bits only. At clocks of hundreds-of-megahertz, this will overflow in some 10's of seconds to maybe a minute, so it would be nice (but to essential) to trap the overflow with an interrupt and increment an upper-half counter, making a 64-bit counter. > >> > > > > Wouldn't that amount to creating a one-off implementation of > > binuptime()? (Except not one-off, but one-per-SoC-off). > > Not sure, but its get_cyclecount() that I'm trying to get to work on as many systems/SoCs as possible. > > On amd64 and i386 (not the really early ones) get_cyclecount() reads the TSC register (64-bit). This is hardware, and the timing info is really useful for stochastic event timestamping due to its resolution. > > 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 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.) 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? -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1382309355.92499.127.camel>