Menu
▾
▴
Re: [coLinux-users] Very large time offset in coLinux
|
From: Robert I. <and...@ho...> - 2010-09-03 17:36:35
|
Had a few minutes. Code I was thinking of was in Ogre3d.
OgreTimer for Win32 has a section to compensate for PerformanceCounter leaps. Might be worth checking out.
From: and...@ho...
To: sva...@gm...; hen...@ar...
Date: Fri, 3 Sep 2010 18:03:19 +0100
CC: col...@li...
Subject: Re: [coLinux-users] Very large time offset in coLinux
Message body
I have seen some code to support the suggestion that it is down to the QueryPerformanceCounter and CPU scaling. I can't remember if it was in though. SFML, Ogre or Irrlicht are the most likely
--
Sent from my Nokia N900
----- Original message -----
> 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
> >
> >
>
<Attachment> ATT00001
<Attachment> ATT00002
------------------------------------------------------------------------------
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 |
