[ntp:questions] iburst and NIST servers AND NIST server anomaly

Mike Cook michael.cook at sfr.fr
Mon Aug 3 06:51:30 UTC 2015


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.ch at 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.net at 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 at 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 at 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


More information about the questions mailing list