Is there a way to get consistant time across different VMs?

Is there a way to get consistant time across different VMs?

[walmart]

Hi, all:

I want to test some program, which requires a high precise time. (some
thing as rdtsc).

I tested rdtsc on different VMs, they are not consistant. (I am using
Xen 4.0, Fedora 13, 64 bit).

Is there a way to get consistant high precise time across different VMs?

Thanks very much!

Best!

Sam

Re: Is there a way to get consistant time across different VMs?

[Jeremy Fitzhardinge]

 On 09/07/2010 02:12 PM, walmart wrote:
> Hi, all:
>
> I want to test some program, which requires a high precise time. (some
> thing as rdtsc).
>
> I tested rdtsc on different VMs, they are not consistant. (I am using
> Xen 4.0, Fedora 13, 64 bit).
>
> Is there a way to get consistant high precise time across different VMs?

Hm, you're walking into a bit of a minefield.

What are your precise requirements for:

    * accuracy
    * resolution
    * monotonicity
    * cross-cpu synchronization
    * cross-process synchronization

?

In general rdtsc isn't very useful as a timesource, since there are many
ways in which it can fail/do strange things from processor to processor
and system to system, so "s[a]me thing as rdtsc" doesn't tell us much.

However, in modern versions of Xen, you can turn on rdtsc emulation
which makes rdtsc generate a guaranteed global monotonic time value at a
nominal 1GHz rate (I think, or did that change to the starting CPU
speed?).  But the downside is that it results in a trap'n'emulate of the
instruction which is a bit more expensive than a raw rdtsc.

Or if you have a new Intel system with a really, truly nonstop
synchronized tsc, you can use rdtsc directly.

But if neither of those are acceptable/possible, you need to use the
normal Xen system time, which has a 1ns resolution, is fairly precise,
but not generally completely monotonic between cpus.  It also isn't
usable from usermode without some extra kernel patches.

    J

Re: Is there a way to get consistant time across different VMs?

[walmart]

Hi, Jeremy:

Thanks for the reply.

I have pinned two VMs on the same core (1 VCPU per VM), but the rdtsc
reading from them are different. What I want are monotonicity,
accuracy, and low cost.

I think I'll try to turn on rdtsc emulation.I found this on the web:
http://lists.xensource.com/archives/cgi-bin/extract-mesg.cgi?a=xen-devel&m=2009-08&i=830e5c23-96f5-4e79-9f11-3884735e1c33%40default

I'll try that.

thanks very much!

Best!

Regards,
Sam

On Tue, Sep 7, 2010 at 3:10 AM, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
>  On 09/07/2010 02:12 PM, walmart wrote:
>> Hi, all:
>>
>> I want to test some program, which requires a high precise time. (some
>> thing as rdtsc).
>>
>> I tested rdtsc on different VMs, they are not consistant. (I am using
>> Xen 4.0, Fedora 13, 64 bit).
>>
>> Is there a way to get consistant high precise time across different VMs?
>
> Hm, you're walking into a bit of a minefield.
>
> What are your precise requirements for:
>
>    * accuracy
>    * resolution
>    * monotonicity
>    * cross-cpu synchronization
>    * cross-process synchronization
>
> ?
>
> In general rdtsc isn't very useful as a timesource, since there are many
> ways in which it can fail/do strange things from processor to processor
> and system to system, so "s[a]me thing as rdtsc" doesn't tell us much.
>
> However, in modern versions of Xen, you can turn on rdtsc emulation
> which makes rdtsc generate a guaranteed global monotonic time value at a
> nominal 1GHz rate (I think, or did that change to the starting CPU
> speed?).  But the downside is that it results in a trap'n'emulate of the
> instruction which is a bit more expensive than a raw rdtsc.
>
> Or if you have a new Intel system with a really, truly nonstop
> synchronized tsc, you can use rdtsc directly.
>
> But if neither of those are acceptable/possible, you need to use the
> normal Xen system time, which has a 1ns resolution, is fairly precise,
> but not generally completely monotonic between cpus.  It also isn't
> usable from usermode without some extra kernel patches.
>
>    J
>