All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dan Magenheimer" <dan.magenheimer@oracle.com>
To: Keir Fraser <keir.fraser@eu.citrix.com>,
	"Xen-Devel (E-mail)" <xen-devel@lists.xensource.com>
Cc: Dave Winchell <dwinchell@virtualiron.com>
Subject: Xen system skew MUCH worse than tsc skew (was RE: RE: [PATCH] record max stime skew (was RE: [PATCH] strictly increasing hvm guest time))
Date: Thu, 10 Jul 2008 16:42:38 -0600	[thread overview]
Message-ID: <20080710164238562.00000003744@djm-pc> (raw)
In-Reply-To: <C49B7B8E.1ACC8%keir.fraser@eu.citrix.com>

> > 7) CONJECTURE: Result of natural skews between platform
> > timer and tsc, plus jitter.  Unfixable.
> >
> > Possible, untested, not sure how.
> 
> I ended up suspecting this on one of the test platforms I 
> originally did the
> Xen-system-time implementation on. It was an old AMD white 
> box iirc. On that
> system, TSC and platform time seemed to have a significant 
> and inexplicable
> jitter at around 1Hz. The jitter was 100s of ppm, which was totally
> unexpected for what should be crystal-based oscillators. And 
> the test code
> was simple enough that it was hard to suspect that either (I 
> think I was
> just dumping the counters every second or two after reading 
> them as close
> together as I could).

Is this the code in read_clocks() in keyhandler.c?  If so,
I just did an experiment there with some interesting results:

I modified that code to record the "max dif" and then executed
it >10000 times.  The result shows maxdif ~11usec which
corresponds with my earlier measurements.  Next, I replaced the
calls to NOW() in read_clocks() and read_clocks_slave() with
rdtscll().  Guess what?  The result is a maxdif of 11000 "ticks"
but now on a 3GHz clock, which is about 3.3usec.  Next, I disabled
interrupts in read_clocks_slave() around the while loop plus
the rdtscll() so that I ensure I'm not accidentally counting any
interrupts.  Now I'm seeing maxdif<330nsec (>6000 measurements).
Next, I go back to NOW(), but with interrupts disabled as above.
So far maxdif is about 10.7usec (>6000 measurements).

SO XEN SYSTEM TIME MAX SKEW IS >30X WORSE THAN TSC MAX SKEW!

Looks to me like there's still something algorithmically wrong
and its not just natural skew and jitter.  Maybe some corner
case in the scale-delta code?  Also, should interrupts be turned
off during the calibration part of init_pit_and_calibrate_tsc()
(which might cause different scaling factors for each CPU)?

  reply	other threads:[~2008-07-10 22:42 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-02 16:03 [PATCH] strictly increasing hvm guest time Dan Magenheimer
2008-07-02 16:07 ` Keir Fraser
2008-07-02 21:50   ` Dan Magenheimer
2008-07-02 22:41     ` [PATCH] record max stime skew (was RE: [PATCH] strictly increasing hvm guest time) Dan Magenheimer
2008-07-03  8:03       ` Keir Fraser
2008-07-03 16:24         ` Dan Magenheimer
2008-07-03 16:35           ` Dan Magenheimer
2008-07-03 20:03             ` Dan Magenheimer
2008-07-03 23:00               ` Keir Fraser
2008-07-04 15:11                 ` Dan Magenheimer
2008-07-04 15:22                   ` Keir Fraser
2008-07-04 19:32                     ` Dan Magenheimer
2008-07-04 19:56                       ` Keir Fraser
2008-07-10  0:24                         ` Dan Magenheimer
2008-07-10  7:40                           ` Keir Fraser
2008-07-10 22:42                             ` Dan Magenheimer [this message]
2008-07-11  8:27                               ` Xen system skew MUCH worse than tsc skew (was RE: RE: [PATCH] record max stime skew (was RE: [PATCH] strictly increasing hvm guest time)) Keir Fraser
2008-07-11 20:53                                 ` Dan Magenheimer
2008-07-11 21:27                                   ` Xen system skew MUCH worse than tsc skew (was RE: RE: [PATCH] record max stime skew (was RE: [PATCH] strictly increasinghvm " Ian Pratt
2008-07-12 21:05                                     ` Dan Magenheimer
2008-07-11 21:27                                   ` Xen system skew MUCH worse than tsc skew (was RE: RE: [PATCH] record max stime skew (was RE: [PATCH] strictly increasing hvm " Keir Fraser
2008-07-12 21:07                                     ` Dan Magenheimer
2008-07-19 17:51                                 ` Dan Magenheimer
2008-07-21  8:32                                   ` Keir Fraser
2008-07-22 22:27                                     ` Dan Magenheimer
2008-07-22 23:07                                       ` Xen system skew MUCH worse than tsc skew (was RE: RE: [PATCH] record max stime skew (was RE: [PATCH] strictly increasinghvm " Ian Pratt
2008-07-23  0:40                                         ` Dan Magenheimer
2008-07-23  1:16                                           ` Ian Pratt
2008-07-23  6:11                                       ` Tian, Kevin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080710164238562.00000003744@djm-pc \
    --to=dan.magenheimer@oracle.com \
    --cc=dwinchell@virtualiron.com \
    --cc=keir.fraser@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.