Two possibilities... many power management features
have gone into Xen and there are many bug fixes post-3.3
to improve time sync in the presence of power management.
However if power management is NOT happening on your system,
it's possible that your processors have bad TSC skew
that Xen's TSC synchronization mechanism is unable to
handle. (This seems unlikely with a dual core... AMD
might have information otherwise.)
A nice feature that went into Xen 3.3 is the ability to
measure the skew between physical processors. The
"xm debug-key t" takes only one sample, but it can
be repeated many times and will retain max and avg
for all of the samples.
Can you do:
# for j in $(seq -w 10000); do xm debug-key t; done
in dom0, then send the output from "xm dmesg | tail"
If you can do this both with Xen 3.3 and 3.4 (when it
is released, or xen-unstable now), that would be great!
-----Original Message-----
From: Carsten Schiers [mailto:carsten@xxxxxxxxxx]
Sent: Friday, March 27, 2009 3:19 AM
To: xen-devel
Subject: [Xen-devel] Time went backwards 885 ms
Dear all,
I thought this might be worth again to report:
After rebooting a 3.3.1/2.6.18.8 environment on my AMD 4050e, I received a
885ms delta just
after powernow-k8 loaded:
Mar 26 21:28:37 data kernel: powernow-k8: Found 2 AMD Athlon(tm) Dual Core
Processor 4050e processors (version 2.20.00)
Mar 26 21:28:37 data kernel: powernow-k8: 0 : fid 0xd (2100 MHz), vid 0xe
Mar 26 21:28:37 data kernel: powernow-k8: 1 : fid 0xc (2000 MHz), vid 0xf
Mar 26 21:28:37 data kernel: powernow-k8: 2 : fid 0xa (1800 MHz), vid 0x11
Mar 26 21:28:37 data kernel: powernow-k8: 3 : fid 0x2 (1000 MHz), vid 0x16
Mar 26 21:28:37 data kernel: Timer ISR/1: Time went backwards: delta=-885437842
delta_cpu=6562158 shadow=11822142480 off=436198 processed=12708016520 cpu_p
rocessed=11816016520
Mar 26 21:28:37 data kernel: 0: 12704016520
Mar 26 21:28:37 data kernel: 1: 11816016520
Find full xm dmesg, xm info, and syslog of boot attached.
Otherwise, the environment is more stable; Time went backwards appear roughly
every 2-3 days,
mostly when there is a 1,0->2,1GHz jump when munin asks for CPU. It is reduced
in addition by a
4 sec sampling time of the ondemand govenor.
Will test 3.4 as soon as released.
BR,
Carsten.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home