Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Bolt on October 25, 2018, 04:19:08 PM
-
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.
-
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.
-
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.
-
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.
-
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?
-
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?
-
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
-
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.
-
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.
-
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.
-
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.
-
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.
-
I have actually yet to ping a NIST server that replies. From PC, not PLC.
-
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.
-
I have actually yet to ping a NIST server that replies. From PC, not PLC.
This one worked for me: utcnist.colorado.edu
-
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.
I don't think that's the issue, either. I am my own IT guy, and have very few restrictions on traffic.
This one worked for me: utcnist.colorado.edu
I can also ping that one from command prompt in Windows. With slightly better performance than a ping to google.com.
-
This one worked for me: utcnist.colorado.edu
I can also ping that one from command prompt in Windows. With slightly better performance than a ping to google.com.
If you hardcode NETTIME to that server, and then attempt to ping from the PLC when it fails, what happens?
-
This one worked for me: utcnist.colorado.edu
I can also ping that one from command prompt in Windows. With slightly better performance than a ping to google.com.
If you hardcode NETTIME to that server, and then attempt to ping from the PLC when it fails, what happens?
I get about a 70% success rate getting a time from that server too. When it fails, a ping also fails 100% of the time. A ping does work from DmD when manually triggered however.
-
I get about a 70% success rate getting a time from that server too. When it fails, a ping also fails 100% of the time. A ping does work from DmD when manually triggered however.
Everything you are describing points to some kind of general network instability.
Host's primary internet connection is fiber, but we have a backup copper line that works great...and then doesn't. Never could figure out exactly why it would go wobbly. From our desks it still appeared to work, but the packet losses would shoot way up for a bit and then it would be fine.
-
I spoke too soon. I changed my logic up via remote desktop, and didn't enable the alternate bit to force everything over to the colorado IP address. It has run 100% over the last 50+ attempts. So it was also pinging the non-pingable IP address in the mean time. Doh!
-
After two systems with a hard coded IP, changing the addresses a few times, and having inconsistent results, I went with Bob's suggestion of using DNSLOOKUP on time.nist.gov and feeding it into NETTIME, (Which couldn't be simpler by the way, thanks guys.) Haven't had a failure since.
-
Strange. I can go 100% on 260+ attempts with utcnist.colorado.edu, then go back to time.nist.gov, get 1 failure right away, it won't ping, and go back to utcnist.colorado.edu, and it succeeds again.
-
Maybe the DNS server in use by your provider has a messed-up entry for time.nist.gov. Can you ping it from the desktop while getting interwebs from the same network? And, if you resolve the IP address elsewhere, can you ping it from that network with the explicit IP?
-
Another option is pool.ntp.org. These servers don't get as much traffic as the NIST servers, have a higher service capacity, and automatically route your request to your nearest server.