RE: Re: Fix for get_s_time()

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

OK, then although you are not saying it directly, assuming
your patch is accepted, it sounds like the hpet will now
always be more accurate than pit and the change a couple
of months ago that turns OFF the guest hpet by default
should now be reversed so that the guest hpet is turned ON
by default (or perhaps the option should just be removed
or ignored, with the previous behavior being restored that
hpet is always on).

True?

Thanks,
Dan

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com]On Behalf Of 
> Dave Winchell
> Sent: Monday, April 28, 2008 12:09 PM
> To: dan.magenheimer@oracle.com
> Cc: Dave Winchell; Tian, Kevin; xen-devel@lists.xensource.com; Ian
> Pratt; Keir Fraser
> Subject: Re: [Xen-devel] Re: Fix for get_s_time()
> 
> 
> Dan Magenheimer wrote:
> 
> > 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?
> 
> For guests that compute missed ticks, it may not help. That's 
> because here
> the guests are using tsc in their computations of offset and last
> interrupt time stamp.
> Also, there is the esoteric use of delay in the computations for pit.
> With hpet, on the other hand, the guests don't read the tsc and don't
> use delay -
> they only rely on the hpet main counter.
> 
> It might improve accuracy for a guest that does not compute missed
> ticks. But you
> would still have the time going backwards issue, unless you 
> patched the
> guest.
> 
> Most of the hpet accuracy we see is due to clean and correct 
> algorithms
> in the guest,
> in my opinion. Of course we have to do the right things in 
> emulating the
> hpet in xen.
> 
> -Dave
> 
> >
> > 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
> >     > >>
> >     > >>
> >     > >>
> >     > >>
> >     > >
> >     >
> >     >
> >     >
> >
> >
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>