[Pool] time reset

Chuck Swiger cswiger at mac.com
Fri Mar 25 17:37:01 UTC 2011


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 4.2.2p1 at 1.1570-o 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 4.2.4p8 at 1.1612-o 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



More information about the pool mailing list