Hi, Ask-- Thanks for responding with data-- and also to Courtney and Andreas/Ist_hoe. However, they didn't compare a VM to a un-virtualized real machine under equivalent network and peering conditions, as Ask did, so I'll respond to this message in particular.
On Mar 25, 2011, at 12:18 AM, Ask Bjørn Hansen wrote: > On Mar 24, 2011, at 21:13, Chuck Swiger wrote: >> On Mar 24, 2011, at 7:42 PM, Ryan Tucker wrote: >>> If you do run ntpd, everything is fine. It has no problems keeping >>> accurate time, and the PLL stats show no differences from real hardware. >>> It makes for perfectly capable pool servers, too. >> >> Please show me some data, ie, "ntpq -pcrv" output..... > > RHEL5 with Xen (with a bunch of busy virtual machines; this is from one of > the DomU's): > > $ ntpq -pcrv -n > remote refid st t when poll reach delay offset jitter > ============================================================================== > +204.235.61.9 130.207.244.240 2 u 3 256 377 68.210 0.773 0.492 > -149.20.68.17 204.123.2.72 2 u 5 256 377 9.867 2.227 0.276 > +216.144.229.211 209.81.9.7 2 u 55 256 377 1.315 0.425 1.145 > -207.171.7.151 164.67.62.212 2 u 2 256 377 0.177 -1.297 2.468 > -207.171.7.152 164.67.62.212 2 u 255 256 377 0.281 -0.944 1.295 > *64.142.122.38 .PPS. 1 u 195 256 377 20.514 0.845 0.910 > assID=0 status=0664 leap_none, sync_ntp, 6 events, event_peer/strat_chg, > version="ntpd [email protected] Thu Nov 26 11:35:07 UTC 2009 (1)", > processor="i686", system="Linux/2.6.18-194.17.1.el5xen", leap=00, > stratum=2, precision=-20, rootdelay=20.514, rootdispersion=24.269, > peer=53430, refid=64.142.122.38, > reftime=d136bb52.54000de8 Thu, Mar 24 2011 23:57:22.328, poll=8, > clock=d136bf16.ef99279c Fri, Mar 25 2011 0:13:26.935, state=4, > offset=0.896, frequency=-61.361, jitter=0.942, noise=0.553, > stability=0.418, tai=0 > > Compared to an ntpd running on "real hardware" (RHEL6) on the same network > and with the same configuration: > > $ ntpq -pcrv -n > assID=0 status=0664 leap_none, sync_ntp, 6 events, event_peer/strat_chg, > version="ntpd [email protected] Thu May 13 14:38:25 UTC 2010 (1)", > processor="x86_64", system="Linux/2.6.32-71.18.2.el6.x86_64", leap=00, > stratum=2, precision=-24, rootdelay=20.641, rootdispersion=16.029, > peer=9542, refid=64.142.122.38, > reftime=d136bea6.4abedf91 Fri, Mar 25 2011 0:11:34.291, poll=9, > clock=d136bf75.93abbfca Fri, Mar 25 2011 0:15:01.576, state=4, > offset=-0.209, frequency=-15.105, jitter=0.151, noise=0.251, > stability=0.048, tai=0 > remote refid st t when poll reach delay offset jitter > ============================================================================== > +204.235.61.9 130.207.244.240 2 u 412 512 377 67.985 -0.047 0.585 > +69.50.219.51 128.138.188.172 2 u 386 512 377 11.790 -0.165 0.177 > -209.114.111.1 132.163.4.101 2 u 406 512 377 50.861 -0.420 0.247 > -207.171.7.151 164.67.62.212 2 u 407 512 377 0.408 -2.047 0.064 > -207.171.7.152 164.67.62.212 2 u 397 512 377 0.213 -1.945 0.041 > *64.142.122.38 .PPS. 1 u 207 512 377 20.641 -0.250 0.126 Well, take a look at the peerstats-- especially offset and jitter-- and ntpd's rv assessment of the offset, jitter, and stability of the kernel clock it is adjusting. The worst-case peer jitter if a factor of 4 worse in the VM (2.468 vs. 0.585); best case is a factor of 7 difference: 0.276 vs 0.041; and the jitter for the stratum-1 source using PPS is also a factor of 7 worse for the VM (0.910 vs 0.126). You can repeat the same analysis with offset values and rv stats. The real hardware is keeping better time than the VM by between a factor of 5 and a full order of magnitude. And this is a VM which is well configured, has a good number of nearby peers, and doesn't appear to be heavily loaded. I've seen VM stats where only ticker panic 0 kept ntpd from giving up entirely, with jitter in the 10s or 100s. Regards, -- -Chuck _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
