Resolving IP Camera / VMS Time Sync ProblemsBy Ethan Ace, Published Nov 07, 2011, 12:00am EST
One issue which IP surveillance systems must address is syncing of time between cameras and the VMS in a surveillance network. In our experience, and as discussed in a recent lively discussion in our LinkedIn group [link no longer available], this is often overlooked, yet it is an extremely important issue. Cameras and recorders being out of sync could very well result in evidentiary video being thrown out in court. More commonly and mundane, out of synch cameras can result in 'lost' video and headaches for both users and integrators.
In this update, we look at the key issues including Network Time Protocol servers, GPS time appliances, and how IP cameras and VMS servers handle timing.
How Cameras Handle Time
Different manufacturers of IP cameras manage the camera's internal clock in different ways. Fundamentally, there are two options: manual and automatic via network time protocol.
Manual: This option requires the user to enter the current time in the camera's web interface. It allows for precise entry, but must be maintained manually. In some cases, the manual entry may be accomplished via a "sync to PC" button, which sets the time on the camera to the time of the workstation the user is accessing it from.
Maintaining a handful of cameras' internal time is easy to manage, though also easily forgotten, so manual entry is never recommended. In mid- to large-sized systems, manual entry is out of the question. Systems on a larger scale require too much time to manually update. There is also a higher risk that a camera will be missed or incorrectly set.
Automatic: Most current cameras may be synchronized to a network time protocol (NTP) source, whether it be a public source such as time.gov, or a private source, such as GPS master clock or dedicated time server. Synchronizing cameras automatically has multiple benefits. For one, no work is required to update the cameras in the future. Once the time source is set up, the process is automatic.
Most importantly, it ensures the cameras all have the same time. It should be noted that in many cases, this time does not have to be exact. It is much better to have all cameras say it is 2:10PM when it is in fact 2:14 than it is to have one say 2:05, another say 1:59, and another say 2:43. If one camera shows a theft occuring at 1PM, but the subject enters the building on another camera showing 4PM, there's a possibility this video may be inadmissable in court.
How Recorders Handle Timestamps
Just as cameras handle time differently, recorders may handle timestamps differently as well. The two most common ways a VMS may handle time are by stamping frames upon arrival, or using the camera's timestamp.
Stamping on arrival is exactly what it sounds like. The VMS system marks the time it receives each frame of video. This avoids issues with cameras being out of sync, since the server is using its own stamp on each camera. However, in very large systems, or systems with high latency, it may take longer for frames from one camera to arrive than frames from another camera, which will cause video to be out of sync. In most cases, this shouldn't be a large span of time. We would guess less than a second, unless the network is extremely high latency. However, users should at least be aware that this may occur.
Other systems use the timestamp added to video by the camera. If all cameras are synchronized, this is not an issue, and may be more accurate than stamping video upon arrival, due to the latency issues described above. However, if cameras are not synched, it can cause massive issues. If a camera's clock is off by two hours, video on the VMS system will be marked as two hours off. Attempting to use synchronized playback will especially get difficult, as recorded video will simply not be where the user expects it.
In order to synchronize cameras, they need an NTP source from which to pull the current time. Internet servers, such as time.gov and ntp.org may be used, but this requires that the cameras be on a network with access to the internet, with ports opened for this communication. Many users regard this as an unacceptable security hole in their network, and choose to run sources internal to their network instead. There are at least two means by which this can be accomplished. The first method is via software.
It should be noted that Windows is capable of running as a time server. However, there are some issues with doing so. First, in order to set any given server as an Authoritative Time Server, users must edit the Windows registry. Many users will not be comfortable with this process. Second, by default, Windows updates time from a master server once per week. In order to change this, users must once again edit the registry.
To simplify this process, third party NTP clients have been created. One popular client is NetTime. Using programs such as these, users may more easily set different parameters, such as a server list or update interval. Any given PC may be easily set to act as a master server, also.
In situations where it's undesirable to run a master time server on an existing server, dedicated hardware options exist.
GPS-based: For systems which need to have accurate time, but do not want to open ports to the internet to retrieve it from an NTP source, GPS master clocks may be the only option. These clocks retrieve time from GPS satellites, which means they require clear antenna line of site to the sky. This is accomplished in one of two ways:
- Window-mounted: The GPS antenna is mounted inside the building, in a window with a clear view of the sky. The obvious disadvantage to these models is that they need unobstructed access to a properly oriented window. In some cases, this may be hard to come by.
- Exterior: Using units with exterior antennas is the second method. A receiver and master clock, is rack-mounted, located with other network equipment in the system. The antenna is located outside the facility, either wall- or roof-mounted. This places the antenna above other obstacles which may obstruct its connection to satellites. However, this is an obvious added expense, since exterior walls and roofs can be difficult and costly to penetrate.
GPS models are available in various price ranges. Veracity's TIMENET ($700-800 online) is a common option, and uses an interior window antenna. The latest version of TIMENET is PoE-powered, so it may be remotely located without need of a local power outlet, unlike its predecessor. For more systems requiring more precise capabilities and an exterior antenna, a number of manufacturers are available, such as Spectracom, Symmetricom, and Meinberg. Units such as these are commonly 2-3x the price of other options, however, and are normally only used when absolutely necessary.
Network Time-based: Master time servers which obtain their time from an NTP source are also available, and from many of the same sources as GPS clocks. The disadvantage to dedicated NTP servers is that once again, ports to the internet need to be opened, which will be unacceptable to some users. Generally, master clocks drawing time from NTP sources are only used when there is a reason users don't want to make an existing server into a master time server.
1 report cite this report:
Back to Top