 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / September 2007Windows time runs faster
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 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 On Sep 13, 7:18 pm, zf...@yahoo.com wrote: > 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 > On Sep 13, 7:18 pm, zf...@yahoo.com wrote: > [quoted text clipped - 10 lines] > -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 >> On Sep 13, 7:18 pm, zf...@yahoo.com wrote: >> [quoted text clipped - 16 lines] > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4500388 It sure sounds like you found your answer with that bug listing. > <zf...@yahoo.com> wrote in message > [quoted text clipped - 22 lines] > > 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 > 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 [quoted text clipped - 4 lines] > 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. > 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.  SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com On Sep 13, 8:49 pm, Roedy Green <see_webs...@mindprod.com.invalid> wrote: > On Thu, 13 Sep 2007 14:46:53 -0700, zf...@yahoo.com wrote, quoted or > indirectly quoted someone who said : [quoted text clipped - 13 lines] > Roedy Green Canadian Mind Products > The Java Glossaryhttp://mindprod.com 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 >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. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.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 : [quoted text clipped - 14 lines] > 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. Eugene Zharkov > On Sep 14, 6:24 am, Roedy Green <see_webs...@mindprod.com.invalid> > wrote: [quoted text clipped - 19 lines] > 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? > 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 >> I would hope that Sun has made Microsoft aware of this problem, although >> the [quoted text clipped - 9 lines] > > 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. > 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.