From: Shai V. <sva...@gm...> - 2010-09-03 09:43:16
|
Hi Henry and Ron, Just to verify, I have duplicated this problem on my PC as well. This appears to be related to the selected Power Options settings (Control Panel, Power Options). I believe this can also happen if you have a variable frequency CPU as the time calculation is performed using QueryPerformanceCounter which counts CPU cycles and not time. Ron, can you verify this by disabling power options in your host? Thanks, - Shai On Fri, Sep 3, 2010 at 1:42 AM, Henry Nestler <hen...@ar...> wrote: > Hello Ron, > > we don't use RDTSC directly. We use windows API, and that should work > without problems. KeQueryPerformanceCounter is the only function with > smallest time interval. Of curse I also have seen updates for broken > KeQueryPerformanceCounter: http://support.microsoft.com/kb/896256 > > The problem is not to follow the time. If the timediff is more as one > second, for example if you suspend Windows, then we set the time absolutely. > The problem is, from where we can get the exact time stamp, if > KeQueryPerformanceCounter is wrong? > > Here we have the two calculations. One on Windows side, here we calculate > the difference of "jiffies" in callback_return_jiffies: > > http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/kernel/monitor.c?view=markup#l366 > > co_os_get_timestamp is here: > > http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/os/winnt/kernel/lowlevel/time.c?view=markup#l31 > > On Linux side we increment teh jiffies and time here in function > co_handle_jiffies: > > http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/patch/base-2.6.33.diff?view=markup#l2563 > > I will create more debug for cases of "time warps". > > -- > Henry > > > > On 02.09.2010 13:06, Ron Avriel wrote: > > 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 > > > > -- > 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 > > |