Steven Sommars wrote:
> I regularly monitor the NIST public NTP servers including the UT1 server.
> ut1-time.colorado.edu <http://ut1-time.colorado.edu> reachability was
> good for the past 10 weeks, though the server was briefly in alarm on
> January 22 and March 10. I can supply details off-list.
>
> NTP traffic is subject to Internet delay and loss that depends on the
> endpoint IP addresses and often on the client UDP port. If the client
> NTP daemon (ntpd, etc.) can't contact a server, try to manually poll
> using ntpdate.
I've also added ut1-time.colorado.edu as "noselect" peer to a local, GPS
controlled ntpd. Even with a 1024 s poll interval my ntpd doesn't
receive a reply for each request, so the "reach" column in the output of
"ntpq -p" is not "377", which is the same for other NIST servers:
~ # ntpq -p
remote refid st t when poll reach delay offset jitter
======================================================================
*SHM(0) .shm0. 0 l 5 8 377 0.000 0.000 0.000
ptbtime1.ptb.de .PTB. 1 u 79 128 377 28.787 1.397 7.650
ptbtime2.ptb.de .PTB. 1 u 129 128 277 30.608 1.212 5.261
ptbtime3.ptb.de .PTB. 1 u 75 128 377 29.536 2.891 2.165
resolver2.skyfi 216.xxx 2 u 5 64 377 172.385 4.483 2.485
hadb2.smatwebde 192.xxx 3 u 46 64 377 137.772 1.627 2.066
time-a-b.nist.g .NIST. 1 u 95 1024 5 162.529 -8.114 1.445
time-b-b.nist.g .NIST. 1 u 1302 1024 42 159.903 -10.609 2.652
utcnist2.colora .NIST. 1 u 37m 1024 334 161.740 -9.495 3.151
ut1-time.colora .Nut1. 1 u 675 1024 143 162.015 130.909 1.048
This is not a basic network problem at my side. The servers "resolver2"
and "hadb2" which are public pool servers located in the US have both
reach "377", so these ones reply reliably.
You can simply test this if you run "ntpdate -d -p1 <hostname>"
repeatedly. When I try this for a NIST server here from Germany I only
receive a reply occasionally, and in most cases I don't. On the other
hand, if I run the same ntpdate command against a pool server located in
the US, this works most of the time, and only very occasionally there is
no reply.
So there seem to be quite strict restrict rules at NIST. The NIST
servers seem to simply not send a reply if they see queries from the
same IP address in short intervals, whatever "short" means. I'm assuming
this is to reduce the high load they probably have to handle.
Please note you need to take care if you have several nodes behind a NAT
router that poll the same server. From the server's point of view it
looks like all the requests from the nodes behind the router seem to
come from the same (public) IP address, so a particular node on the NAT
subnet may receive even less replies.
Martin
--
Martin Burnicki
Senior Software Engineer
MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki at meinberg.de
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/
Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de https://www.meinbergglobal.com
Training: https://www.meinberg.academy