> Le 29 août 2015 à 17:41, Charles Swiger <cswi...@mac.com> a écrit :
> 
> On Aug 29, 2015, at 1:03 AM, Mike Cook <michael.c...@sfr.fr> wrote:
>> For me this would not be considered acceptable. I would NEVER have ntp 
>> servers in virtual machines.
> 
> +1 to this point.
> 
>> Your maxpoll default of 10(1024s) for the pool servers is too high. Try 
>> dropping it to 6 (64s) or 7(128s). 
> 
> -1 to this.
> 
  experience tells me otherwise. 
Here’s a test:
2 clients, same hardware, same LAN segment, same version NTP, same ntp config, 
with exception of their own GPS PPS ref clock.


The 2 clients reference 4 identical servers with the same versions of ntpd, all 
4 have GPS PPS ref clocks in addition to their PPS refs and preferred GPS 
sync’d server.
All servers are on the same LAN segment as the clients. These servers are 
configured with maxpoll 10 on bb2, and 6 on bb3.

ntpq -pn data

bb2
Sat Aug 29 20:59:19 UTC 2015
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
o127.127.22.0    .Neo6.           0 l   13   16  377    0.000    0.002   0.002
*192.168.1.4     .PPS1.           1 u    9   16  377    0.712    0.119   0.015
-192.168.1.15    .PA6H.           1 u  583 1024  377    1.163    0.358   0.056
-192.168.1.16    .MAX7.           1 u  597 1024  377    1.260    0.369 189.435
+192.168.1.17    .ResT.           1 u  493 1024  377    1.261    0.312   0.040
+192.168.1.18    .Neo8.           1 u  600 1024  377    1.136    0.250   0.088

bb3
Sat Aug 29 20:57:18 UTC 2015
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
o127.127.22.0    .NS-T.           0 l   12   16  377    0.000    0.003   0.002
*192.168.1.4     .PPS1.           1 u   10   16  377    0.591    0.064   0.029
+192.168.1.15    .PA6H.           1 u   10   16  377    0.437    0.021   0.037
-192.168.1.16    .MAX7.           1 u    9   16  377    0.583    0.074   0.029
+192.168.1.17    .ResT.           1 u   10   16  377    0.448    0.017   0.030
+192.168.1.18    .Neo8.           1 u   10   16  377    0.593    0.055   0.022

You can see that the maxpoll 10 servers seen from bb2 have delays at >2 times 
that of the same servers seen from bb3.
Reported offset on bb3 is up to 5 times that seen from bb3.
Reported jitter (ntpd’s error bars) is in 3 cases of the same order, though 
greater, but in one is completely anomalous on bb2 . 

 I have not made a complete analysis of this and give the following as a 
probable cause.
Long intervals between client server exchanges allow arp caches to be cleared 
in both clients, servers, routers causing arp resolution (who has IP, I have 
IP, here’s my MAC).
This extra path delay will possibly be asynchronous and offset and jitter will 
be increased .
Here are the clients arp caches to show what I mean:
bb2
mike@bb2:~$ arp -a
livebox-router (192.168.1.1) at 3c:81:d8:db:4e:b4 [ether] on eth0
muon.stratum1.d2g.com (192.168.1.4) at 00:00:24:c6:20:60 [ether] on eth0
electron.home (192.168.1.13) at 34:15:9e:01:e5:9c [ether] on eth0
cubieez.stratum1.d2g.com (192.168.1.124) at 02:cd:07:c1:82:5f [ether] on eth0
mike@bb2:~$ exit
bb3
mike@bb3:~$ arp -a
cubieez.stratum1.d2g.com (192.168.1.124) at 02:cd:07:c1:82:5f [ether] on eth0
livebox-router (192.168.1.1) at 3c:81:d8:db:4e:b4 [ether] on eth0
raspb3.stratum1.d2g.com (192.168.1.17) at b8:27:eb:71:05:50 [ether] on eth0
raspb2.stratum1.d2g.com (192.168.1.16) at b8:27:eb:2b:ab:90 [ether] on eth0
raspb4.stratum1.d2g.com (192.168.1.18) at b8:27:eb:fe:15:fa [ether] on eth0
electron.home (192.168.1.13) at 34:15:9e:01:e5:9c [ether] on eth0
muon.stratum1.d2g.com (192.168.1.4) at 00:00:24:c6:20:60 [ether] on eth0
raspb1.stratum1.d2g.com (192.168.1.15) at b8:27:eb:7e:0b:f2 [ether] on eth0

So in certain application environments using long poll intervals IS detrimental.

I am going to run the same configs overnight with the net loaded to see what 
difference that makes.


Mike


> Unless your hardware is broken, it shouldn't need to ask what the time is 
> every minute just to manage decent timekeeping accuracy.  Admittedly, running 
> on a VM often resembles running on real hardware with a broken clock, but to 
> me that in turn means one should be running ntpd in the hypervisor so that it 
> is managing a real HW clock and let the VMs inherit time from the hypervisor 
> / Dom0 / etc.
> 
> Regards,
> -- 
> -Chuck

"Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une 
petite et provisoire sécurité, ne méritent ni liberté ni sécurité."
Benjimin Franklin
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Reply via email to