From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Winchell Subject: Re: [PATCH 0/2] Improve hpet accuracy Date: Mon, 09 Jun 2008 17:44:07 -0400 Message-ID: <484DA427.5080006@virtualiron.com> References: <20080609150704468.00000002776@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: <20080609150704468.00000002776@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: Dave Winchell , xen-devel , Keir Fraser , Ben Guthro List-Id: xen-devel@lists.xenproject.org Dan Magenheimer wrote: >I'm wondering what is "magic" about 0.03% in all the non-hw-hpet >measurements. > .03% is simply the maximum error we've seen with hpet. The maximum value (.03) is the same whether its simulated or physical. The best value physical is .001% and I don't remember the best value simulated bit I believe it is under .01%, perhaps well under. I'll have to repeat that measurement. I would think that simulated and physical would give roughly the same drift values, but perhaps at very low drifts that doesn't hold. I think the .03% is mostly due to the stability of the physical hpet device on a platform. I've noticed on some platforms, the simulated hpet time actually improves if you disable the hpet in the bios so that stime() is layered on the pm timer or whatever. I would like to get to the bottom of this hpet stability variance from platform to platform. Regards, Dave > Is that just the accuracy of the underlying tsc >on your test system, e.g. the skew of tsc relative to an external >(ntp) source? Or is Xen (tsc-based) system time skewing that much >on an overcommitted system (and skewing much less than 0.03% on an >unloaded system)? > >Running the following on dom0 both on an unloaded and overcommitted >system (with ntpd off in dom0 and all guests) might be interesting: > ># ntpdate $NTPSERVER; sleep 3600; ntpdate -q $NTPSERVER > >-----Original Message----- >From: Dave Winchell [mailto:dwinchell@virtualiron.com] >Sent: Saturday, June 07, 2008 3:21 PM >To: Keir Fraser; dan.magenheimer@oracle.com >Cc: Ben Guthro; xen-devel; Dave Winchell >Subject: RE: [Xen-devel] [PATCH 0/2] Improve hpet accuracy > > > > >>Possibly there are bugs in the hpet device model which are fixed by Dave's >>patch. If this is actually the case, it would be nice to break those out as >>separate patches, as I think an 11% drift must largely be due to >>device-model bugs rather than relatively insignificant differences between >>hvm_get_guest_time() and physical HPET main counter. >> >> > >Hi Keir, > >I tried an experiment on Friday where I short circuited the missed ticks policy >code in the hpet.c patch, but used the physical hpet each access. The result for Linux >was a drift of .1%, same as the xen-unstable bits. > >Conversely I get very good drift numbers, i.e., under .03%, when using the missed ticks >policy code and running in simulated mode (layered on stime) when stime uses hpet. > >So clearly, the improvement from .1% to .03% is due to the policy code. >I haven't run the short circuit test with the windows policy but I can do that >on Monday. > >Note: For Windows and Linux I get < .03% drift using the policy code and running >simulated mode whether stime is using hpet or some other device. > > >regards, >Dave > > > >-----Original Message----- >From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] >Sent: Fri 6/6/2008 6:34 PM >To: dan.magenheimer@oracle.com; Dave Winchell >Cc: Ben Guthro; xen-devel >Subject: Re: [Xen-devel] [PATCH 0/2] Improve hpet accuracy > >On 6/6/08 21:29, "Dan Magenheimer" wrote: > > > >>Although hwhpet=1 is a fine alternative in many cases, it may >>be unavailable on some systems and may cause significant performance >>issues on others. So I think we will still need to track down >>the poor accuracy when hwhpet=0. And if for some reason >>Xen system time can't be made accurate enough (< 0.05%), then >>I think we should consider building Xen system time itself on >>top of hardware hpet instead of TSC... at least when Xen discovers >>a capable hpet. >> >> > >Yes, this would be a sensible extra timer_mode: have hvm_get_guest_time() >call to the platform time read function, and bypass TSC altogether. This >would be cleaner than having only the vHPET code punch through to the >physical HPET: instead we have the boot-time chosen platform timesource used >by all virtual timers. > > > >>Or maybe there's a computation error somewhere in the hvm hpet >>scaling code? Hmmm... >> >> > >Possibly there are bugs in the hpet device model which are fixed by Dave's >patch. If this is actually the case, it would be nice to break those out as >separate patches, as I think an 11% drift must largely be due to >device-model bugs rather than relatively insignificant differences between >hvm_get_guest_time() and physical HPET main counter. > > -- Keir > > >