NTP - time.nist.gov Not working

time.nist.gov does not seem to be responding to NTP requests. I have a bunch of esp8266 projects that use this NTP pool, some for years, and many have stopped getting responses.

I just tried one of the esp8266 NTP example programs and that also is not working.

Furthermore mostly these NTP servers don't respond to pings, although rarely I do see a response. I even tried using an online based pinger (Online Ping Utility Tool for IPv4 Address | IP AddressGuide) and pings from that site also fail.

This has been going on for several days, and it appears that the NTP pool "time.nist.gov" is malfunctioning. Hard to believe that is the case given that there must be millions of users (IMHO) and news of such a malfunction would likely be widely available (via Google, etc).

The alternative NTP pool "pool.ntp.org" works fine and is pingable.

Is anyone else having this problem?

Thanks, Frank

I am playing with ESP8266s and used the sample program for getting NTP time, which used time.nist.gov. I found it to be somewhere between unreliable and unuseable. Like you, I tried pool.ntp.org, which works fine.

Thanks for the response, i was beginning to think I was crazy since I thought it was unimaginable that "time.nist.gov" could malfunction seemly unnoticed.

Kinda gives credibility to those who say the government can't do anything right :>)

I'm hoping they get their act together soon so some of my older projects can get accurate time again. If not, maybe I can find a way to override the DNS lookup for "time.nist.gov" like is done in a P.C. "hosts" file. Maybe my home router has some similar capability.

I hate the idea of going back and modifying some of my old projects. I have so many variations and permutations
of my old sketches that I might have trouble identifying which sketch applies to a specific old project. More recently I have mitigated that problem by programming sketches to identify the sketch file name via the console port upon bootup.

If anyone has any further comments/information on this problem I'd love to hear it.

Thanks again.
Frank

Have you tried contacting them?

Excellent suggestion!

I just sent an email to them describing the problem. I'll post back when/if I get a response.

Frank

For what it's worth...

pi@raspberrypi:~ $ ntpdate -q time.nist.gov
server 132.163.97.4, stratum 1, offset -0.019549, delay 0.05302
11 Jul 02:45:00 ntpdate[29601]: adjust time server 132.163.97.4 offset -0.019549 sec
pi@raspberrypi:~ $ ntpdate -q time.nist.gov
server 132.163.97.4, stratum 1, offset -0.020000, delay 0.05318
11 Jul 02:46:05 ntpdate[29618]: adjust time server 132.163.97.4 offset -0.020000 sec
pi@raspberrypi:~ $ ntpdate -q time.nist.gov
server 129.6.15.28, stratum 1, offset -0.068781, delay 0.17342
11 Jul 02:46:17 ntpdate[29619]: adjust time server 129.6.15.28 offset -0.068781 sec
pi@raspberrypi:~ $ ntpdate -q time.nist.gov
server 129.6.15.28, stratum 1, offset -0.067441, delay 0.17392
11 Jul 02:46:28 ntpdate[29628]: adjust time server 129.6.15.28 offset -0.067441 sec
pi@raspberrypi:~ $ ntpdate -q time.nist.gov
server 129.6.15.28, stratum 1, offset -0.068839, delay 0.17601
11 Jul 02:46:35 ntpdate[29629]: adjust time server 129.6.15.28 offset -0.068839 sec

But a little later:

ntpdate -q time.nist.gov
server 132.163.97.4, stratum 0, offset 0.000000, delay 0.00000
11 Jul 07:19:43 ntpdate[18979]: no server suitable for synchronization found

Maybe the service is oversubscribed or some of their servers are down, unnoticed.

Huh. Still working here...

