[ntp:questions] iburst and NIST servers

[Mike Cook]

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
***@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

[Charles Swiger]

Post by Mike Cook
Can anyone confirm that this is an issue?
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.

iburst isn't usually a problem, but minpoll 4 / maxpoll 6 would be
considered abusive without prior arrangements. minpoll 6 is the fastest
rate you should query other NTP servers without explicit permission.

To be more specific, folks who implement per-client firewall rate rules
tend to block clients who exceed ~100 packets per hour.


The main point of iburst is to quickly get a downed NTP server back up
and serving valid time. That matters most for isolated stratum-2+
servers; if you've already got S1 timesources available and multiple
redundant NTP servers locally, using iburst is superfluous.

Sure, use iburst on one remote server entry if you want and/or against
all of the other NTP peers on your local subnet, but it's not obviously
helpful to use iburst everywhere.

Regards,

[Mike Cook]

Just checked that the iburst rate is one packet every 2 secs for a responding client , total 6 .

16:45:00.115534 IP 209.200.39.7.123 > 129.6.15.30.123: NTPv4, Client, length 48
16:45:00.206980 IP 129.6.15.30.123 > 209.200.39.7.123: NTPv4, Server, length 48
16:45:02.122616 IP 209.200.39.7.123 > 129.6.15.30.123: NTPv4, Client, length 48
16:45:02.295478 IP 129.6.15.30.123 > 209.200.39.7.123: NTPv4, Server, length 48
16:45:04.115161 IP 209.200.39.7.123 > 129.6.15.30.123: NTPv4, Client, length 48
16:45:04.202371 IP 129.6.15.30.123 > 209.200.39.7.123: NTPv4, Server, length 48
16:45:06.115260 IP 209.200.39.7.123 > 129.6.15.30.123: NTPv4, Client, length 48
16:45:06.202423 IP 129.6.15.30.123 > 209.200.39.7.123: NTPv4, Server, length 48
16:45:08.115264 IP 209.200.39.7.123 > 129.6.15.30.123: NTPv4, Client, length 48
16:45:08.201688 IP 129.6.15.30.123 > 209.200.39.7.123: NTPv4, Server, length 48
16:45:10.115066 IP 209.200.39.7.123 > 129.6.15.30.123: NTPv4, Client, length 48
16:45:10.238195 IP 129.6.15.30.123 > 209.200.39.7.123: NTPv4, Server, length 48

So NIST servers should not refuse access , and this one clearly doesn’t.

For a client that is stays in INIT.
Requests are sent at minpoll , which in my case is 16 secs.

16:23:21.428877 IP 209.200.39.7.123 > 128.138.140.44.123: NTPv4, Client, length 48
16:23:37.428912 IP 209.200.39.7.123 > 128.138.140.44.123: NTPv4, Client, length 48
16:23:53.428827 IP 209.200.39.7.123 > 128.138.140.44.123: NTPv4, Client, length 48
16:24:09.428838 IP 209.200.39.7.123 > 128.138.140.44.123: NTPv4, Client, length 48
16:24:25.428832 IP 209.200.39.7.123 > 128.138.140.44.123: NTPv4, Client, length 48
16:24:41.428875 IP 209.200.39.7.123 > 128.138.140.44.123: NTPv4, Client, length 48
16:24:57.428801 IP 209.200.39.7.123 > 128.138.140.44.123: NTPv4, Client, length 48
16:25:13.428818 IP 209.200.39.7.123 > 128.138.140.44.123: NTPv4, Client, length 48

So my issue is not with iburst as I do not get ANY packets in response from this server but ntpdate does get a response????

Post by Charles Swiger

Post by Mike Cook
Can anyone confirm that this is an issue?
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.

iburst isn't usually a problem, but minpoll 4 / maxpoll 6 would be
considered abusive without prior arrangements. minpoll 6 is the fastest
rate you should query other NTP servers without explicit permission.
To be more specific, folks who implement per-client firewall rate rules
tend to block clients who exceed ~100 packets per hour.
The main point of iburst is to quickly get a downed NTP server back up
and serving valid time. That matters most for isolated stratum-2+
servers; if you've already got S1 timesources available and multiple
redundant NTP servers locally, using iburst is superfluous.
Sure, use iburst on one remote server entry if you want and/or against
all of the other NTP peers on your local subnet, but it's not obviously
helpful to use iburst everywhere.
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

[Charles Elliott]

