Date: Mon, 21 Oct 2013 00:01:02 +0100 From: Mark Robert Vaughan Murray <markm@FreeBSD.org> To: Ian Lepore <ian@FreeBSD.org> Cc: freebsd-arm <freebsd-arm@FreeBSD.org> Subject: Re: ARM counter registers and get_cyclecount() Message-ID: <25608D4E-C299-498A-8F77-3548D711F419@FreeBSD.org> In-Reply-To: <1382309355.92499.127.camel@revolution.hippie.lan> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_FE892B73-F41E-414B-8EE8-D6837A37D3F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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. >>=20 >=20 > 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 --=20 Mark R V Murray --Apple-Mail=_FE892B73-F41E-414B-8EE8-D6837A37D3F2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUmRgrt58vKOKE6LNAQqkJgQAsCspAT5s5BZa6xgfwbmYyfFXNcgDPt4/ 4BPvr1f0/PjZ8kN/DIAkLConfAfY4QlVnPCwSuKTE6w60Uj8GAkjkrndd4aP3ogY pkWOQUxzPwPXsPIhUpSo2zcb1PKdtIObr/hL44k69kLMjDQpSnb5VWbN58+WWlut gcgSZaI4lr8= =WX+l -----END PGP SIGNATURE----- --Apple-Mail=_FE892B73-F41E-414B-8EE8-D6837A37D3F2--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25608D4E-C299-498A-8F77-3548D711F419>