WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 0/2] Improve hpet accuracy

To: "dan.magenheimer@xxxxxxxxxx" <dan.magenheimer@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0/2] Improve hpet accuracy
From: Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>
Date: Mon, 09 Jun 2008 17:44:07 -0400
Cc: Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Ben Guthro <bguthro@xxxxxxxxxxxxxxx>
Delivery-date: Mon, 09 Jun 2008 14:44:05 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20080609150704468.00000002776@djm-pc>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20080609150704468.00000002776@djm-pc>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
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@xxxxxxxxxxxxxxx]
Sent: Saturday, June 07, 2008 3:21 PM
To: Keir Fraser; dan.magenheimer@xxxxxxxxxx
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@xxxxxxxxxxxxx]
Sent: Fri 6/6/2008 6:34 PM
To: dan.magenheimer@xxxxxxxxxx; 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" <dan.magenheimer@xxxxxxxxxx> 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



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