Timer Lag

In early versions of Windows Minesweeper the game clock was slower than real time.


Timer lag on Windows 3.1 after 500s

Timer lag is when the game clock runs slower than real time. During the 1990s it was common knowledge that running multiple programs could slow the Minesweeper timer on Windows due to limited computer memory. For example, a search of old Usenet posts finds an Ulrich Steimann (Germany) reporting on 22 March 1994 that he could win Expert in less than 20 seconds by running another game in the background on his 20 MB Pentium 4861.

The Minesweeper community started recording videos using Camtasia in 2000 and on 3 June 2001 Georgi Kermekchiev (Bulgaria) noticed Minesweeper timers were not counting real time. A possibility was that Camtasia was slowing the clock but multiple players soon reported that Minesweeper seemed to count only 480 "seconds" for every 500 seconds on Windows 98 when no other programs were running. David Barry (Australia) performed tests without naming his operating system and found the Minesweeper clock lagged 13s for every 500s with the CPU at 57%, 16s when running Camtasia at 8fps, 17s running Camtasia at 10fps and 17s when using the music player Winamp. David and Matt McGinley (USA) published an article on 13 June 20012 proposing a link between the timer and computer memory.

Personal computers in those days used a cheap quartz crystal clock powered by a battery. The "Real Time Clock" (RTC) on Windows 3.1 / 95 / 98 / ME would read time in integer seconds based on the 18.2 hertz oscillation of the clock. This 18.2 hertz frequency was chosen because there are 3600 seconds in one hour and 16 bit computers can only store integers up to 65535, with a hertz representing completion of one "calculation" (requiring a minimum of 2 system calls) per second. At 18.2 hertz there are 2^15 completed calculations per hour and the clock can tick over from 65535 and start again at 0. Setting the clock to oscillate at this frequency means however that system calls can only take place every 55 milliseconds (one oscillation) and this limits accuracy. Windows 2000 introduced the ability to record time to 1ms but it defaults to 10.0ms (uniprocessor HAL) or 15.6ms (multiprocessor HAL)3 while Windows XP and later versions of Windows default to 15.6ms (64 hertz)4.

Source code for Windows NT 4.0 (from 1996) was leaked in 2004 including the source files for Windows Minesweeper. Minesweeper uses the WINAPI SetTimer function to call the WM_TIMER function every 1000ms. The first problem is that WM_TIMER messages are low priority5. When the SetTimer function ticks it sets a boolean flag and when Minesweeper reads the WM_TIMER message the flag is reset to 0. Programs running on the same thread will share a message queue with Minesweeper and the WM_TIMER message is not processed unless the message queue is empty. In other words, if Minesweeper is being bombarded with mouse input messages and is sharing a message queue the timer will update more slowly than real time. The second problem is that the SetTimer function attempts to tick every 1000ms which is impossible. The SetTimer function instead ticks every 1043ms because it can only tick on multiples of 55ms. Over the course of 500 seconds the Minesweeper clock only counts 479 seconds! This explains the 480 seconds reported by multiple players since Minesweeper starts the clock at 1 second on your first click. A combination of these two problems means the Minesweeper clock always runs slower than real time.

Do the higher frequency timers of Windows 2000 and later solve this problem? You might think so because tick intervals of 10.0ms and 15.6ms divide nicely into 1000ms. Unfortunately, the timer lag problem exists but not as badly for all versions of Windows Minesweeper until the Arkadium Windows 8 version. For example, a quick test on a 2.5 GHz Windows 7 machine with 6 GB RAM running at 65% memory counted 493 seconds for the Windows XP version and counted 493 seconds for the Windows 7 Oberon Media version. A similar test using a quad-core 1.0 GHz Windows 10 machine with 8 GB RAM running at 50% memory counted 496 seconds for the Windows XP version but counted real time for the Windows 10 Arkadium version. Exact results depend on your machine and the programs you are running but it appears the Arkadium version finally implemented a game loop that reads time correctly.

The end result is that the timer on historical versions of Minesweeper cannot be trusted. This is one of many reasons the Minesweeper community introduced Minesweeper Clones in 2004 to replace Windows Minesweeper, which is no longer accepted for world records.


Pictures

Usenet post in 1994 discussing Minesweeper timer lag

Windows 3.1 timer lag (479s)

Windows ME timer lag (478s)

Windows XP Minesweeper timer lag on Windows 7 (493s)

Windows 7 Minesweeper timer lag on Windows 7 (493s)

Windows XP Minesweeper timer lag on Windows 10 (496s)

Windows 10 Arkadium Minesweeper with no timer lag


References
1 comp.sys.ibm.pc.games.misc - Steimann reports Minesweeper timer lag in a post dated 22 March 1994.
2 A Clockwork Mines - Barry and McGinley suggest the timer lag bug is caused by high memory usage.
3 Time is the Simplest Thing - Newcomer explains issues with Windows timers and message queues.
4 High Resolution Time Stamps - Microsoft confirms clock frequencies and details available high resolution timers.
5 Message Queues - Microsoft explains how messages and message queues work.