Software Development Laboratories C L O C K M O N v2.3.

0 Windows operating system clock and real time clock (RTC) synchronization and monitoring program

THE PROBLEM I happened to notice that for some time now my Windows system couldn't keep time worth shit. It was constantly losing time, anywhere from several seconds per ho ur or so to many minutes per day (sometimes as much as 15 minutes or more in a s ingle day!) I couldn't figure out why it was happening and just figured either my RTC circui try was bad or the battery was low or something. I even went so far as to instal l a little freeware clock synchronization program that syncs up your computer cl ock to one of the many atomic clock time servers out there on the Internet, and wrote a little batch program to log the results. For several months I simply made note of the fact that my clock was very frequen tly very out-of-sync with the rest of the world and made adjustments to how ofte n I would have to resync it to one of the many atomic clock time servers in orde r to maintain a reasonably accurate time-of-day clock, until eventually I had to resync every few hours. Eventually, though, I began to notice a definite pattern. I noticed that whenever I would get heavily involved in program development, doi ng frequent compiles and links of whatever program I happen to be developing, th e clock would get out of sync more quickly than otherwise. I found this to be *e specially* true (especially noticeable) when I did cross-platform development un der Cygwin, using the GNU make and gcc compiler and other tools. I also noticed that during such Cygwin builds, my mouse would be slightly jerky and somewhat on the sluggish side. This eventually caused me to suspect that the reason my clock was becoming more and more out of sync was because clock interrupts were being lost, gradually cau sing the Windows clock to get further and further behind (i.e. to lose time). A few hours of investigation doing various searches on the web and a few searche s of Microsoft's own support database confirmed my suspicion. However, as what may come to no surprise to some, the various suggested work-aro unds failed to resolve the problem. My clock was still getting out of sync rathe r quickly whenever I did some heavy duty program development. THE SOLUTION Eventually I decided enough was enough and sat down and wrote ClockMon , a handy l ittle program that periodically reads the hardware (BIOS or CMOS) Real Time Cloc k (RTC) and compares it with the Windows operating system clock, resetting the W

