[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: Fix for get_s_time()



Keir,

Last nights run had the error in the 12 ppm range.
Here is the change we have been talking about.

-Dave

Dave Winchell wrote:

Keir Fraser wrote:

On 24/4/08 17:04, "Dave Winchell" <dwinchell@xxxxxxxxxxxxxxx> wrote:

yes, this is the issue. What you suggest should be fine and I am trying
it now.
With the locking version (and a fix to a bug I introduced) I got .0012%
error
on an overnight run with hpet layered on get_s_time_mono(), which is the
max(prev, cur) layer on get_s_time we discussed.


12 parts per million is pretty good. Is that cumulative deviation from 'wall
time' over ~12 hours?

yes, deviation between the guest's time and an ntp reference.

That could easily be explained by the fact that Xen
system time is not sync'ed with ntp.
That's true. And, as we have discussed, this error seems to vary quite a bit platform to platform for some reason. I will verify that this still is the case.

-Dave

-- Keir




diff -r 483d006cc607 xen/arch/x86/time.c
--- a/xen/arch/x86/time.c       Fri Apr 25 13:46:27 2008 +0100
+++ b/xen/arch/x86/time.c       Fri Apr 25 15:40:31 2008 -0400
@@ -836,9 +836,9 @@ static void local_time_calibration(void 
 
     /* Disable IRQs to get 'instantaneous' current timestamps. */
     local_irq_disable();
+    curr_master_stime = read_platform_stime();
+    curr_local_stime  = get_s_time();
     rdtscll(curr_tsc);
-    curr_local_stime  = get_s_time();
-    curr_master_stime = read_platform_stime();
     local_irq_enable();
 
 #if 0
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.