NTP server

[Pedro Augusto]

Good afternoon everyone!

I'm new to the forum and I'm having a problem with the IMS1000 servers.

For some reason the IMS1000 servers were delayed by an hour, as in some theaters we don't have NTP servers I would like to know if it is possible to leave a PC as an NTP server and adjust the time.

[Leo Enticknap]

It is certainly possible to set up a Windows PC to work as a NTP server - instructions attached.

However, if it isn't reporting itself as stratum 1 or higher, and if the number of hops from the IMS1000 through it to the stratum 0 source is too high, and/or the time lag too great, the IMS1000 will not recognize it as a valid server, and will not adjust the media block's secure clock on the basis of what it reports.

If your IMS1000 has drifted by over an hour, it is "out of budget" in DCI jargon. Per DCI rules, a secure clock can be adjusted by up to 300 seconds (six minutes) in any one year. If it drifts by more than that, manufacturer intervention is required to correct it. If you email Dolby with your IMS1000's serial number, they should be able to give you a patch to upload. After doing so, it will correct the secure clock on the following reboot, if it has a valid NTP server to sync to during the boot process.

[Mark Gulbrandsen]

If your clock is over 300 seconds it can still be made correct, but GDC has to remote in to do it. If you do not have a local GDC office they may be able to send you a script to make it correct. Then you want to be sure the NTP is up and running correctly so it's not allowed to drift. I do not recommend a laptop, even a cheap PC would be better.

[Elia Orselli]

Leo, Dolby offers a DLM that allows 30 minutes of correction. More than 30 minutes will require a board reserialization:

This technical article is to highlight the importance of using (NTP) Network Time Protocol, which is for synchronizing the systems clocks, and means your Digital Cinema Server will automatically adjust/correct its time/clock. It is important to know that the DCI (Digital Cinema Initiative) have set a maximum limitation of 6 minutes drift per year (a DLM which allows extension to 30 minutes are possible on request) that a Digital Cinema Server can drift. This also states that any Digital Cinema Server that goes outside this 6/30 minute window, will have to be return to the factory to be corrected. This can only cause an inconvenience to the exhibitor. It is the owners and/or maintenance companies responsibility to ensure the time does not drift.

Mark, as Pedro has an IMS1000, GDC policy does not apply.

[Mark Gulbrandsen]

You're right Elia... I guess I'm stuck at SR-1000.

[Dave Macaulay]

I have several older Doremi servers that have reached a hard limit on time adjust, a DLM can't help. This can not be corrected as Dolphin media blocks are not supported now. These systems were all using NTP. I don't know what the max correction is, but expect to see more units hit it. They stay synced for years and then the drift is uncorrectable.

[Frank Cox]

If something is synced to a ntp server then how could it possibly drift?

I must not be understanding something.....

[Leo Enticknap]

If that server isn't giving it a NTP sync that complies with the DCI rules 'n regs. This has to be stratum 1 or 0, meaning that the DCP server connected to the media block with the secure clock has to be 2 or higher. Typically, the TMS computer will be configured to sync to a stratum 0 external source (e.g. time.nist.gov, or one of its specified nodes if the TMS doesn't support DNS - for example, 128.138.140.44, in Colorado, is the geographically nearest to most of the sites I service, and thus the one I use under these circumstances), and therefore be stratum 1; and the individual screen servers in a 'plex will sync to the TMS, and thus be stratum 2.

I've found that two scenarios can cause problems. Firstly, if the site is an single screen arthouse or screening room with no TMS, then either the screen server needs a direct gateway to the Internet, or to sync via a device that does, in order to get an NTP sync and thus maintain the media block's secure clock. I've been to literally dozens of sites at which this simply wasn't addressed at the install, the server has been running for years with no NTP source, and as a result, the media block's clock has drifted way out of budget. Usually, this is only discovered either by me at a service call, or if the site is issued a ridiculously tight KDM that won't open when they try to play the movie. I set up our remote access PCs to act as the NTP server in some of these setups, using the procedure described in the cheat sheet linked above.

Secondly, if a firewall or general network slowness delays the sync time, it is not fast enough for the NTP source in the booth to qualify as stratum 1, and therefore screen servers connecting to it will reject it. DCP server manufacturers could make our lives easier in identifying this problem. by flagging it up more explicitly. AFAIK, none do. For example, the IMS2000 and 3000 will let you configure and test an invalid NTP server, and even say "Time offset is X seconds" when you press the test button. But after a reboot, you will still get the "No valid NTP source" error banner. DSS servers will simply give you a "could not sync" error message, with no detail as to why. Barco Alchemies won't give you any error message at all - they'll just let the clock continue to drift. However, when you push the test button after entering a NTP server address, the Alchemy will report the stratum number of the source. If it's 3 or higher, it's no good, but the software won't actually tell you that.

Finally, I have a weird situation with a 'plex full of DSS220s, which will sync to the (GDC) TMS upon bootup, but not thereafter. So all is good after the boot, but about a day later the yellow warning icon appears, and it complains of no valid NTP server; and the time in the top left starts to drift. Reboot the thing, and it's good again. I've wasted hours trying to figure it out, without success. Eventually, I just configured the TMS to reboot every screen server at 4am each morning, and that has maintained their times OK.

[Steve Guttag]

If something is synced to a ntp server then how could it possibly drift?

I must not be understanding something.....

The secure clock (mediablock) does not change based on NTP...it offsets). So, when you reach the offset limit, that is when you get into a problem. What is "supposed" to happen is on 1/1 of each year, the secure clock is supposed to re-center itself to allow another +/- 6 minutes. So, it is important to be accurate at the end of the year.

