Submitted On 25-OCT-2006
The workaround outlined above is not really working. I still have problems when it comes to wait 8ms. That causes my Sprite to move unsmooth. It is very annoying, because I cannot do anything! Maybe there is an additional error in Time measurement too.
Submitted On 29-OCT-2006
The workaround should cause the timer interrupt to be set to 1ms - you should be able to verify this using the perfmon tool. Please advise if this is not the case, with full platform details and VM version.
For the more general issue of using clocks and timers on win32 please see my blog entry:
Submitted On 04-MAY-2007
Ran across this on windows 2000. The workaround seems to be working. Windows 2003 doesn't seem to exploit this bug, so I'd say MS has changed something..
Submitted On 03-JUN-2008
I am confirming the bug on JDK 6 Update 6 running on Windows 2003 SP2.
(that is "system time goes too fast when calling sleep(45)")
David Balažic <xerces(5+3) aat butn period net>
(yes, that is an eight)
Submitted On 06-JUN-2008
The bug is still in Windows 2008 SP1 (and presumably Vista SP1, since they are the same).
Tried single CPU/core system and a quad core system.
Submitted On 07-JUN-2008
I'm unclear what is being reported as still being in Windows 2008. This bug (the fact that the flag works incorrectly) has not been fixed in the JDK - period.
Whether later Windows versions have changed the default timer interrupt rate I can't say. But note that some applications you run - particular multi-media apps will change the timer rate. So it is entirely possible that on a "multi-media" version of Windows that a higher timer rate is always in effect. Again the perfmon tool can be used to show this.
Submitted On 09-JUN-2008
Sorry, I was referring to the "system time goes too fast when calling sleep(45)" issue of Windows.
Submitted On 08-DEC-2008
How do we fix this problem for our JBoss-Application-Server? You should not start threads in an app server.
And the other problem is were should we place this Daemon-Thread?
Should we start a "TimeAdjustApp" that only contains this daemon thread?
Submitted On 04-JAN-2009
The daemon thread just has to exist in a VM on the system - it only takes the presence of one application to change the interrupt rate. I don't know how JBOss is deployed, nor how apps are run on it so I can't be more specific.
Submitted On 30-DEC-2009
"...so anyone using the switch must be satisfied with the way their application is behaving..."
Or maybe users noticed that this switch does not work at all so they avoided it altogether. Fix the bug please :)
PLEASE NOTE: JDK6 is formerly known as Project Mustang