summaryrefslogtreecommitdiffstats
path: root/win/tclWinTime.c
diff options
context:
space:
mode:
authorKevin B Kenny <kennykb@acm.org>2002-04-01 20:44:35 (GMT)
committerKevin B Kenny <kennykb@acm.org>2002-04-01 20:44:35 (GMT)
commit021fe1e9bdb2ad887b654e5185fd137145450be7 (patch)
treede864d00ec66c4bed437304baa0f8fe5b9468e75 /win/tclWinTime.c
parent37dc17ce8795fe95d137e14cf17316113b429172 (diff)
downloadtcl-021fe1e9bdb2ad887b654e5185fd137145450be7.zip
tcl-021fe1e9bdb2ad887b654e5185fd137145450be7.tar.gz
tcl-021fe1e9bdb2ad887b654e5185fd137145450be7.tar.bz2
Made tests for clock frequency more permissive to cope with Win98SE being
observed to return 1.19318 in place of 1.193182 MHz as the performance counter frequency.
Diffstat (limited to 'win/tclWinTime.c')
-rw-r--r--win/tclWinTime.c21
1 files changed, 16 insertions, 5 deletions
diff --git a/win/tclWinTime.c b/win/tclWinTime.c
index d90e8ba..d0aa9ec 100644
--- a/win/tclWinTime.c
+++ b/win/tclWinTime.c
@@ -9,7 +9,7 @@
* See the file "license.terms" for information on usage and redistribution
* of this file, and for a DISCLAIMER OF ALL WARRANTIES.
*
- * RCS: @(#) $Id: tclWinTime.c,v 1.9 2001/11/21 02:36:21 hobbs Exp $
+ * RCS: @(#) $Id: tclWinTime.c,v 1.10 2002/04/01 20:44:36 kennykb Exp $
*/
#include "tclWinInt.h"
@@ -254,17 +254,28 @@ Tcl_GetTime(timePtr)
* - unpredictable changes in performance counter frequency
* on "gearshift" processors such as Transmeta and
* SpeedStep.
+ *
* There seems to be no way to test whether the performance
* counter is reliable, but a useful heuristic is that
* if its frequency is 1.193182 MHz or 3.579545 MHz, it's
* derived from a colorburst crystal and is therefore
- * the RTC rather than the TSC. If it's anything else, we
- * presume that the performance counter is unreliable.
+ * the RTC rather than the TSC.
+ *
+ * A sloppier but serviceable heuristic is that the RTC crystal
+ * is normally less than 15 MHz while the TSC crystal is
+ * virtually assured to be greater than 100 MHz. Since Win98SE
+ * appears to fiddle with the definition of the perf counter
+ * frequency (perhaps in an attempt to calibrate the clock?)
+ * we use the latter rule rather than an exact match.
*/
if ( timeInfo.perfCounterAvailable
- && timeInfo.curCounterFreq.QuadPart != (LONGLONG) 1193182
- && timeInfo.curCounterFreq.QuadPart != (LONGLONG) 3579545 ) {
+ /* The following lines would do an exact match on
+ * crystal frequency:
+ * && timeInfo.curCounterFreq.QuadPart != (LONGLONG) 1193182
+ * && timeInfo.curCounterFreq.QuadPart != (LONGLONG) 3579545
+ */
+ && timeInfo.curCounterFreq.QuadPart > (LONGLONG) 15000000 ) {
timeInfo.perfCounterAvailable = FALSE;
}