There are normally multiple clocks in a DCinema system (and Dolby has something like 3 on the DSS servers). The show clock is not secure and can be changed by time zone and BIOS...however the KDMs reference the secure clock (mediablock). So, while you can make your clock on the display say whatever you want and scheduled shows will trigger off that clock...the keys still reference the secure clock. So, if a CAT745 is not in the correct time, it isn't too big a deal if you are not a screening room that has incredibly short windows for the KDM.

Leo, presuming your GDC TMS is running on some windows OS/Server...here is a command I picked up somewhere where I had the problem that, like you NTP would stop working. It fixed it on all systems.

From an Administrator Command prompt, execute the following:

sc triggerinfo w32time start/networkon stop/networkoff

This is on top of whatever you use to set up your NTP and your server as an NTP device. FWIW, I use the "us.pool.ntp.org" as I found NIST to be flaky (and I tried several of them). Those sites where we have a NOC, we use the NOC as the NTP source.

[Peter Foyster]

A couple of years ago, with Leo's help, I set up an NTP server on a laptop, networked to my DSS/DSP100. It was not successful as I was using Windows 7, however more recently I purchased a Win 10 laptop and followed Leo's instructions to the letter, which resulted in the Show clock reverting to the exact time when rebooted. As alluded to above, however, it only takes a few days for the time to be out by several seconds and two or three minutes after few weeks, requiring a reboot.
What is interesting is that the DSP100 has never had a connection to the internet in the seven years that I have been using it at my cinema and who knows how long before that. The secure time, however, has been exactly 10 seconds shy of correct time for all of those years. I know that Steve did mention, in a response to one of my earlier postings, that the secure clock in the DSPs was very accurate, but I can't believe just how accurate.
I wonder, if I leave the laptop connected on New Years Eve, will that 10 seconds will become 0 seconds on the 1st January?

[Leo Enticknap]

Some media block secure clocks drift more than others. I haven't had the opportunity to observe many DSP100 ones, but the Dolby cat862s seem to me to be the most accurate of all of them if left to their own devices: they drift for a few seconds a year, if that. In contrast, Dolby cat745s are the worst of the lot, racing forward by around an hour a year if they aren't kept in check by NTP syncs. DolRemI and GDC secure clocks tend to drift by around 3-4 minutes a year.

Steve - thanks for that - will give it a try on the TMS in question.

[Steve Guttag]

Peter, did you create a rule in your Windows Firewall for UDP port 123? Without that, all devices will be blocked from getting NTP from a windows device. I have set up an NTP server in countless Windows 7 devices.

If you take the following and copy/paste it into a text file. Change the extension to .reg (windows registry file), it will create what is needed on most any Windows machine. If you have a preferred NTP server to reference, then change the "us.pool.ntp.org" to your NTP source, including an IP address. You still need to create the firewall rule and I always used the sc triggerinfo command listed previously.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\W32Time\Config]
"MaxNegPhaseCorrection"=dword:00000e10
"MaxPosPhaseCorrection"=dword:00000e10
"AnnounceFlags"=dword:00000005

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\W32Time\Parameters]
"NtpServer"="us.pool.ntp.org,0x1"
"Type"="NTP"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\W32Time\TimeProviders\NtpClient]
"SpecialPollInterval"=dword:00000384

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\W32Time\TimeProviders\NtpServer]
"Enabled"=dword:00000001

[Jon Dent]

Question on this: I sucessfully set up an NTP server a few weeks ago and our IMS3000 units sync up every morning at 6:00. I notice that the "Last Synchronization Offset" always says 1 second on one of our servers, and 3 seconds on the other. Does that mean the one server is drifting by 3 seconds every day? The "Secured Clock" line on that one says 287s/360s (it's -34s/360s on the other) but I've never thought to keep an eye on it so I don't know if it's changing. But following the topics above does this mean I have 24 days until it runs out of adjustment?

[Leo Enticknap]

My guess would be that it's not actually correcting the secure clock because your server is reporting too high a stratum number, and/or too many hops. This annoys me about the DolRemi web UI: it will report whether it's received a time from the NTP server, but not whether the time sync it's received is valid for correcting the secure clock or not.

[Jon Dent]

Lovely. Well I'll see if it changes tomorrow.

There's no way to find out if it's actually adjusting the secure clock, or even seeing what the secure clock is set to? I know the NTP server is updating the clock that's displayed on the "Date and Time" tab at the very least

BTW, I did do a manual clock update before I set up the NTP server, so I don't know how much of that secure clock offset is the result of that.