RE: [Xen-devel] system time skew measurement patch

["Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>]

> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> 
> > <dan.magenheimer@xxxxxxxxxx> wrote:
> 
> > The patch below printk's useful interprocessor system time skew
> > information.  Patch is relative to xen-unstable.  Printk is
> > rate-limited to output only when O(max skew) grows.  Max skew
> > is measured across all cores/processors... ideally eventually it
> > should be measured for each processor and exported via "xm info"
> > so groups of sync'ed processors can be properly identified.
> >
> > Even on my Core 2 Duo E6850 @ 3.00 GHz (1 socket), I am seeing
> > skew on the order of 6000 cycles (2 usec).  I'm not clear on
> > whether this is due to the calibration algorithm or the
> > hardware.
> 
> This is not unexpected. Stick a max() function at the end of 
> get_s_time()
> and we'll be fine.

All that does is change the problem from a monotonicity problem
to a "time appears to be frozen" problem.  While I agree that
2 usec is unlikely to be noticed by *anyone*, on systems
without good tsc synchronization, this could get much larger
(even when it is corrected once per second).

The patch isn't intended to fix anything, it's just to help
us determine how bad the problem is.  If tsc doesn't skew
across processors more than about 10 ppm in each epoch, I
agree that the max function is probably good enough.

Dan


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