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
|
Home