FYI the issues reported are related to the VPN link I am using to access the US NIST servers. If I deactivate openvpn then the issues are corrected . Re-activating it recreates the issues. I was intrigued why ntpdate was seeing the servers and it looks like it may be due to its use of a non root source port. There is possibly some firewall in the vpn link blocking root traffic. Anyway ntp is working as designed.
Regards, Mike > Le 2 août 2015 à 16:58, Charles Elliott <elliott...@comcast.net> a écrit : > > In your NIST server anomaly email, you are using an older version of ntpdate; > my output from ntpdate is much different from yours. > > As far as the refid for time-c.nist.gov goes, in your output it is different > in two places, neither of which is correct: > > refid [129.6.15.30], delay 0.11169, dispersion 0.00015 > > ntpq -pn on this system showed > 129.6.15.30 43.77.130.254 2 u 13 16 377 86.501 1.132 0.582 > > All that being said, it is a good catch; there is obviously something wrong. > However, with older versions of ntdpdate and possibly ntpd, there have been > so many changes it is hard to tell what is wrong, whether it is a programming > error or an NIST error. However, it appears that 43.77.130.254 is registered > to a university in Tokyo, Japan. Is some enterprising young Japanese lad > performing experiments, or is NTPD performing inverse IP address lookups > incorrectly again? > > I have achieved much better results from ntpd (currently offset=0.030818 > milliseconds and sys_jitter=0.014405 milliseconds) by selecting up to 9 NTP > servers that are physically close to me and are not heavily loaded. And I > avoid using the pool servers, period. Pool servers in the United States > apparently use computers not even the Salvation Army will give away to the > poor. In addition, in my experience, they are not well maintained. > > NTPD error is proportional to the distance between the client and server > machines. You have very little hope of accessing accurate time by using > servers that are thousands of miles away from you, and thousands of miles > from each other. Time-c.nist.gov is located in the American state of > Maryland, which on the east coast; access time for me is about 18 > milliseconds. India.colorado.edu is located slightly west of the middle of > the United States, and access time for me is 53 milliseconds. Right this > minute, they are both showing about the same time, about 1.7 milliseconds > apart, but ordinarily I would expect the difference to be greater than that. > In any case, my ntpd client almost never selects time-c.nist.gov because I > can access physically closer servers with less jitter. > > > Charles Elliott > > >> -----Original Message----- >> From: questions [mailto:questions- >> bounces+elliott.ch=comcast....@lists.ntp.org] On Behalf Of Mike Cook >> Sent: Sunday, August 2, 2015 5:32 AM >> To: Questions List >> Subject: [ntp:questions] iburst and NIST servers >> >> Hi, >> Can anyone confirm that this is an issue? >> >> I habitually put an burst directive in my ntp.conf server statements. >> ex: >> >> server 129.6.15.30 noselect iburst minpoll 4 maxpoll 6 >> server 128.138.140.44 noselect iburst minpoll 4 maxpoll 6 >> server 98.175.203.200 noselect iburst minpoll 4 maxpoll 6 >> >> But in the case of these NIST servers, sometimes they never get out of >> INIT state. >> >> # pool 0.europe.pool.ntp.org iburst >> mike@bb1:~$ ntpq -pn >> remote refid st t when poll reach delay offset >> jitter >> ======================================================================= >> ======= >> o127.127.22.0 .M12+. 0 l 4 16 377 0.000 0.003 >> 0.002 >> +192.168.1.23 .GPS. 1 u 1 16 377 0.473 -0.031 >> 0.011 >> 129.6.15.30 43.77.130.254 2 u 16 16 376 86.082 0.805 >> 0.312 >> 128.138.140.44 .INIT. 16 u - 64 0 0.000 0.000 >> 0.000 >> 98.175.203.200 .INIT. 16 u - 64 0 0.000 0.000 >> 0.000 >> *192.168.1.4 .PPS1. 1 u - 16 377 0.580 0.049 >> 0.018 >> +192.168.1.18 .Neo8. 1 u 2 16 377 0.437 0.019 >> 0.035 >> >> I see in <http://tf.nist.gov/tf-cgi/servers.cgi> the following gotcha >> >> All users should ensure that their software NEVER queries a server more >> frequently than once every 4 seconds. Systems that exceed this rate >> will be refused service. In extreme cases, systems that exceed this >> limit may be considered as attempting a denial-of-service attack. >> >> The refusal appears random as sometimes a server never leaves INIT, >> however if I restart ntpd it may be accepted. >> >> Could there be another explanation? >> >> Regards, >> Mike >> >> "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 "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