I use minpoll 4 maxpoll 5 on the client that accesses external servers and
minpoll 4 maxpoll 4 on the LAN. The results justify the means: consistent
sub-100 millisecond offsets on the LAN (presently -0.011 on this computer).
The only time I have been knocked off an NIST server was when I switched
from one computer to another as the external gateway. Because of the NAT,
time-d and time-d.nist.gov picked up the fast request rate right away when
both clients were briefly active, and would not let me back on for a day or
so.

Charles Elliott

-----Original Message-----
From: questions [mailto:questions-
Swiger
Sent: Sunday, August 2, 2015 10:34 AM
To: Mike Cook
Cc: Questions List
Subject: Re: [ntp:questions] iburst and NIST servers

Post by Mike Cook
Can anyone confirm that this is an issue?
I habitually put an burst directive in my ntp.conf server statements.
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.
iburst isn't usually a problem, but minpoll 4 / maxpoll 6 would be
considered abusive without prior arrangements. minpoll 6 is the fastest
rate you should query other NTP servers without explicit permission.
To be more specific, folks who implement per-client firewall rate rules
tend to block clients who exceed ~100 packets per hour.
The main point of iburst is to quickly get a downed NTP server back up
and serving valid time. That matters most for isolated stratum-2+
servers; if you've already got S1 timesources available and multiple
redundant NTP servers locally, using iburst is superfluous.
Sure, use iburst on one remote server entry if you want and/or against
all of the other NTP peers on your local subnet, but it's not obviously
helpful to use iburst everywhere.
Regards,
--
-Chuck
_______________________________________________
questions mailing list
http://lists.ntp.org/listinfo/questions

[Greg Dowd]

I have used the locked poll intervals as well, but mostly for LAN. The only comment I have is that the steering stays in PLL mode so you get a noisier loop and the frequency correction resolution is poor in the event you lose connectivity to your servers. But, as you mentioned, you get these nice rails to bounce off of. When using these "fast" poll times with servers farther away, the error introduced by the network adds more noise to a short measurement interval and I have found that sometimes it's better and sometimes worse. I find that the network has periods, lasting many minutes, where the path gets twisted or congested. With the faster poll times, the filter fills with bad data and ntp is forced to consume some of it. With the standard poll times, sometimes we can get through these network weirdness intervals with just 1 or 2 bad samples.

Of course, in the IEEE-1588 world, we typically query at 64Hz and can go up to 128Hz. Now there is some real data to crunch :-)



-----Original Message-----
From: questions [mailto:questions-bounces+greg.dowd=***@lists.ntp.org] On Behalf Of Charles Elliott
Sent: Tuesday, August 04, 2015 4:57 PM
To: 'Charles Swiger'; 'Mike Cook'
Cc: 'Questions List'
Subject: Re: [ntp:questions] iburst and NIST servers

EXTERNAL EMAIL


I use minpoll 4 maxpoll 5 on the client that accesses external servers and minpoll 4 maxpoll 4 on the LAN. The results justify the means: consistent
sub-100 millisecond offsets on the LAN (presently -0.011 on this computer).
The only time I have been knocked off an NIST server was when I switched from one computer to another as the external gateway. Because of the NAT, time-d and time-d.nist.gov picked up the fast request rate right away when both clients were briefly active, and would not let me back on for a day or so.

Charles Elliott

-----Original Message-----
From: questions [mailto:questions-
Swiger
Sent: Sunday, August 2, 2015 10:34 AM
To: Mike Cook
Cc: Questions List
Subject: Re: [ntp:questions] iburst and NIST servers

Post by Mike Cook
Can anyone confirm that this is an issue?
I habitually put an burst directive in my ntp.conf server statements.
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.
iburst isn't usually a problem, but minpoll 4 / maxpoll 6 would be
considered abusive without prior arrangements. minpoll 6 is the
fastest rate you should query other NTP servers without explicit
permission.
To be more specific, folks who implement per-client firewall rate
rules tend to block clients who exceed ~100 packets per hour.
The main point of iburst is to quickly get a downed NTP server back up
and serving valid time. That matters most for isolated stratum-2+
servers; if you've already got S1 timesources available and multiple
redundant NTP servers locally, using iburst is superfluous.
Sure, use iburst on one remote server entry if you want and/or against
all of the other NTP peers on your local subnet, but it's not
obviously helpful to use iburst everywhere.
Regards,
--
-Chuck
_______________________________________________
questions mailing list
http://lists.ntp.org/listinfo/questions

[Mike Cook]

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

In your NIST server anomaly email, you are using an older version of ntpdate; my output from ntpdate is much different from yours.
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-
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?
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
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
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