RE: Re: Fix for get_s_time()

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

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
> >>
> >>
> >>
> >>
> >
> 
> 
>