Menu
▾
▴
Re: [coLinux-users] Very large time offset in coLinux
|
From: Henry N. <hen...@ar...> - 2010-09-02 22:42:58
|
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. |
