Home AMX User Forum AMX General Discussion

NTS Issue

Okay - this is weird. At my home/office I have 5 Netlinx masters running. They range from an old NI-900, and NI-3000, two NI-X100s and an NX-3200. They all have the most current firmware.

During our recent time change from Daylight Savings not a single one made the change. I found it odd that all my other gadgets that do rely on my IP network changed over just fine. I eventually logged into each master and looked at the NTS settings. The only oddball was the really old NI-900 had a NTS address that is no longer valid. but, I changed it to something that is and still no workie.

Lastly I telneted into each family and pinged each one's NTS and got a response. So, it can at least reach the NTS. As to whether or not it can get to the NTS port is another issue. I can get to the NTS ports via my laptop and Macs just fine. The only devices that seem to be not able to pull the time are my Netlinx masters.

Riddle me that Batman????

Comments

  • ericmedleyericmedley Posts: 4,177
    Okay - now this...
    So I was poking around trying all kinds of different NTSs out there I found a list of NTS that shows both open and ones that require authentication. I tried a NIST one in Maryland that is listed as "Open / No Authentication" and it now works on my NX master. But, it does not work on any of my NI masters.. Perhaps it's something to do with authentication. I thought NTP was UDP. If it does authentication, perhaps its now UDP with reply or TCP now.
  • John NagyJohn Nagy Posts: 1,742
    Huh. 100% of our systems update precisely at 2 AM, and have for years. Messing up only the one year when Bush changed the effective dates. Call me if you want to compare settings.We've never mucked with the NTS pointers. I believe we use STANDALONE setting. Perhaps the scheduler module in the code (ancient, but useful) is doing the deed.
  • ericmedleyericmedley Posts: 4,177
    John Nagy wrote: »
    Huh. 100% of our systems update precisely at 2 AM, and have for years. Messing up only the one year when Bush changed the effective dates. Call me if you want to compare settings.We've never mucked with the NTS pointers. I believe we use STANDALONE setting. Perhaps the scheduler module in the code (ancient, but useful) is doing the deed.

    Thanks John,
    I will indeed give you a call if I end up playing more with it this week. (Mama's gotta shake the money maker for a couple days. Gotta pay the bills...) I suspect it's something in my network as none of my outside masters misbehaved at all. And all these masters I'm referring to (save one which is my personal home system) are test systems. So, If I have a weird router/firewall issue going on, it's not a show-stopper. Right now this is at the level of an odd curiosity.
    Thanks as always.
    E
  • [Deleted User][Deleted User] Harman Integrated Technologies Group (ITG) Posts: 0
    In speaking with support earlier today, this subject came up. Per my understanding, the default time servers found in current firmware are no longer valid - or at a minimum not working. Manual time server assignment is working. A hotfix is due out NLT tomorrow that contains updated defaults. I recall changing this on my home NI3100 system some time back and to achieve success, I entered a different manual time server.
  • ericmedleyericmedley Posts: 4,177
    AMX_Chris wrote: »
    In speaking with support earlier today, this subject came up. Per my understanding, the default time servers found in current firmware are no longer valid - or at a minimum not working. Manual time server assignment is working. A hotfix is due out NLT tomorrow that contains updated defaults. I recall changing this on my home NI3100 system some time back and to achieve success, I entered a different manual time server.

    Thanks Chris,
    At least I know I'm not going crazy. Well, wait a minute...
  • viningvining Posts: 4,368
    Yeah I just logged into a system that said it was January 9th, 2031. Am I going to have to check all my systems and change the time server?
  • John NagyJohn Nagy Posts: 1,742
    I've seen the jump to 2031 a number of times through the years, never pinned down what causes it.
  • ericmedleyericmedley Posts: 4,177
    vining wrote: »
    Yeah I just logged into a system that said it was January 9th, 2031. Am I going to have to check all my systems and change the time server?

    Was it drawing 1.2 Gigawatts?

  • I just checked all my controllers today. Only 10% were accurate, most of them were an hour off, and another 10% were in 2031. I know I went through and manually set them all during the last time change. I may need to change the NTP to point to one of our on-campus time servers.
  • I discovered the time server problem a few days ago when I noticed in Diagnostics my masters were all reporting ClkMgr errors. I put together a quick test and discovered that the time server configuration was the issue and that by using User Defined time servers (that were valid), the ClkMgr was happy. In examining the current time server configuration (at least on NX firmware), AMX has hard coded three (3) NIST time server URL/IP address combinations. NIST deprecated a number of time servers on 10/31 of this year and these time servers are no longer active along with a number of other time servers.

    I hope that the solution is not to simply hard code a new set of time servers since that too is likely to lead to the same problem down the road if those servers are deprecated by NIST. Instead, NIST now recommends the use of a single time server URL (time.nist.gov) and not a specific IP address. If you do a DNS lookup on the URL, it will provide the IP address of a time server that is in the current time server pool and is active/serving requests (it might be a different time server each request). Using this technique, the actual time servers and their IP addresses can change but programming would never need to change unless of course the NIST time server URL is ever changed. In solving the time server problem with user defined time servers, my preference would have been to implement this approach but not having a way to do a DNS lookup dynamically prevents it. The interface to specify a user defined time server calls for a URL and IP address but it is not clear if you specify a URL and not an IP address that Netlinx will then perform the DNS lookup to resolve the URL.

    Unfortunately, to correct the issue with masters in the field, either a firmware update or programming changes are going to be necessary. If the current approach of hard coding the time servers is maintained, adding support to Studio for updating the time server config or minimally adding commands to the CLI/telnet interfaces to update the time server configuration would really be helpful.
  • banobano Posts: 173
    Glad I live in Arizona.
  • a_riot42a_riot42 Posts: 1,624
    Just noticed this on the NIST site:

    https://www.nist.gov/pml/time-and-frequency-division/services/internet-time-service-its


    Urgent Notice for Users of the NIST Internet Time Service (ITS)
    Be advised that NIST is upgrading the servers and networks that support the ITS. That will result in new addresses for some servers, and the discontinuation of other servers. If you have a hard-coded connection to an ITS server, that address may no longer function. Please check the latest list of ITS servers and addresses as soon as possible. The upgrade process will continue through mid-November. For questions or problems, send email to jlevine@nist.gov (link sends e-mail).
Sign In or Register to comment.