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/
Home Products Support Community News


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

To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>, "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] system time skew measurement patch
From: "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>
Date: Mon, 21 Apr 2008 18:34:29 -0600
Delivery-date: Mon, 21 Apr 2008 17:36:12 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C432D93C.16E57%keir.fraser@xxxxxxxxxxxxx>
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>
Organization: Oracle Corporation
Reply-to: "dan.magenheimer@xxxxxxxxxx" <dan.magenheimer@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acij8qfr3eN+Hq6zQZSPY+jdn0NuoAAD7ehoAANECXA=
> 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.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>