Re: Re: Fix for get_s_time()

[Dave Winchell <dwinchell@virtualiron.com>]

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