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

[Henry N. <hen...@ar...>]

  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.