indows clock whenever it notices the two are out of sync. ---------------N O T E ClockMon reads the Real Time Clock by doing direct I/O to port 70, which is not normally allowed under the Windows NT/2K/XP security model. But ClockMon is nonetheless able to run on Windows NT, Windows 2000 and Windows XP systems too thanks to a free device driver called giveio. The tiny little giveio device driver simply gives any program (that properly asks for it) the necessary privileges to do direct port I/O. Just do a web search for "giveio" and you should find several places where you can download it from. It also comes with its own complete set of source code just like ClockMon so you can build it for yourself if you want to. ClockMon comes with a (as well as the source which is automatically you don't already have pre-built version of the giveio device driver code too in case you want to build it for yourself) installed the first time you run ClockMon (if it installed on your system of course). ------------------You see, the Windows operating system clock starts out with the same value as th e Real Time Clock whenever you reboot your computer, but from then on, it's upda ted independently of the RTC via periodic clock interrupts. Thus, over time (i.e . as the system runs), it is possible for the Windows operating system clock to get out of sync with the actual hardware Real Time Clock (i.e. the actual true " wall clock" time). This happens because as the system runs, certain software and operating system f unctions sometimes have to disable all interrupts causing the operating system t o sometimes miss a clock interrupt. Most software that disable all interrupts (i ncluding the Windows operating system) don't keep interrupts disabled for very l ong (it's usually only for a VERY short period of time -- usually only a few mic roseconds (millionths of a second) at most), but because they DO disable all int errupts from time to time, clock ticks ARE unfortunately periodically lost, and over time, add up, causing the Windows operating system clock to sometimes diffe r considerably from the actual "wall clock" time (sometimes by several minutes o r more, depending on system load and the variety and type of software programs r unning during the time period in question). When ClockMon notices the Windows operating system clock differs from the actual hardware Real Time Clock by more than a predefined amount (but less than 30 minu tes), it resets the minutes and seconds portion of the Windows system clock to t hat of the RTC, thereby eliminating this annoying "Windows Clock Drift" problem and ensuring a more accurate Windows clock value (since the BIOS/CMOS hardware R TC circuitry operates independently from the underlying operating system and sho uld under normal circumstances always be relatively accurate since it doesn't ha ve to worry about missing an interrupt). USING ClockMon

Clicking the close box or the minimize box simply hides the main window so that it doesn't clutter your screen or taskbar. To actually exit the program, you mus t select the "Exit" function from the "File" menu. Once hidden, you can easily c ause the main window to be redisplayed again by simply double-clicking on its ic on in the System Tray area. Also, if specified, an optional log file named "ClockMon.log" is created and wri tten to as the program runs which logs the current operating system time, the RT C time, and the difference between the two. You have the option of either loggin g every time sample the program makes, or only the samples that cause the system clock to actually be reset. The log file entries look like this: 11/06/02 18:54:36 RTC=54:37.000 SYS=54:36.994 DIF=00:00.006 11/06/02 18:54:39 RTC=54:40.000 SYS=54:39.989 DIF=00:00.011 ** 11/06/02 18:54:41 RTC=54:41.000 SYS=54:41.001 !! DIF=00:00.001 An "**" following the calculated difference between the two times indicates the system clock was reset for that log entry. If the "**" is not present, then the system clock was not reset for that sample. An "!!" indicates that ClockMon disco vered an unusual occurrence: that the system clock was found to be ahead of the RTC time rather than behind it as normally expected (i.e. that the Windows syste m clock appears to be running faster than the Real Time Clock rather than slower as is normally expected). As far as I know, this is only an issue on Windows NT /2K/XP systems and not on Win9x/Me systems. All ClockMon configuration settings can be entered via the Options dialog or spec ified via command-line arguments. Whatever values you specify (either via the Op tions dialog or via command-line arguments) are saved and used the next time Clo ckMon runs: /hide /nohide /log /nolog /logall /nologall /sync /nosync /back /noback /nn show the main window initially hidden show the main window initially visible record the clock drift to the log file do NOT record the clock drift to the log file record ALL time samplings to the log file (ignored if /log not specified) only record samples causing the system clock to be reset (ignored if /log not specified) reset the Windows system clock when it's out-of-sync do NOT reset the Windows system clock; just monitor it do backward syncs too (ignored if /sync not specified) only do forward syncs (ignored if /sync not specified) monitor and/or set clock every this many minutes

(where 'nn' is a number from 1 - 1440) /nnnn reset system time whenever it differs from the RTC time by more than this many milliseconds (where 'nn' is a number from 10 - 9999) Note: to specify this value, you must specify the /nn sampling interval first. The first number is always interpretted as the sampling interval and only the second subsequent number is interpretted as the desired accuracy in milliseconds. force synchronization on RTC seconds update boundary (see discussion further below for details) do NOT force seconds update boundary synchronization clear the log file to empty before starting do NOT clear the log file to empty before starting use "filename" as the name of the log file (if the name contains blanks, surround it with double quotes)

/sec0 /nosec0 /clear /noclear filename

The "sec0" option forces ClockMon to retrieve the RTC time as close as possible t o when the Real Time Clock circuitry actually updates its 'seconds' register. Do ing so ensures the RTC time value it uses to synchronize the Windows system cloc k with is as accurate as possible (i.e. is as close to the actual RTC time as po ssible). Not specifying this option causes ClockMon to use whatever time value wa s returned by the Real Time Clock at the moment it read it, thereby allowing it to be off by up to one second. (The Real Time Clock only returns hours, minutes and seconds (as well as the date of course, but ClockMon doesn't use it), but not milliseconds. Thus, if the "actual" time was, for example, 14:41:53.997 wheneve r ClockMon goes to read the RTC, the value that is returned to it (and the value that is uses to synchronize with) is only "14:41:53" (the Real Time Clock circui try does not "round" the seconds value that it returns to you; it can only repor t what second it actually is "right now"). If ClockMon were to then reset the Win dows system clock to that value, the Windows system clock would then be off by 9 97 milliseconds. Specifying "sec0" however, causes ClockMon to wait until the Rea l Time Clock reports that it is updating its seconds before reading the RTC time value, thus ensuring the RTC time it uses to synchronize the Windows system clo ck with is as close as possible to the actual "true" time. With the 'sec0' option specified, ClockMon is able to achieve, on average, better than 10 milli-second accuracy! NOTE After starting ClockMon for the first time, you must manually configure it before it will begin resyncing your Windows clock. The default settings are to simply monitor the clock, but not to reset (resync) it. If you want ClockMon to sync your Windows clock, you must specifically *tell* it to do that. (The reason the default is specifically to *not* resync your clo ck is to prevent unintended system modifications. Not everyone may want to use C lockMon to resync their clock. Some people may simply want to monitor the inaccur acy of their Windows clock and not resync it, so if you want ClockMon to actually resync your Windows clock, you need to specifically enable that option). SUMMARY Since writing this handy little program and adding it to my Startup folder, my W indows clock is rarely ever out of sync by more than a few milliseconds or so, a

nd I discovered that I don't even need to resync to any of the Internet atomic c lock time servers anymore since, apparently, my Real Time Clock (RTC) is quite a ccurate! (Or at least accurate enough for me; individual results may vary of cou rse.) So, if you're currently frustrated with having your Windows clock being constant ly out of sync, give ClockMon a try, and enjoy having an accurate and reliable cl ock again. :)

"Fish" (David B. Trout) fish@infidels.org "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." - Rich Cook