RE: Re: Fix for get_s_time()

["Dan Magenheimer" <dan.magenheimer@oracle.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2958 bytes --]

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

> You know, its more like hpet on system time.

I wonder how much of the problems we observed with skew on pit was due to
the pit-on-tsc "bug"... in other words, should the virtual pit be based on
system time also?

Dan


  -----Original Message-----
  From: Dave Winchell [mailto:dwinchell@virtualiron.com]
  Sent: Friday, April 25, 2008 7:54 PM
  To: dan.magenheimer@oracle.com
  Cc: Keir Fraser; Tian, Kevin; xen-devel@lists.xensource.com; Ian Pratt; Dave Winchell
  Subject: RE: [Xen-devel] Re: Fix for get_s_time()


  Hi Dan,

  I just need to remove some debug and merge with unstable.
  I should be able to send you a patch Monday or Tuesday.
  You know, its more like hpet on system time.
  Thanks for the testing offer.

  Regards,
  Dave


  -----Original Message-----
  From: Dan Magenheimer [mailto:dan.magenheimer@oracle.com]
  Sent: Fri 4/25/2008 5:03 PM
  To: Dave Winchell
  Cc: Keir Fraser; Tian, Kevin; xen-devel@lists.xensource.com; Ian Pratt
  Subject: RE: [Xen-devel] Re: Fix for get_s_time()

  Hi Dave --

  Are you ready to release the guest-virtual-platform-timer
  on xen-system-time patch yet?  If so, we'd be happy to
  give it some testing.

  Thanks,
  Dan

  > -----Original Message-----
  > From: Dave Winchell [mailto:dwinchell@virtualiron.com]
  > Sent: Friday, April 25, 2008 1:48 PM
  > To: Dave Winchell
  > Cc: Keir Fraser; Tian, Kevin; dan.magenheimer@oracle.com;
  > xen-devel@lists.xensource.com; Ian Pratt; Dave Winchell
  > Subject: 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@virtualiron.com> 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
  > >>
  > >>
  > >>
  > >>
  > >
  >
  >
  >




[-- Attachment #1.2: Type: text/html, Size: 5523 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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