NETTIME and proper setup

[Bolt]

I've been using a NETTIME instruction for quite a while, and have always gotten allot of timeouts, failed updates.  It does work successfully sometimes, but not consistently.

I've tried different servers.  I get all my IP's from https://tf.nist.gov/tf-cgi/servers.cgi

I've changed timeout from 1000 ms to 2000 ms.

How does "proper" NETTIME logic look?  If failed, try again in 10 seconds?  If failed try different IP address?

Here's my attached logic.  Just trying to generate conversation for proper procedure.

[Mike Nash]

My code does time out at times, but it doesn't seem excessive. I'm only using it to display the time on my desk on a device not remotely associated with being a timepiece or display - it was primarily to get comms working with that family just to see if I could. (And then I got to do it for real.)

You're not hitting the time server too frequently are you?

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.

[BobO]

It is and has always worked perfectly for me. Just set up a quick test, hitting a NIST server in Maryland every 6 seconds. It's close to 100 now with zero failures.

My guess is that you have more general issues with network stability. You might ping one of the servers recurrently and observe any bumps in ping responses.

[ATU]

Do a little data collection.
When you have a a NETTIME  timeout, start pinging the server and then record in an array how long it takes before you get a response.

[Bolt]

Regularly, I only attempt it once an hour.  So I'm not bombarding the server.

I can't even ping any of the NIST servers from the command prompt, so I didn't bother having the PLC ping the servers.  What am I missing there?  Are they port specific, don't reply to regular pings?

[BobO]

The time.nist.gov domain gets round robin mapped to a range of servers. It appears that some of those servers are answering pings, but others are not. For my test I looked up one of the servers and just used that IP. That worked fine.

How are you resolving the address to the server?

[ADC Product Engineer]

One other thing to note, not all of the NIST servers are public anymore.  Be sure you are picking from a current list.  As Bob said, time.nist.gov should typically be the proper access point.

Current list: https://tf.nist.gov/tf-cgi/servers.cgi

[Bolt]

The time.nist.gov domain gets round robin mapped to a range of servers. It appears that some of those servers are answering pings, but others are not. For my test I looked up one of the servers and just used that IP. That worked fine.

How are you resolving the address to the server?

I am picking an IP address from the list that I and the ADC Product Engineer have linked to in this post,  the nist.gov servers.  I have tried several, and they all work occasionally, and occasionally not.  Since starting this post, running NETTIME just once an hour (and occasionally forcing it for troubleshooting) success rate is about 58%.

It's not a big deal, but I'm wondering what I'm doing wrong, or how I should be structuring my ladder logic.  Most of my logic has a success rate of well over 58%, haha.  I'm just trying to cut down on the warning errors every time I open DmD. 

[BobO]

I am picking an IP address from the list that I and the ADC Product Engineer have linked to in this post,  the nist.gov servers.  I have tried several, and they all work occasionally, and occasionally not.  Since starting this post, running NETTIME just once an hour (and occasionally forcing it for troubleshooting) success rate is about 58%.

It's not a big deal, but I'm wondering what I'm doing wrong, or how I should be structuring my ladder logic.  Most of my logic has a success rate of well over 58%, haha.  I'm just trying to cut down on the warning errors every time I open DmD.

That's terrible. I have not seen anything that bad, but I haven't run it over night.

Maybe the servers coming and going is expected, and perhaps the global DNS function is accounting for servers being up or down. Add an additional step that does a DNSLOOKUP on time.nist.gov before calling NETTIME. I just set that up myself. It looks like the returned server is changing every 15 seconds or so.

[Mike Nash]

No errors after 3 1/2+ days checking every 2 hours here.

The NETTIME errors I do get are quite possibly me screwing up the ethernet here in the office network, and our service can get iffy at times.

[Bolt]

Strange.

I have changed my logic to DNSLOOKUP, NETTIME, and if success, repeat in 5 minutes.  if fail, repeat in 10 seconds.  So far I'm at about 75% success (about 160 attempts).  Overall my internet connection doesn't have that many issues, so not sure what gives.  I guess I'll just live with it, it's still quite accurate.

[BobO]

I'm really quite curious. SNTP is a very simple UDP based protocol...packet out and back. There is really nothing to go wrong unless packet delivery is unreliable. It appears that some of the servers don't answer ping, but several do. I would still like to know what ping looks to a server that supports it.

[Bolt]

I have actually yet to ping a NIST server that replies.  From PC, not PLC.

[Evilbeard]

I have actually yet to ping a NIST server that replies.  From PC, not PLC.

Seems to me like you have some sort of firewall/traffic restriction. I know that here at work, I can't ping those servers, but my internet access works allowing me to ping things like google, etc. You might look at what kind of restrictions your network has in regards to network traffic. Corporate IT is my nemesis.

[BobO]

I have actually yet to ping a NIST server that replies.  From PC, not PLC.

This one worked for me: utcnist.colorado.edu