Windows time runs faster

[zfkmk]

I realize this is a long shot, but maybe somebody have seen this ...

I have been using the old Java Communication API on windows for quite
a while without problems. Until now. I have an application that
constantly send/receives something via COM1 at 9600. I am on Windows
XP and Java(TM) SE Runtime Environment (build 1.6.0_02-b06). The
problem that I am seeing is that windows time runs faster when the
application is running. I.e., I would start my application, open
Windows Date and Time window, and look at my wrist watch. I see that
Windows time runs about gains about 15 seconds every minute. I see
this happening on two different computers.

I do not think I have ever seen anything that weird.

Eugene Zharkov

 

[zfkmk]

In my application I have multiple threads and I have sleep calls
shorter than 10ms. Maybe that is what causing the problem. I will try
longer sleeps tomorrow to see if that makes a difference ...

Eugene

 

[Manish Pandit]

In my application I have multiple threads and I have sleep calls
shorter than 10ms. Maybe that is what causing the problem. I will try
longer sleeps tomorrow to see if that makes a difference ...

Eugene

This is really interesting. Have you tried running the same on a non-
windows platform ? If not, this could be something to try as well (if
possible).

-cheers,
Manish

 

[Roedy Green]

I see that
Windows time runs about gains about 15 seconds every minute. I see
this happening on two different computers.

Usually the problem is losing time, timer tick interrupts are not
serviced fast enough because interrupts are masked too long.

By any chance is this code deliberately trying to resync the clock?

If you have source, dig around in the code for anything that would
touch the clock.

 

[zfkmk]

This is really interesting. Have you tried running the same on a non-
windows platform ? If not, this could be something to try as well (if
possible).

-cheers,
Manish

No, I have not tried on non-windows platform. But I have a feeling
that this is windows specific. This probably has nothing to do with
the Java Communication API. Here is what I googled on the net:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4500388

Eugene

 

[zfkmk]

Usually the problem is losing time, timer tick interrupts are not
serviced fast enough because interrupts are masked too long.

By any chance is this code deliberately trying to resync the clock?

If you have source, dig around in the code for anything that would
touch the clock.

The application is pretty simple. Aside from the Communication API,
the rest is pure Java. Just a few hundred lines. No deliberate tricks
with clock. No interrupts. Well, there are obviously interrupts from
the COM port somewhere behind the scene. But at 9600 baud there should
not be many of them.

Eugene

 

[Karl Uppiano]

No, I have not tried on non-windows platform. But I have a feeling
that this is windows specific. This probably has nothing to do with
the Java Communication API. Here is what I googled on the net:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4500388

It sure sounds like you found your answer with that bug listing.

 

[Roedy Green]

The application is pretty simple. Aside from the Communication API,
the rest is pure Java. Just a few hundred lines. No deliberate tricks
with clock. No interrupts. Well, there are obviously interrupts from
the COM port somewhere behind the scene. But at 9600 baud there should
not be many of them.

This is WEIRD. I hate it when people give me this answer, but at this
point I can't think of anything else. Have you tried running this
code on some totally unconnected machine, and running some recent
virus scan on your own machine. Pure java should not be capable of
speeding up the clock.

 

[zfkmk]

It sure sounds like you found your answer with that bug listing.

Yes, it looks like that was it. I had Thread.sleep(1). If I replace
the delay with a multiple of 10ms or remove the call altogether, the
clock runs fine.

In my application with a little redesign I can get rid of the sleep
altogether. So I should be fine now. But what a mess this whole sleep
thing on windows is! (I mean the (b) thing from
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5005837).

Eugene Zharkov

 

[zfkmk]

This is WEIRD. I hate it when people give me this answer, but at this
point I can't think of anything else. Have you tried running this
code on some totally unconnected machine, and running some recent
virus scan on your own machine. Pure java should not be capable of
speeding up the clock.

Well, apparently Pure java is capable of speeding up the clock. See my
reply to Karl Uppiano.

Eugene Zharkov

 

[Zig]

Yes, it looks like that was it. I had Thread.sleep(1). If I replace

the delay with a multiple of 10ms or remove the call altogether, the
clock runs fine.

