Re: [coLinux-users] Very large time offset in coLinux

[Shai V. <sva...@gm...>]

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