pi@raspberrypi:~ $ ntpdate -q time.nist.gov
server 128.138.141.172, stratum 1, offset -0.028040, delay 0.12584
11 Jul 12:35:23 ntpdate[5442]: adjust time server 128.138.141.172 offset -0.028040 sec
pi@raspberrypi:~ $ ntpdate -q time.nist.gov
server 129.6.15.30, stratum 1, offset -0.041947, delay 0.15367
11 Jul 12:35:38 ntpdate[5443]: adjust time server 129.6.15.30 offset -0.041947 sec
pi@raspberrypi:~ $ ntpdate -q time.nist.gov
server 129.6.15.30, stratum 1, offset -0.052181, delay 0.17299
11 Jul 12:35:46 ntpdate[5444]: adjust time server 129.6.15.30 offset -0.052181 sec
pi@raspberrypi:~ $ ntpdate -q time.nist.gov
server 129.6.15.30, stratum 1, offset -0.041568, delay 0.15404
11 Jul 12:35:54 ntpdate[5445]: adjust time server 129.6.15.30 offset -0.041568 sec
pi@raspberrypi:~ $ ntpdate -q time.nist.gov
server 129.6.15.26, stratum 1, offset -0.042717, delay 0.15593
11 Jul 12:36:12 ntpdate[5446]: adjust time server 129.6.15.26 offset -0.042717 sec

Are there any geographic restrictions on its use? I am in the UK.

Still working from here...

pi@raspberrypi:~ $ ntpdate -q time.nist.gov
server 132.163.96.6, stratum 1, offset -0.008480, delay 0.08261
11 Jul 14:08:47 ntpdate[8064]: adjust time server 132.163.96.6 offset -0.008480 sec
pi@raspberrypi:~ $ ntpdate -q time.nist.gov
server 132.163.97.4, stratum 1, offset 0.000103, delay 0.06807
11 Jul 14:10:06 ntpdate[8082]: adjust time server 132.163.97.4 offset 0.000103 sec

(My Pi's clock is oddly accurate.)

Still working from here...

And where, Mrs. Badly's little boy, is 'here' exactly? :slight_smile:

Huh. The forum used to display "location". I wonder when that disappeared.

Dallas. (Not the one in South Dakota.)

Frontier is my ISP.

Location stopped on the topic pages a while ago.
They can still be seen on the Profile page. As a moderator I can see yours by clicking on your picture/avatar, I don't know if non-mods can see others.

The online pinger still shows 100% packet loss.

No reply to my email yet.

Frank

I believe the NIST time servers are normally not pingable.

Some of the "time.nist.gov" servers do (sometimes) respond to pings and some do not. Similarly, occasionally my NTP programs will get the time successfully, but mostly not.

Below are some pings from my NY home. When I put those two IP's into the online pinger the results are the same (one responds, one does not).

Admittedly the ping test may not conclusively prove that server is also not serving time. However, it is some evidence that is the situation.

Frank

Pinging ntp1.glb.nist.gov [128.138.141.172] with 32 bytes of data:
Reply from 128.138.141.172: bytes=32 time=49ms TTL=51
Reply from 128.138.141.172: bytes=32 time=49ms TTL=51
Reply from 128.138.141.172: bytes=32 time=53ms TTL=51
Reply from 128.138.141.172: bytes=32 time=49ms TTL=51

Ping statistics for 128.138.141.172:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 49ms, Maximum = 53ms, Average = 50ms

Pinging ntp1.glb.nist.gov [129.6.15.26] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 129.6.15.26:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

frank2644:
Some of the "time.nist.gov" servers do (sometimes) respond to pings and some do not.

The NIST requests that "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."

In conversations with the NIST, regarding server status at various times over the past several years, I've learned they shut down whole servers without notice for months at a time.

Perehama,
Yes I know about the 4 second rule, although I'm not sure if collectively my home IP address exceeds that limit. That is, I have maybe 1/2 dozen devices that query time through my home IP address, although I am not sure how often since mostly there is a behind the scenes time library that handles that detail. Hopefully those libraries query sparingly. I suppose that could be my problem, but I doubt it because occasionally I do get the time successfully.

Relative to taking some servers offline, I would hope NIST simultaneously takes them out of the round robin sequencing so that users don't automatically and unknowingly try and use them.

Thanks,
Frank