> 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