Re: Windows time runs faster
<zfkmk@yahoo.com> wrote in message
news:1189776509.408181.117970@r29g2000hsg.googlegroups.com...
On Sep 14, 6:24 am, Roedy Green <see_webs...@mindprod.com.invalid>
wrote:
On Thu, 13 Sep 2007 20:18:42 -0700, zf...@yahoo.com wrote, quoted or
indirectly quoted someone who said :
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.
--
Roedy Green Canadian Mind Products
The Java Glossaryhttp://mindprod.com
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?