RTools 3.2.52 brings with it a small, but important fix, related to the last part of this article on the GP Austin coverage.
The issue itself: When we began the deck registration period, we started all four clocks together. The way the networking system works, there is occasionally slight delays between each clock starting, but a .5-1 second delay isn’t a big deal, and the total delay here was about 2 seconds between the four clocks. (that just told us that it would be better to use two clocks for the event, which we ended up doing) I noticed, however, that the clock we labelled “4” (the furthest right of the four from where we were observing) was about 5 seconds off the others after a couple minutes. At that point, I got out my iPhone and started another timer to track against this one clock.
It became quickly apparent that the clock was not counting time correctly. The big thing that cleared out almost all non-RTools issues was that the “4” machine was identical to “2” and “3” in hardware and software, and neither of those two were exhibiting this.
How RTools does timers: One value is stored in memory for any given timer. When the clock is stopped, it is the number of milliseconds remaining on the clock; when it is running, it is the UNIX time stamp that is when the clock will hit 0:00. RTools queries the current UNIX time stamp a couple times a second, and displays a quick calculation and conversion of the stored memory and queried time stamp as the remaining time. This code has literally not been touched since it was first built, due to it’s simplicity and robustness.
What caused the issue: As far as I have been able to tell through testing, the issue is with the route I used to get the time from the computer. There are two “big” ways of getting a time representation in Java: System.currentTimeInMillis() and System.nanoTime(). (I had never heard of the latter before this weekend) The former on Windows is a direct call to a simple Windows-maintained location, while the latter is a more complex (and slower) call to hardware-maintained locations. I was calling the former, and apparently Windows can’t be trusted 100% to maintain that number. (though, to be fair, this is the first time this has happened in tens of thousands of hours counted by RTools timers)
What the fix is: I replaced all instances of the former call with the latter call. A little extra conversion code was also added, as the latter call is one million times as sensitive as the former and behaves in a slightly different manner. (we’re talking milliseconds and nanoseconds of precision here – nothing that would affect us for tournament operations)