Menu
▾
▴
Re: [coLinux-users] Very large time offset in coLinux
|
From: Ron A. <ra...@ho...> - 2010-09-02 11:07:05
|
Hi Henry and Shai, Thanks for answers. Here are some answers and more information: The time always advanced to the future, so far. In one coLinux it jumped forward 30944 seconds, and in another it jumped more than 24 hours (I don't have the exact number). The processor is an Intel Pentium 1.4 GHz. QueryPerformanceFrequency on the server returns 3579545. The problem already occurred several times on different servers, but it can take days or weeks until it happens. I think RDTSC is not a good idea for time measurement, because its speed can change. Are you sure it's used in coLinux? It seems to me that the problem is related to some wrong overflow calculation. I'd check in that direction. I also think that special handling is required if time difference between coLinux wakeups is too large. Perhaps in that case you should get the real time from Windows, like you do on startup? Thanks, Ron Date: Thu, 2 Sep 2010 10:39:10 +0300 Subject: Re: [coLinux-users] Very large time offset in coLinux From: sva...@gm... To: hen...@ar... CC: ra...@ho...; col...@li... Hi Ron, Do you use an AMD processor? If so, can you please be more specific, which one? I *think* that this could be related to an issue I've seen with RDTSC which reports the clock frequency, usually in accordance with QueryPerformanceFrequency (could be a different API, not sure) but has some problems with AMD processors. There should be a workaround, I'll have to dig more into this. Another option is that the RDTSC is not updated properly when the system is in sleep (power maangement). Can you try again without power management enabled and see if the issue is resolved? Thanks, - Shai On Thu, Sep 2, 2010 at 2:42 AM, Henry Nestler <hen...@ar...> wrote: On 01.09.2010 13:37, Ron Avriel wrote: Hi, I have several coLinux running in different Windows hosts. Occasionally, the time in coLinux advances by several hours and up to a day! The time on the Windows hosts always remains correct. This happened on multiple coLinux servers, some of them ran NTP, but it seems that NTP will not adjust clock if the offset is too large. It also happened on a server that did not run NTP. It should be noted that that the the large offset of 9 hours or more happened at once. It's not a small offset that accumulates. How can this happen? Can anyone explain how time is kept in coLinux? I know that vmWare and HyperV have special tools for keeping the VM clock in sync. Is there anything similar in coLinux? What are the recommendations for keeping time in coLinux? In what direction goes the clock wrong? You lost 9 hours, or is it 9 hours in the future? coLinux uses Windows timer with 10Hz (100ms) as time base. In the time where Linux is not running, we count the "losed" ticks. Next time Linux is running again, the internal Linux timer "jiffies" will adjust from the count of "losed" timer ticks. For calculation the clock difference between last Linux running and next Linux entry will calculate as difference into "jiffies". The time base function on Windows side is "KeQueryPerformanceCounter". I don't know, why some machines have such big difference. One option would be, if the Windows timer frequency is not stable, for example the clock frequency will change from one to other call. Then we would count a wrong timer difference. The "clock frequency" is not the CPU frequency. It is the parameter we get from KeQueryPerformanceCounter, and this should be the same value as long the Windows machine is running. See http://www.osronline.com/ddkx/kmarch/k105_3waa.htm An other idea would be an overflow in the clock calculation, on machines with very high "clock frequency". Can you reproduce it? Maybe we can add some debug messages to check the calculation, if the time difference from one to next Linux entry is more as some seconds? Normal it is less than 100 ms, unless Windows goes into suspend (to RAM or to disk) and will wakeup later. -- Henry N. ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ coLinux-users mailing list coL...@li... https://lists.sourceforge.net/lists/listinfo/colinux-users -- Shai Vaingast Author of Beginning Python Visualization http://www.apress.com/book/view/1430218436 |