From 2bd824e16eb4e6ff569a51b2d2411d6fe9f71caa Mon Sep 17 00:00:00 2001 From: Cyd Date: Tue, 11 Aug 2026 10:25:35 -0500 Subject: [PATCH] The clock counts from launch, not from boot Chasing the tick turned up why its period looked quantised: every interval the trace reported was a multiple of 1/32s, which is the spacing between representable float32 values near 474196 - this machine's uptime in seconds. GetRTC returned QueryPerformanceCounter scaled to milliseconds since BOOT, so (Scalar) Now() was a number near half a million and had lost resolution accordingly. That is not only a measurement problem. Scalar is a 32-bit float, so any absolute time held in one degrades as the number grows: 3.9ms apart after nine hours of uptime, 15.6ms after a day and a half, 31.25ms after three days - past which the clock cannot resolve a single 20ms physics step. Two places subtract absolute times in float and inherit it. L4CTRL polls the joystick when (Scalar)Now() - lastJoystickUpdate exceeds 50ms, and lastJoystickUpdate is a Scalar, so that test becomes 62.5ms after three days of uptime and 125ms after twelve: a player's controls get less responsive the longer their machine has been switched on, with nothing on screen to explain it. The smoke emitter in L4VIDRND compares myLastSmoke plus an interval against now, and once the interval falls under the spacing the addition rounds to no change at all. Separately, GetRTC returns a long, and milliseconds since boot overflow one after 24.8 days. Counting from launch fixes the whole class at the source. Every Time arithmetic path is untouched, because those subtract ticks as integers and were always exact - which is also why the simulation itself was never affected, and why the render fraction measured clean. The origin is taken in Startup rather than on first use, so it is fixed before anything reads the clock and no two threads can race to set it. Peer machines already disagreed about this origin, having booted at different moments, so the network is no worse off; reconciling that is what RP412NETCLOCK does. The fix is self-checking: the trace's interval readings should stop being multiples of 0.03125. Co-Authored-By: Claude Opus 5 (1M context) --- MUNGA/TIME.h | 6 ++++++ MUNGA_L4/L4TIME.cpp | 43 ++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 48 insertions(+), 1 deletion(-) diff --git a/MUNGA/TIME.h b/MUNGA/TIME.h index e81d5f6..0375a5b 100644 --- a/MUNGA/TIME.h +++ b/MUNGA/TIME.h @@ -32,6 +32,12 @@ protected: static long ticksPerSecond; static __int64 perfCounterFreq; + // + // The counter reading this process started at, so the clock counts from + // launch rather than from the machine's boot. See GetRTC. + // + static __int64 perfCounterOrigin; + static long GetRTC(); static double GetHiRes(); static __int64 GetHiResTicks(); diff --git a/MUNGA_L4/L4TIME.cpp b/MUNGA_L4/L4TIME.cpp index 75a2d0d..5323823 100644 --- a/MUNGA_L4/L4TIME.cpp +++ b/MUNGA_L4/L4TIME.cpp @@ -14,6 +14,7 @@ SystemClock SystemClock::timer; long SystemClock::ticksPerSecond; __int64 SystemClock::perfCounterFreq; +__int64 SystemClock::perfCounterOrigin; //RB 1/20/07 //volatile long fast_time = 0L; @@ -53,11 +54,42 @@ void Timer_Handler() //~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // +// +// Milliseconds since this process started. +// +// It used to be milliseconds since the machine BOOTED, which is what +// QueryPerformanceCounter counts from, and that had two consequences. +// +// The quiet one: Scalar is a 32-bit float, so an absolute time held in one +// loses resolution as the number grows. Consecutive representable values +// are 3.9ms apart after nine hours of uptime, 15.6ms after a day and a +// half, and 31.25ms after three days - by which point the clock can no +// longer resolve a single 20ms physics step. Anything computed by +// subtracting two absolute times IN FLOAT inherits that, and the joystick +// poll interval in L4CTRL is exactly such a subtraction: its 50ms test +// quietly becomes 62.5ms after three days of uptime and 125ms after +// twelve, so a player's controls grow less responsive the longer the +// machine has been switched on. The smoke emitter in L4VIDRND has the same +// defect, where adding a small interval to a large timestamp can round to +// no change at all. +// +// The loud one: this returns a long, and milliseconds since boot overflows +// one after 24.8 days. +// +// Counting from launch fixes both at the source and leaves every Time +// arithmetic path untouched - those subtract ticks as integers and were +// always exact. Peer machines already disagreed about this origin, having +// booted at different moments, so the network is no worse off; reconciling +// that is what RP412NETCLOCK does. +// long SystemClock::GetRTC() { LARGE_INTEGER count; QueryPerformanceCounter(&count); - return (long)((count.QuadPart * (__int64)1000) / SystemClock::perfCounterFreq); + return (long)( + ((count.QuadPart - SystemClock::perfCounterOrigin) * (__int64)1000) + / SystemClock::perfCounterFreq + ); } double SystemClock::GetHiRes() @@ -97,6 +129,15 @@ SystemClock::SystemClock() //SystemClock::ticksPerSecond = freq.QuadPart; SystemClock::perfCounterFreq = freq.QuadPart; SystemClock::ticksPerSecond = 1000L; + + // + // Time zero. Set here rather than on the first GetRTC call so that the + // origin is fixed before anything can read the clock, and so no two + // threads can race to establish it. + // + LARGE_INTEGER origin; + QueryPerformanceCounter(&origin); + SystemClock::perfCounterOrigin = origin.QuadPart; } //~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~