| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] xen PIT timer
On 26 Sep 2005, at 16:22, Ryan Harper wrote:
Keir,
Thanks for the explanation. I'm still trying to reason out why we are
seeing the 'Time went backwards' every now and then, as well as being
able
to forcibly create the issue via serial interrupt floods (holding 'r'
with serial input sent to Xen).
Is either assumption, PIT_CH0 ~= 10ms (Linux) or PIT_CH2 = 1.119380Mhz
source (Xen) more valid? It sounds like either is valid. Though Linux
can be adjusted via ntpd, is there any correcting factor for Xen? I
know we can run ntpd in dom0 and it can update the wall clock timer,
but
AFAICT, wall clock doesn't affect system_timestamp (which is where we
detect the Time went backwards in
linux-2.6-xen-sparse/arch/x86/xen/i386/kernel/time.c).
NTP isn't plumbed thru into Xen yet. So ntpd will only affect the
domain it is run in right now.
Via some trace observation, I've noticed that the per-cpu time in Xen
(specifically stime_local_stamp) can vary widely between cpus. Is this
the best source to be using for updating Linux system_timestamp since
it
can vary significantly ( >1000000 ) between processors?
It is supposed to be a trustworthy source. Given we resync every CPU
every second, being out by 1ms would indicate either a bug in the
resync code or local oscillators jittering by 1000ppm, which is hard to
believe!
I haven't gotten around to doing it yet, but I was going to instrument
irq disable/enable to see how long we run with irq's disable with the
thought that we might be missing some events from which Xen derives
time
calculations. Is this a worthwhile investigation?
It would be interesting. Unless you are sync'ed to the PIT you should
be able to go reasonably long periods with no timer interrupts with no
ill effects (except the CPU time may get to wander off track a little
more than it would otherwise have done). If you are sync'ed to the PIT
(you have no cyclone, hpet or other chipset timer) then CPU0 needs to
take a timer interrupt at least every 50ms or it will miss the 16-bit
PIT counter wrapping.
Do you have any other suggestions on where I should investigate? I
know
this isn't a problem for most folks, but we are still concerned that it
shows up every now and then on our platform under Xen, though we don't
see any of the Linux lost_tick stuff when running Linux.
Getting this stuff right seems a lot harder than it ought to be. There
are clearly problems in the existing code -- if you've been able to
ascertain that there are real sync issues between CPUs (ought by >1ms
relative to each other) then that is a start. I would investigate how
they manage to get so out of sync, when all oscillators in the system
ought to be driven by crystals with stability much better than that.
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home