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

[Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>]

Dan Magenheimer wrote:

> 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).
>  
Dan,

We should have the option on a per guest basis, as to whether that
guest sees the hpet in the acpi tables. This is because one guest
that I know of, Windows 2k8, doesn't keep good time with hpet with
either of the two policies that I support now.  I may be able to come
up with a policy for 2k8, but still, we should have the ability
to turn hpet off. Furthermore, the great accuracy I have been reporting
is for Linux guests, which, so far, all have computed missed ticks.
Windows 2k3 does not compute missed ticks, and I have a policy for it
which keeps it relatively accurate, but as I recall, not as accurate
as the Linux guests.

To turn the hpet off, not only should we not advertise it in acpi,
but also we should return 0 for the hpet capabilities register as some
guests just try to use the hpet regardless of acpi.

Regards,
Dave

> True?
>
> Thanks,
> Dan
>
>  
>
> > -----Original Message-----
> > From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of 
> > Dave Winchell
> > Sent: Monday, April 28, 2008 12:09 PM
> > To: dan.magenheimer@xxxxxxxxxx
> > Cc: Dave Winchell; Tian, Kevin; xen-devel@xxxxxxxxxxxxxxxxxxx; 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@xxxxxxxxxxxxxxx]
> > >    *Sent:* Friday, April 25, 2008 7:54 PM
> > >    *To:* dan.magenheimer@xxxxxxxxxx
> > >    *Cc:* Keir Fraser; Tian, Kevin; 
> > >      
> > xen-devel@xxxxxxxxxxxxxxxxxxx; 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@xxxxxxxxxx]
> > >    Sent: Fri 4/25/2008 5:03 PM
> > >    To: Dave Winchell
> > >    Cc: Keir Fraser; Tian, Kevin; 
> > >      
> > xen-devel@xxxxxxxxxxxxxxxxxxx; 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@xxxxxxxxxxxxxxx]
> > >    > Sent: Friday, April 25, 2008 1:48 PM
> > >    > To: Dave Winchell
> > >    > Cc: Keir Fraser; Tian, Kevin; dan.magenheimer@xxxxxxxxxx;
> > >    > xen-devel@xxxxxxxxxxxxxxxxxxx; 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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
> >
> >    
>  

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