[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] Re: Fix for get_s_time()
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 WinchellSent: 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 --I wonder how much of the problems we observed with skew onYou know, its more like hpet on system time.pit was due tothe pit-on-tsc "bug"... in other words, should the virtualpit be based onFor guests that compute missed ticks, it may not help. That's because heresystem time also?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 youwould still have the time going backwards issue, unless you patched theguest.Most of the hpet accuracy we see is due to clean and correct algorithmsin the guest,in my opinion. Of course we have to do the right things in emulating thehpet in xen. -DaveDan -----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; IanPratt; 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 WinchellCc: Keir Fraser; Tian, Kevin;xen-devel@xxxxxxxxxxxxxxxxxxx; Ian PrattSubject: 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 thatcumulative deviation> >> from 'wall > >> time' over ~12 hours? > >>> > yes, deviation between the guest's time and an ntpreference.> > > >> 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
Lists.xenproject.org is hosted with RackSpace, monitoring our