From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1JzYGU-0000cV-Vz for mharc-grub-devel@gnu.org; Fri, 23 May 2008 10:29:03 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JzYGR-0000bf-TW for grub-devel@gnu.org; Fri, 23 May 2008 10:28:59 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JzYGR-0000bA-44 for grub-devel@gnu.org; Fri, 23 May 2008 10:28:59 -0400 Received: from [199.232.76.173] (port=33858 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JzYGQ-0000b6-TK for grub-devel@gnu.org; Fri, 23 May 2008 10:28:58 -0400 Received: from gateway13.websitewelcome.com ([69.56.160.10]:58299) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1JzYGQ-0002kB-9n for grub-devel@gnu.org; Fri, 23 May 2008 10:28:58 -0400 Received: (qmail 2148 invoked from network); 23 May 2008 14:31:09 -0000 Received: from gator297.hostgator.com (74.53.228.114) by gateway13.websitewelcome.com with SMTP; 23 May 2008 14:31:09 -0000 Received: from c-67-185-142-228.hsd1.wa.comcast.net ([67.185.142.228]:49658 helo=localhost) by gator297.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1JzYGL-0002rZ-01 for grub-devel@gnu.org; Fri, 23 May 2008 09:28:53 -0500 Date: Fri, 23 May 2008 07:28:44 -0700 From: Colin D Bennett To: grub-devel@gnu.org Message-ID: <20080523072844.3189b53a@gibibit.com> In-Reply-To: <87bq2x8cba.fsf@xs4all.nl> References: <20080512093354.2770e1cf@gibibit.com> <20080520104646.18dfaf47@gibibit.com> <87bq2x8cba.fsf@xs4all.nl> X-Mailer: Claws Mail 3.4.0 (GTK+ 2.12.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/2FtfQXwfHvoZRynFTP.XEmq"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator297.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gibibit.com X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) Subject: Re: Higher resolution timers X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2008 14:29:00 -0000 --Sig_/2FtfQXwfHvoZRynFTP.XEmq Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 23 May 2008 13:55:21 +0200 Marco Gerards wrote: > Colin D Bennett writes: >=20 > > On Mon, 12 May 2008 09:33:54 -0700 > > Colin D Bennett wrote: > > > >> I think that using the TSC (w/ RDTSC instruction) and calibrating > >> it with a quick 2-3 RTC tick loop at startup might be the easiest > >> option. > > > > Just wondered if something like this would be a practical way to go: >=20 > Well, I only had a quick look and this might be a good way to measure > the clock speed. BTW, can you please make sure you use our coding > style? Are the 2-3 loops based on some calculations or only a guess? Of course I will adhere to the GRUB coding style. The snippet I posted was just basically just quick pseudocode (not actually compiled) based on 10 minutes of thought. I did not take time to format the code style but surely I would before submitting an actual patch. I think we only need 1 full RTC timer tick (i.e. 1/18 of a second) to figure out how many TSC cycles correspond to one second of real time. The code has to first synchronize to the starting edge of an RTC tick, so that is the loop: do { ... } while (start_tick =3D=3D initial_tick); Then the number of elapsed TSC cycles until the next RTC tick is calculated and the TSC cycles per second is calculated. (As I said, this is untested and incomplete scratch work as a starting point for a discussion, and it might not even compile.) > There might be a problem with using this instruction. Are clock > cycles actually measured after using the "halt" instruction? If not, > the use of such instruction might not generally used in GRUB :-/ Thanks for thinking of that. According to , the TSC continues counting even when the CPU executes the HLT instruction: The TSC is set to 0 at system reset. It presently increments once per processor cycle, and is 64 bits wide. Only CPL =3D 0 can modify TSC, and then only the lower 32 bits can be set, while the upper 32 bits are cleared. We do not recommend changing TSC, and the library does not permit it. The TSC will continue to increment in the halt state (HLT instruction). Therefore, I think that that the HLT instruction in GRUB will not negatively impact the use of RDTSC. Regards, Colin --Sig_/2FtfQXwfHvoZRynFTP.XEmq Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkg21KQACgkQokx8fzcGbYdujgCeLbXjJ2T+97aR6Q1ZxtxKIS32 FhEAn3nJks72W2XY8owcozPIrGkyZgry =qZgu -----END PGP SIGNATURE----- --Sig_/2FtfQXwfHvoZRynFTP.XEmq--