Clock Manager not working?

Kmclane

I am trying to enable the "Clock Manager" function on an NI-3100 through the web page and apparently I am doing something wrong.

I set the clock to the wrong time, and it never corrects itself.

I have selected Network Time from the Mode Settings Screen, A 5 minute Re-sync period, and Eastern Time zone.

I have selected Daylight Savings time "ON". I assume this means that DST is observed and not that it we are currently "IN" DST.

I have tried using the default NIST time servers as well as adding a couple of custom ones.

I tried changing the firmware by upgrading to v. 4.1.373 from v. 3.60.453 and device firmware 1.30.8

I have tried this on two different controllers with the same problem. anyone else having problems? or any ideas about what I might be doing wrong? Should the time server update as soon as the changes are applied? 5 minutes from then? or every 5 minutes on the clock (I.e. 1:00, 1:05, 1:10...etc.)?

Help!!!!

trav

It's a firmware bug

I discovered this (apparently) unreported bug earlier this year on a site with 50(ish) panels syncing both with RMS, and with the clients internal ntp server, neither appeared to be working.

In the telnet interface of the panel, and in the setup pages, the time showed that it was set correctly, but the display time address codes always displayed the wrong time, and would drift from the moment it was set.

I think it was a rendering bug in the panel firmware, but defiantly contact tech support as I was told that it has been subsequently fixed.

I worked around it by using a timeline to manually update the time fields on all the panels every 30 seconds.

edit: To confirm, I'd telnet into the panels and check the time in there. It should be correct.

Kmclane

This appears to be at the controller level. It shows incorrectly even if I use the set time function from within Netlinx Studio to "get" the time. Not sure how a "Display" bug could cause that.

trav

Mine were showing the panel time correctly in the telnet interface of the TP, but displaying the wrong time on the user pages when using the appropriate address codes.



That screen shot shows the issue in the panel setup pages, the correct time showing in one set of codes, and not in the other. It displayed the wrong time on the panels, but was actually holding the correct time internally, hence (what I was told) a rendering issue within the panel itself.

May or may not be your issue, but I thought I'd mention it, as it is one feature that in over 10 years I hadn't had a problem with, until August this year.

But in all things AMX, your results may vary!

good luck

Kmclane

Thanks. I think I have a different issue. The clock on the TP is updated to match the controller's as soon as I change it manually inside the controller or from the TP. I am just not getting the clock to check with an Internet time server and update itself.

Joe Hebert

Kmclane wrote: »

I am just not getting the clock to check with an Internet time server and update itself.

Are the gateway and DNS settings of the NI-3100 correct?

trav

As an addition to Joe's response, can you ping 4.2.2.4 from the NI controller telnet interface?

That will at least directly prove internet connectivity from the NI.

Kmclane

No Joe. They were not set correctly, and that fixed the problem - Thank you!

Kmclane

I may have spoken a bit too soon.

The time server is correcting the clock time each time after the master is rebooted now, but not at the 5 minute interval selected. I am pointing to a NIST server that claims to be very available, unlike the default servers.

pdabrowski

Another thing, it may not be site-wide, but I did find a NI3100 installed here back in 2009 that did not have it's Timekeeper battery installed from the factory - it's a yellow "block" that is fitted to the top of the timekeper chip in the NI controller adjacent to the CF card on the NI3100's.

The tech notes mention it here: http://www.amx.com/techsupport/techNote.asp?id=856

The symptons I was experiencing that the system would be unable to keep sync'd - we never saw the issue as the panels on that controller didn't have a time & date visible to users.

The only thing that exposed the issue after 4 years was that after setting up RMS enterprise we would see the Netlinx system 0:0:0 to appear as offline in RMS for 20 minutes every hour.

Kmclane

Thanks, I am not losing time though. I was just trying to ensure that the clock manager was working so I purposefully set the clock wrong.

RichardHamilton

Kmclane wrote: »

I may have spoken a bit too soon.

The time server is correcting the clock time each time after the master is rebooted now, but not at the 5 minute interval selected. I am pointing to a NIST server that claims to be very available, unlike the default servers.

I'm not sure you should be polling a NIST every 5 mins, there's very little need for that.

Once every 24 hours should be more then enough. Even once a week. The controller's clock wont drift that greatly, and I'm going to guess it's not required for an ultra-time critical installation.

So, try backing off for what it's worth, the NIST may not even be replying if you are polling too much (not sure, but a server admin setting might do such a thing).

Kmclane

Perhaps polling every 5 minutes is excessive, but I am simply trying to confirm that the polling ever actually takes place. It is the shortest time interval selectable, so that I can be sure that the function works at all, and aside from updating at reboot, it does not appear to be doing so.

ericmedley

This may be a bit obscure but I have see this issue cause problems a couple other times. (Not necessarily AMX)

Part of the protocol/conversation going on in the time server has to do with the health of the server. There is a health rating byte the server sends that tells the client how healthy it thinks it is from a performance standpoint as well as how busy it thinks it is and also how busy it thinks it's network is. The idea behind it is it gives the client the choice whether to pay attention to the time data coming back.

Time check conversations typically involve up to 7 pings in which the client and server time the round trip of consecutive messages. Once the client thinks it has a good idea of the latency it will adjust time time it sets its clock to accordingly.

