Return-Path: Received: (qmail 64854 invoked from network); 14 Feb 2004 15:21:14 -0000 Received: from unknown (HELO ptb-mxscan03.plus.net) (212.159.14.237) by ptb-mailstore02.plus.net with SMTP; 14 Feb 2004 15:21:14 -0000 Received: (qmail 51331 invoked from network); 14 Feb 2004 15:21:14 -0000 X-Filtered-by: Plusnet (hmail v1.01) X-Spam-detection-level: 11 X-Priority: 3 X-MSMail-Priority: Normal Received: from ptb-mxcore03.plus.net (212.159.14.217) by ptb-mxscan03.plus.net with SMTP; 14 Feb 2004 15:21:12 -0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Received: from post.thorcom.com ([193.82.116.20]) by ptb-mxcore03.plus.net with esmtp (Exim) id 1As1bU-000D83-Eq for dave@picks.force9.co.uk; Sat, 14 Feb 2004 15:21:12 +0000 X-Fake-Domain: majordom Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1As1a3-0000nt-EO for rs_out@blacksheep.org; Sat, 14 Feb 2004 15:19:43 +0000 Received: from [165.212.11.111] (helo=cmsrelay02.mx.net) by post.thorcom.com with smtp (Exim 4.14) id 1As1Zz-0000nk-5a for rsgb_lf_group@blacksheep.org; Sat, 14 Feb 2004 15:19:39 +0000 Received: from uadvg128.cms.usa.net (165.212.11.128) by cmsoutbound.mx.net with SMTP; 14 Feb 2004 15:19:07 -0000 Received: from usa.net [151.41.154.54] by uadvg128.cms.usa.net (ASMTP/dibene@usa.net) via mtad (C8.MAIN.3.13N) with ESMTP id 488iBNPTD0455M28; Sat, 14 Feb 2004 15:19:03 GMT X-USANET-Auth: 151.41.154.54 AUTH dibene@usa.net usa.net Message-ID: <402E3C77.8000207@usa.net> Date: Sat, 14 Feb 2004 16:19:19 +0100 From: "Alberto di Bene" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rsgb_lf_group@blacksheep.org References: <143.21a3b7d4.2d5ea1b2@aol.com> In-reply-to: <143.21a3b7d4.2d5ea1b2@aol.com> Subject: LF: Re: Timing GPS Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on post.thorcom.com X-Spam-Level: ** X-Spam-Status: No, hits=2.8 required=5.0 tests=FAKE_HELO_USA_NET autolearn=no version=2.60 X-SA-Exim-Scanned: Yes Sender: Precedence: bulk Reply-To: rsgb_lf_group@blacksheep.org X-Listname: rsgb_lf_group X-SA-Exim-Rcpt-To: rs_out@blacksheep.org X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-PN-SPAMFiltered: yes X-Spam-Rating: 1 WarmSpgs@aol.com wrote: >[...] > > >With >programs no longer having direct access to the hardware, the time is whatever Windows >says it is. I expect there are still ways to trigger reading of the system >clock, but there will always be slippage of an unknown number of "ticks", >depending on what processes are running and what priority they have. >[...] > > Maybe there is a way out. In Windows, both 98 and XP, there is API called QueryPerformanceCounter. From the help: The QueryPerformanceCounter function retrieves the current value of the high-resolution performance counter, if one exists. The last sentence "if one exists", is justified by the fact that this *hardware* counter has been implemented in CPUs not older that the Pentium II, or the AMD K7, if memory serves. This counter is a 64-bit register in the CPU core, incremented by a 1,193,180 Hz clock, about 0.838 us resolution. Being hardware, it is not affected by the scheduling priorities of Windows, so it is quite accurate. It's main drawback is that you cannot use it to generate interrupts, you have to poll it to read its value. The main FFT buffers shifting and sheduling timing in Spectran is done using this counter, so I know by experience that it works. Windows docs suggest to use the API QueryPerformanceFrequency to know the actual clock frequency used to increment that counter, but I have found that, at least on all the PCs I have tested, it always returns the value of 1,193,180 Hz. 73 Alberto I2PHD