From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Winchell Subject: Re: Re: Fix for get_s_time() Date: Mon, 28 Apr 2008 17:29:49 -0400 Message-ID: <481641CD.4020501@virtualiron.com> References: <20080428141114875.00000002360@djm-pc> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20080428141114875.00000002360@djm-pc> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "dan.magenheimer@oracle.com" Cc: "Tian, Kevin" , "xen-devel@lists.xensource.com" , Dave Winchell , Ian Pratt , Keir Fraser List-Id: xen-devel@lists.xenproject.org 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@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" >>> > 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 >> >> >> > > >