Hi Henry,

Can you please explain why you multiply by 100 in

timestamp_diff += 100 * (((long long)timestamp.quad) - ((long long)cmon->timestamp.quad)); /* HZ value */


If this function is called every 100ms, as you previously wrote, then you get 10 jiffies per call. Shouldn't it be 1 jiffy per 100ms? Shouldn't you multiply by 10 instead?

I guess your calculation is right, but I can't figure it out.


Date: Fri, 3 Sep 2010 00:42:47 +0200
From: henry.ne@arcor.de
To: ravriel@hotmail.com
CC: colinux-users@lists.sourceforge.net
Subject: Re: [coLinux-users] Very large time offset in coLinux

Message body 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:

co_os_get_timestamp is here:

On Linux side we increment teh jiffies and time here in function co_handle_jiffies:

I will create more debug for cases of "time warps".