Re: [Xen-devel] Re: [Xen-users] ntpd under Xen Dom0 exhibits extremely high jitter/noise? runs stable/quiet under non-xen kernel.

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

On 19/01/2010 02:12, "mail ignored" <0.bugs.only.0@xxxxxxxxx> wrote:

> (1) *is* there, in fact, a bug here?

It's not clear. It could alternatively be a problem with the HPET on that
specific system. Have you reproduced your issues on a different type of
system (making sure that HPET platform timer is detected and used on that
system too, of course)? That would then obviously point more at it being a
software bug. What is the make/model of the system exhibiting the problem,
by the way?

> (2) which Timer is, in keeping with any/all issues discussed @ the
> aforementioned wiki page, recommended?

HPET or ACPI-PM timers ought to work equally well, assuming bugs haven't
crept into Xen's code paths for either one, and both are implemented
correctly by the hardware Xen is running on. I have to say I think it's
unlikely to be a software bug, because Xen's code paths to use HPET and
ACPI-PM timers are really very simple indeed -- it's hard to see where a bug
could exist in there. But of course that doesn't make it absolutely
impossible.

> (3) is the *real* answer simply intended to be "try them all, pick what
> works"?

Well, really there oughtn't to be enough of a difference between them for
anyone to really notice or care which is actually being used. If this does
turn out to be a hardware issue, then yes that is just the kind of case
where you might expect to have to tweak things on the Xen command line.

One option for us is to change the priority ordering of platform timers to
prefer ACPI-PM above HPET, when both are available. That would assume that
ACPI-PM is more reliable than HPET across a wide range of systems though. We
don't really have much evidence one way or the other.

Another would be to dynamically detect platform timers that aren't working
well and disable them at run time. That would require some more thought, and
isn't going to be something for Xen 4.0 at this point.

 -- Keir



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