There are many flavors of time client and some are pickier than others. Also, a few have known bugs concerning the "health" report. The manifestation of the big is the time client says, "I can reach the time server but I don't trust it. So, I'm not going to reset my clock until after the next check." Wash-rinse-repeat...

You might try setting your time check interval back longer. I do mine on the hour.

Kmclane

It has always been my intent to decrease the frequency to a more reasonable interval. My application is by no means time critical. I just want to confirm that the clock gets updated properly before I do that. I have tried pointing to a NIST server that claims to be less busy than the default options. I would think that with a 5 minute interval that the time would be updated at least every 20 - 30 minutes even if the server was too busy a couple of times. So far it does not seem to update regardless of the degree of offset I introduce with the incorrect time. However, it does update every time I reboot, that seems to undermine the theory that the NIST server is too busy for the periodic checks, unless the program is more forgiving after a reboot.
Maybe AMX thinks that 5 minutes is too excessive and ignores that frequency selection, like the push to walk buttons at traffic lights. I will try a greater duration and see if I have any better success.

Joe Hebert

Kmclane wrote: »

Maybe AMX thinks that 5 minutes is too excessive and ignores that frequency selection...

I don’t think that’s the case. I’ve set mine to 5 minutes before (just as a test - no sense in waiting for an hour) and it works fine from here. Here are the settings I just tried. I set the time incorrectly and it was back in sync within 5 minutes. For what it’s worth, the attached shows the settings that worked successfully for me.

Kmclane

Out of curiosity, using clock manager, I set the time zone to Central time to match Joe's settings, and update frequency to 15 minutes. I went to Lunch for an hour and when I came back the clock was synchronized properly, (though actually 1 hour off). I then set the time zone back to Eastern and the clock immediately jumped back 13 minutes. So now it is 1 hour and 13 minutes slow.
I left the frequency set to 15 minutes, so I will see if it eventually corrects itself. What would cause the 13 minute shift? Suspecting that 1:00, the 13th hour may have some correlation. (The clock went from 1:27 to 1:14) Could be mistaken about the stated times but the offset is correct.

Clock updated again somewhere around 3:18 to the correct time.

Kmclane

I repeated the experiment again. With the clock properly set to 3:30 EST, I changed the time zone to Central time with a 15 minute sync interval, at some time within the next hour the clock set itself 1 hour back as expected. This time when I reset the clock to EST (from 3:40:00 CST) it jumped back :37 seconds to (3:39:23). Weird.

At any rate I have determined that eventually the Clock manager updates the time using the NIST time server.

pdabrowski

Our AV network here does not have external access, so I've got a windows box doing the time server job on the same subnet as the AV gear.

The Netlinx masters don't have an issue with this setup, neither do I see any problem on AXIS IP cameras. I do however have trouble with AVITECH multiviewers but I feel it's down to their NTP client implementation.

The way I see things, using a machine on the local subnet for the AMX devices to sync to is a nice way of eliminating any network lag that you may be experiencing which might explain the different values you are getting, plus it's a good way to work around any firewalls or proxy servers as you only need to get the windows box talking outside, not every AMX master.

The setup I followed is on the following page: http://support.microsoft.com/kb/816042

I've got it running on both W2K3 and W2K8 servers, and it may work with a normal Windows desktop OS but I personally haven't tried.

To help decipher the MS KB article, the reg entries I have used are (many may already be set this way on a standard windows install):

HKLM\CurrentControlSet\Services\W32Time\Parameters
Key Name: Type
REG_SZ
Value: NTP

HKLM\CurrentControlSet\Services\W32Time\Config
Key Name: AnnounceFlags
REG_DWORD
Value: a
(the instructions from Microsoft originally specify a value of 5, but further recommend 
that the value be changed to A in certain cases, I have not tried 5 but have not had an 
issue with this setup so I've always used A for this key).

HKLM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer
Key Name: Enabled
REG_DWORD
Value: 1

HKLM\CurrentControlSet\Services\W32Time\Parameters
Key Name: NtpServer
REG_SZ
Value: 10.1.18.5,0x1
(in the value entry here I have synced to another internal server that has access to the 
internet, you may already see the existing entries from the Change Date/Time dialog 
on the desktop but I don't use the original entries. If your PC or server has access outside, 
you can enter the external IP or hostname here. Remember to add the ,0x1 at the end 
of each address here).

HKLM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient
Key Name: SpecialPollInterval
REG_DWORD
Value: 900
(number of seconds to poll the upstream NTP server every 15 minutes)

HKLM\CurrentControlSet\Services\W32Time\Config
Key Name: MaxPosPhaseCorrection
REG_DWORD
Value: d2f0

HKLM\CurrentControlSet\Services\W32Time\Config
Key Name: MaxNegPhaseCorrection
REG_DWORD
Value: d2f0
(these 2 entries as I understand are the amount of seconds difference between the 
upstream server and local server clock that the local server will allow a change - our 
IT guys recommend this value for our network, you may want to expirement as 
Microsoft recommend 1 hour for this value, it does not effect the downstream 
clients ie. the Netlinx Masters)

Then Stop & Restart the w32time service

Open a command window (as Administrator) and type:

net stop w32time && net start w32time

(Or use the Services control panel).