In my application with a little redesign I can get rid of the sleep
altogether. So I should be fine now. But what a mess this whole sleep
thing on windows is! (I mean the (b) thing from
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5005837).

Wow, thanks for the post. We have been running into a similar issue with
some NIO code. After running the program for a while, some windows
machines were showing dramatically accelerated clocks (approx 61 seconds
elapsed on windows per 60 seconds elapsed on linux). It's a problem we had
never seen outside of Windows machines, but we also didn't see it
consistantly for all the Windows machines that we used, so we had been
assuming it was a problem with workstation's hardware clock.

This definately looks like the more likely culprit though.

 

[Karl Uppiano]

Well, apparently Pure java is capable of speeding up the clock. See my
reply to Karl Uppiano.

I think what is happening here is that the "standard" timer interrupt on a
PC is approximately 10msec. The real-time BIOS clock is a higher quality
time-keeper, but Windows does not check this clock regularly. It appears
that they use the free-running timer interrupt to update the system time,
and perhaps periodically sync with a more reliable time source (e.g., NTP).

In Java, timed waits that are not a multiple of 10msec require reprogramming
the timer to run at a different rate (generally faster for higher
resolution). Assuming Java is making Windows system calls to do this, it
seems that Windows should be aware of the change, and take the modified
timebase into account. But evidently they are not (at least not correctly).

I would hope that Sun has made Microsoft aware of this problem, although the
customer visibility and severity of the problem might not be sufficient to
induce Microsoft to fix the bug in Windows, particularly if it is a
complicated or wide ranging fix, or if some legacy applications happen to
rely on this behavior.

As an aside, prior to Vista, you may have noticed a lot of jitter in the
Windows clock application (the second hand doesn't advance every second on
the second). It is a very poor timekeeper. This bug may be fixed in Vista.
The Vista on-screen clocks do advance every second on the second. Heck, they
even animate the overshoot of the stepper motor in a battery operated
mechanical quartz clock. Which raises the question: Why doesn't Vista just
make the second hand move forward smoothly and continuously, like real time
does, instead of emulating the mechanical and power limitations of a battery
operated clock?

 

[zfkmk]

I would hope that Sun has made Microsoft aware of this problem, although the
customer visibility and severity of the problem might not be sufficient to
induce Microsoft to fix the bug in Windows, particularly if it is a
complicated or wide ranging fix, or if some legacy applications happen to
rely on this behavior.

Well, Microsoft seems to aware of the problem:

http://support.microsoft.com/?id=821893

So, this must not be an easy problem to fix.

Eugene

 

[Karl Uppiano]

Well, Microsoft seems to aware of the problem:

http://support.microsoft.com/?id=821893

So, this must not be an easy problem to fix.

It doesn't look like Microsoft fixed it. They provide a work-around, which I
don't know if Sun is using. I wonder if they looked into it.

 

[zfkmk]

It doesn't look like Microsoft fixed it. They provide a work-around, which I
don't know if Sun is using. I wonder if they looked into it.

I am sure they did look. According to:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5005837

they added the ForceTimeHighResolution flag. It looks that the idea
behind that flag was exactly what Microsoft suggested. I.e., call
timeBeginPeriod once at startup, and timeEndPeriod at exit.

As for the other Microsoft's work-around, the QueryPerformanceCounter
thing, I do not see how it can be of any use for the JVM.

Back to timeBeginPeriod/timeEndPeriod. I am not sure if this can be
done at this point. But here is what I would like to see in an ideal
world:

- Modify the definition of the Thread.sleep method to include a
statement like "The suspension time may be longer than requested due
to the scheduling of other activity by the system". I.e., make it
similar to how unix usleep/nanosleep call are usually defined.

- In Windows JVM, by default, do not use any of the timeBeginPeriod
stuff. Just wait for at least 10 ms (or whatever the sleep resolution
time is on a given system).

- In addition to ForceTimeHighResolution, add one more flag, which
would tell the JVM to do timeBeginPeriod/timeEndPeriod for each sleep
call. I.e., do whatever windows JVM does now, but do that only if a
certain flag is specified.

Eugene Zharkov