I run a Java ATS and noticed that System.currentTimeMillis() "gains" about 8ms on each 5 second interval that I check it. The amount it's running fast continues to build until it totals ~1 second ahead and then it appears to self correct. I'm assuming this comes from drift on my system clock and somehow Windows updates once time is off by > 1 second. I've updated the Windows scheduled task to run at 9am every morning and follow these instructions: http://www.pretentiousname.com/timesync/index.html However, this doesn't do anything for the 1 second drift and it's pointless for me to track ms latency if I'm going to be off by an average of 500ms. Anyhow, is there a way to retrieve an accurate time, all the time? (either through Java or by getting Win7 clock to drift down to single digit ms) Appreciate any suggestions.
There is a bug that Microsoft claims is in Java, and Oracle claims is in Windows. The bug causes clock errors, but it seems to happen mostly when a Java app is started. There is a workaround for Win7, but I cannot remember exactly what I did. Try Googling Win7 Java clock drift. I use the NISTime app for resetting my clock frequently. It's free, and it works well.
Windows clock correction isn't smooth enough. Disable Windows Time Service and install Meinberg NTP, which will "slew" the clock instead of time stepping.
Yes this is true, the clock will have worse drift when a Java app is running. But a real NTP service can still do a pretty good job of correcting it.
Thanks guys for the input. Is there anything more to this than disabling the task in Task Scheduler? Any considerations to be aware of when choosing between NISTtime app and Meinberg NTP? Or is either one fine?
I think NISTtime just corrects the clock once. You need NTP which runs as a service, predicts the drift to constantly and smoothly adjust the clock. You can disable Windows time in services - Start -> Run -> services.msc
It's not a bug, the computer quartz is oscillator is simply very inaccurate (I've worked for the Swedish equivalent to NIST). Download an NTP sync software.
java, bleahhh... have you tried the following: Sun's Java Virtual Machine needs to be started with the -XX:+ForceTimeHighResolution parameter to avoid losing interrupts. from http://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.3. Having said that, losing interrupts would normally lead to the clock slowing down, not speeding up, no?
I've just set up a server with Windows Server 2008 R2 and I'm wondering if it's the same mechanism that manages the clock as in Win7...perhaps they use something better for server OS? Is Meinberg still the best choice?