[pkg-ntp-maintainers] Bug#559634: Bug#559634: no kernel sync and "ntpdc -c kerninfo" reports incorrect estimates of time on Xen dom0

[Michael Bilow]

I've left the daemon running for about 24 hours now since the last 
reset, and I'm still seeing wild swings:

virtual1:~$ ntpdc -c kerninfo
pll offset:           0 s
pll frequency:        104.224 ppm
maximum error:        16 s
estimated error:      16 s
status:               0041  pll unsync
pll time constant:    6
precision:            1e-06 s
frequency tolerance:  500 ppm

virtual1:~$ cat /var/lib/ntp/ntp.drift
-52.501

virtual1:~$ ntpq -p
      remote           refid      st t when poll reach   delay   offset  
jitter
==============================================================================
  ns.intap.net    .STEP.          16 u    -   64    0    0.000    
0.000   0.000
  NAVOBS1.MIT.EDU .STEP.          16 u    - 1024    0    0.000    
0.000   0.000
+navobs1.wustl.e .GPS.            1 u   30   64  377   30.865   35.505  
21.396
*navobs1.gatech. .FLY.            1 u   35   64  377   27.809   66.876  
19.478
+time-a.nist.gov .ACTS.           1 u   41   64  373   33.758   76.914  
21.010
-is.phreaki.com  67.159.5.90      3 u   49   64  377    6.451   44.980  
15.685
-mustang.empire. 199.165.76.11    2 u   25   64  377   14.907   59.414  
13.832
-66-96-98-9.ccup 204.9.54.119     2 u    7   64  377   37.011   52.235  
11.747
-64.73.32.134    1.56.223.198     2 u   37   64  377   39.863   72.497  
19.008

Wall time (from "date") still looks pretty accurate, judging by my 
"atomic" wristwatch.

I've never seen ntpd behave this way on a non-Xen system, so I'm 
becoming convinced that this must be something specific to Xen or at 
least some combination of Xen and something else (such as SMP) 
triggering this strange behavior.