NTP server

[Carsten Kurz]

You can always set the clock back or forth up to 6 minutes manually, then reinstate the NTP sync, and see if/when it follows the NTP. At least as long as the secure clock deviation is within the +/- 6min DCI correction window.

[Jon Dent]

I followed Leo's NTP setup document. Previously there was some NetTime program running in addition to Window's own NTP source (which was synced to time.microsoft), so I have no idea what the servers were getting for a sync. I deleted the NetTime program and switched over the Windows source to time.nist.gov. The IMS recognized the NTP server, but I suppose I won't know if it's working properly for a few days.

It didn't seem to be before. I rebooted the slower IMS with the old setup and sure enough the "Secure Clock" number jumped from 287 to 290. If the NTP server is properly working as a stratum 1, is that number supposed to change?

[Jon Dent]

So either it didn't work or I'm misinterpreting the data.

The Current Time line on the server is always dead on, but after this morning's sync the Secured Clock line shifted by a further 3 seconds to 293s/360s. Is that meaning the secured clock is not adjusting?

If so then we will definitely run out of budget before the end of the year. Is a 3 seconds a day drift normal on a one year old IMS3000?

[Steve Guttag]

You should open a case with Dolby. I've had to get quite a few DRMs to extend the adjustment range on the IMS3000. It is my belief that the NTP is never adjusting the secure clock (regardless of stratum). It is just adjusting the offset. The secure clock updates its actual time on 1-1 to recenter itself. So, if you are accurate on 12-31...you should be back to +/- 360 on 1-1. And, if you think about, 6 minutes of adjustment is 6 minutes of adjustment, regardless of offset or actual clock. So, even if it is really adjusting the clock, it STILL has to keep tally of how much time it has shifted over the course of the year. What should be allowed (but I don't think is) is for secure clocks to realize that they are gaining/losing by a certain amount over the course of time to adjust themselves (make themselves more accurate) and self-correct, without penalty.

I know that the big fear is that one will shift their secure clock enough to circumvent a KDM so, perhaps it should be something where the manufacturer could "calibrate" the clock before sending it out...either that or use very accurate clocks (preferred so NTP wouldn't be such a needed thing).

[Jon Dent]

Thanks Steve, I've already done that (with Dolby)

Having the clock shift by three seconds a day doesn't imply a very accurate one, at least to me.

[Steve Guttag]

No, it isn't nearly accurate enough. In fact, it is 3X beyond the maximum.

[Mark Gulbrandsen]

Cinema servers should really include a TCXO type stabilized clock. It's very easy to integrate one into a design like a server these days since it's a very small IC now.... They are about the size of a typical bios chip today...

https://www.maximintegrated.com/en/p...ks/DS3231.html

[Marcel Birgelen]

Otherwise, Dolby & co. could implement a secured web service, which could send signed and therefore trusted time updates to the servers directly. You would only need to open up your firewall to the IP adresses this service is running on. Even for sites with intermittent Internet access it should be, at least, feasible to do such a sync every few months.

The problem with this approach is that the DCI specs would probably need some revisions to allow for such an implementation.

[Carsten Kurz]

It is trivial nowadays to build a precise off-the-shelf clock circuit into an expensive media block. It's just that some manufacturers have been sloppy selecting one. Maybe they simply assumed that everyone will use NTP at some time. In most cases, secure clock drift is not really a problem for the operator. Most cinema operators probably would never know about their secure clocks drifting by multiple hours if not the show clock would typically be synced from secure clock, which causes large errors in show schedules. Best would have been to allow for easy manual correction (or NTP) for show clock/system clock, and simply ignore secure clock drift until a tech visits, performs software updates, whatever. That said, our Sony secure clock has drifted just a few minutes in nearly 10 years now. A colleagues' Sony has never been corrected, and now shows a secure clock offset of 1min29s after about 5 years.

[Harold Hallikainen]

The Maxim chip mentioned above looks good. By integrating the crystal in the package, they know what crystal is being used and can temperature compensate it. In the original USL media block, the Maxim security chip that held the private key and watched the tamper switches also had an RTC. The crystal was outside the chip package, so it was probably not a perfect match to the chip. I don't remember if there was temperature compensation on that chip. The big problem was that the oscillator frequency was different when the chip was powered by battery versus when it was powered by the system power. One proposal was to have the system monitor what percentage of time main power was on and provide a correction factor. But that was never implemented. I think later units used a separate RTC chip. One thing I dislike about these RTC chips is that they have a clock and calendar in them. It would be a lot easier to deal with if they just had a 64 bit counter that incremented once a second. You would then just load a UTC Unix time stamp in the counter and let software convert it to date and time of day. It's a lot easier to apply a so many second offset to a 64 bit integer than to HH:MM:SS, YYYY,MM,DD scattered among a bunch of registers in the chip.

In my last projects (IRC-28C update and LSS-200), I used a timer on the microcontroller to generate a 1 Hz interrupt that increments a 64 bit counter. There is an NTP query every 10 minutes or so. The time is corrected and the timer period register adjusted in the right direction to move the 1 Hz interrupt closer and closer to 1 Hz. This, of course, is not a battery operated secure clock of high accuracy, but it's simple!

Harold

[Marcel Birgelen]

If you want to guarantee a high-grade of off-line compliance, what about using an embedded atomic clock? The answer surely must have something to do with money.

[Harold Hallikainen]

Cost is certainly a consideration. There's also battery life. The clock and security circuit in our IMB took 13 uA from the 3V battery, or 39 uW. The atomic clock takes 120 mW (avout 3,000 times the power). We'd need a BIG battery...

[Marcel Birgelen]

The kind of battery you'll find in every smart phone on the planet?
I guess costs is the real limiting factor here, even at volume you're probably looking at a unit cost of close to $1,500, compared to a few cents for a quartz occilator.

Still, I think, giving people the opportunity to sync their secure clock to a trusted clock on the Internet is an achievable and cheap solution for clocks that have drifted beyond the adjustment window...

[Frank Cox]

The best batteries that I know of are whatever they use in pacemakers.

Those things seem to last a decade or more. When the whole pacemaker is just the size of a large coin, that's a tiny, powerful and long-lasting battery.

[Mark Gulbrandsen]

A TCXO chip can be accurate to a few seconds a year. No need for a GPS based chip. The TCXO chip would run off a couple of 3 volt lithium batteries as are used in the SX-3000.