From owner-freebsd-current@FreeBSD.ORG Fri Apr 18 21:15:12 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93C231065670 for ; Fri, 18 Apr 2008 21:15:12 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id 278668FC2A for ; Fri, 18 Apr 2008 21:15:11 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m3ILF4LU022282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Apr 2008 07:15:05 +1000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m3ILF4c5018968; Sat, 19 Apr 2008 07:15:04 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m3ILF409018967; Sat, 19 Apr 2008 07:15:04 +1000 (EST) (envelope-from peter) Date: Sat, 19 Apr 2008 07:15:04 +1000 From: Peter Jeremy To: Matthew Dillon Message-ID: <20080418211504.GH73016@server.vk2pj.dyndns.org> References: <51610.1208498408@critter.freebsd.dk> <4808E06D.8020304@elischer.org> <200804181930.m3IJUUYx026599@apollo.backplane.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OOq1TgGhe8eTwFBO" Content-Disposition: inline In-Reply-To: <200804181930.m3IJUUYx026599@apollo.backplane.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@freebsd.org Subject: Re: TSC Timecounter and multi-core/SMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2008 21:15:12 -0000 --OOq1TgGhe8eTwFBO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 18, 2008 at 12:30:30PM -0700, Matthew Dillon wrote: > I think it's harder then it sounds. The technology isn't difficult, > the problem is the two requirements people seem to have for a solid > time base these days: > > * Fast access time (in-instruction-stream) > * High resolution (~1nS) > * Not eat up a bunch of die area or current On this last point, just building a 64-bit counter that runs at roughly the CPU clock speed and can be accurately read is non-trivial - a simple ripple-carry counter is probably good for about 4 bits. By the time you add all the carry propagation circuitry, you probably have quadrupled the die area and increased the power consumption by 2 orders of magnitude - though this is still trivial compared to the complete CPU core. To the above list, I'd add: * Counters read by different CPU (potentially on different dies) can be correlated - ie same count rate and fixed count offset. * Wide enough that the software doesn't have to worry about overflows (ie around 64 bits) > If one didn't mind foregoing the high resolution requirement then > the problem is greatly simplified... an external time base, such as > a 1-30 MHz crystal, can be fed into just one bit's worth of=20 > resynchronization logic to generate counter pulses at the cpu's operat= ing > frequency and the counter can then be implemented inside the cpu, > synchronized to its operating frequency. This sounds like a cheap-to-read version of the ACPI-fast counter. The idea sounds reasonable. Now all you need is to convince a vendor to implement it :-) > It kind of turns into a mess no matter how you twist it, as long as > the 'fast access time' requirement is left in place. Agreed. And without fast access time, high resolution is meaningless. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --OOq1TgGhe8eTwFBO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (FreeBSD) iEYEARECAAYFAkgJD1gACgkQ/opHv/APuIcSWACglETeBHXYCnPramvqrduT3NrQ xMgAoJso8I6LVD989ugn7rjvEJOPPEG2 =RmO1 -----END PGP SIGNATURE----- --OOq1TgGhe8eTwFBO--