WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] System time monotonicity

To: "John Levon" <levon@xxxxxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] System time monotonicity
From: "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxx>
Date: Mon, 26 Mar 2007 19:50:46 +0100
Delivery-date: Mon, 26 Mar 2007 11:50:22 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20070326182323.GA30728@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acdv05ZXz9R4Ec5DS7+nD3dfOiQ6fwAAc3uw
Thread-topic: [Xen-devel] System time monotonicity
> It seems that VCPU system time isn't monotonic (using 3.0.4). It seems
> it might be correlated to when a VCPU is switched across real CPUs but
I
> haven't conclusively proved that. But e.g.:

What output do you get when you hit 't' a few times on the xen serial
console? 

There's no guarantee that the system time calculated will be perfectly
monotonic, but it should be very close. If the guest needs it to be
monotonic, the time reading code should simply clamp the value that's
read to ensure it always goes up. A little jitter at the microsecond
granularity should be just fine.

On your system it appears to be a couple of microseconds out, which is
on the high side of what we've observed. Normally you only see that kind
of mismatch on systems with TSCs running off different crystals.
 
Ian


>     {
>         old = {
>             time = {
>                 version = 0x4ec
>                 pad0 = 0xe8e0
>                 tsc_timestamp = 0x22cc8398b7194
>                 system_time = 0xe8e0345d8805
>                 tsc_to_system_mul = 0xd62c0083
>                 tsc_shift = '\377'
>                 pad1 = [ '\002', '\027', '\365' ]
>             }
>             result = 0xe8e0484568fa
>             tsc = 0x22cc86921ab00
>             cpu = 0
>         }
>         new = {
>             time = {
>                 version = 0x4ee
>                 pad0 = 0
>                 tsc_timestamp = 0x22cc7db96cd29
>                 system_time = 0xe8e00d1031f3
>                 tsc_to_system_mul = 0xd62ae844
>                 tsc_shift = '\377'
>                 pad1 = [ '\357', '\002', '\365' ]
>             }
>             result = 0xe8e048456012
>             tsc = 0x22cc869225443
>             cpu = 0
>         }
>         delta = 0xfffffffffffff718
>     }
> 
> >From what I can work out, time is supposed to be monotonic but I
admit
> I
> can't really understand the time code yet at least. I couldn't find
any
> documentation on what to expect from system time. Any suggestions?
> 
> This seems to happen across all the hardware we've tried but this
> particular case is a Sun V20Z with two CPUs:
> 
>   x86 (AuthenticAMD family 15 model 5 step 10 clock 2392 MHz)
>         AMD Opteron(tm) Processor 250
> 
> cheers,
> john
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel