NTP / Network Time Guide For Video SurveillanceBy IPVM Team, Published Jan 10, 2019, 12:34pm EST
Inaccurate time can lead to missing or inadmissible video, yet this topic is often overlooked, with cameras and servers left defaulted, synchronized to different sources or not at all. However, setting up a proper time server in a surveillance network often requires little time or money and can prevent or mitigate these potentially disastrous issues.
In this guide, we review network time for surveillance, covering these key topics:
- Time protocols: NTP, SNTP, Windows Time
- How cameras handle time sync - on arrival vs camera timestamp
- How recorders / VMS synchronize time
- Time server options
- What you should sync
- IP vs Non-IP Cameras
Time Protocols: SNTP, NTP, PTP
There are three common time protocols in use in networks today:
- SNTP: Simple Network Time Protocol is the simplest time protocol in use, and also most common in surveillance. SNTP uses fewer resources than NTP or PTP, which makes it appropriate for lower powered devices such as IP cameras and embedded recorders. However, it is less accurate than NTP, able to sync only to a single source, and does not perform extensive error checking of its source, which can lead to inaccurate time (though this is not common).
- NTP: Network Time Protocol is more complex than SNTP and requires more resources, but it is able to synchronize to multiple time sources, perform error correction and checking of sources for time drift from expected. It is generally used by Windows/Linux servers or dedicated time servers.
- PTP: Precision Time Protocol is relatively new compared to NTP/SNTP, and was introduced for synchronization of highly sensitive applications. While NTP and SNTP provide millisecond accuracy, PTP is accurate down to nanoseconds. Because of this, it requires hardware support for proper timing and greater resources than other protocols, and is generally not used in surveillance.
A time server running one of these protocols provides time to devices (cameras, client PCs, servers, etc.) which request it. This synchronization is often performed every hour, though some may choose to run it more often, in cases where high accuracy is required. Note that running time synchronization on a small number of devices produces very little traffic, so reducing sychronization interval is likely to have little impact on the network.
Surveillance devices often are not clear whether they support NTP or SNTP. It is common for devices to simply state 'time synchronization' instead of SNTP or NTP specifically. Effectively, though, devices support both protocols, as synchronization packets are identical. Additional features of NTP not supported by a SNTP requesting devices are simply disregarded.
It's worth noting that Windows includes a time protocol of its own which has historically been used in many networks. However, configuring a time server using Windows Time requires users to edit the Windows registry, which many users may not be comfortable with. Additionally, it is notoriously inaccurate, with multiple seconds of drift common, so should not be used in surveillance.
How Cameras Handle Time
The vast majority of current IP cameras, including low cost and consumer models, allow for automatic synchronization of the camera to a time server. Users typically simply enter the server IP address or hostname, port, and time zone, and the camera retrieves current UTC time and adjusts its on-board clock. This synchronization is typically performed hourly, though some cameras allow for a different interval to be set.
This image shows these typical settings:
Time Zones And Daylight Savings
Because time servers provide UTC, which applies no time zone or daylight savings (DST) adjustments, these settings must be configured in the camera. Each camera must be set to its local time zone. For DST, many devices include configurable options for start/end dates and time offset (typically 1 hour). Camera time is automatically adjusted when DST begins and ends.
These settings are shown in this sample image:
However, in some cameras, only an "enable DST" checkbox is provided, and users must manually set and reset time when daylight savings begins and ends. Care should be taken to ensure this is done, as inaccurate time will be provided if it is not.
In addition to automatic sync options, many cameras also allow the time to be manually set. This is not recommended, as manual adjustment may easily be forgotten or incorrectly set, and adjusting time on even a handful of cameras may become tedious and time consuming. Because each camera is changed manually, it is difficult to get the time on each camera to the same second, and could be a minute or more off. Drifting will occur over time and can cause the cameras to be many minutes or more off. In this case you may see obscure time differences (i.e. 6 minutes off, 18 minutes off, etc) between cameras and other devices on the network.
How Recorders / VMS Synchronize Time
There are two ways VMSes handle timestamps: stamping frames upon arrival, or using the camera's timestamp.
Stamping on Arrival
Stamping on arrival is exactly what it sounds like, with the VMS marking the time it receives each frame of video. This avoids issues caused by camera time being inaccurate, as the server is the sole source of time. 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. However, this is rarely a practical concern, as time differences are very small (<1 second) and these issues are not common.
Using Camera Timestamps
Other systems use the timestamp added to video by the camera. If cameras are properly synchronized to a time server, this should not be an issue. However, if one or more cameras are using inaccurate time, issues may result, varying from annoying to severe.
If a camera's clock is fast by two hours, video on the VMS system will be marked as two hours off. Searching for video at the expected time will produce video from another time, while the desired video has actually been stored two hours in the future. This makes synchronized playback unusable. Worse, it may make video inadmissible in court, as the timestamps do not reflect the actual time a crime took place.
There are three basic ways to serve time to a surveillance network:
- Public Servers
- Private Servers
- Dedicated Time Servers
Public servers such as time.gov and ntp.org are most commonly used to synchronize time of PCs, though some cameras also use them by default. However, in order to use these servers, all devices must have internet access, which is often undesirable in surveillance networks. Also, using these servers for multiple devices is considered poor practice in the IT industry, as local servers greatly reduce traffic and requests made of public sources.
In a surveillance LAN, one (or more) servers may be configured as a time server. This machine then retrieves time from a public source such as ntp.org or is manually set, and serves time to all other devices in the network. This is most often configured via third party programs such as Meinberg NTP or NetTime.
This screenshot shows the setup of a typical NetTime server, in this case pulling from multiple sources, with a 15 minute synch frequency:
Since nearly any PC may be set up to act as a time server (including the VMS server), without much-increased load, private servers retrieving time from an Internet source is the most common time synching option in surveillance.
Dedicated Time Servers
Finally, in systems where accurate time is required but the surveillance system is not connected to the internet, dedicated GPS based time servers are used. These devices retrieve time from GPS satellites via antenna, either mounted to a window or external, and act as NTP/SNTP servers for the rest of the network.
Dedicated GPS time servers vary in price. Lower priced models range from about $300 USD online (Time Machines TM1000A) to about $700 USD online (Veracity Timenet). Advanced servers (such as Spectracom and Meinberg) with extremely precise nanosecond accuracy, redundant external antennas, and other advanced features sell for easily 2-3 times this price, or more.
Because of the added installation and material cost, GPS servers are typically only used in systems where the surveillance network is closed, without access to the internet.
IP vs Non-IP Cameras
Non-IP Cameras, like analog, HD analog, HD-SDI, do not have any concept or implementation of 'time'. The encoder or recorder these cameras connect to stamps time when video is received. In small systems, with only a single encoder or recorder, this generally results in the time of all cameras being synchronized. A time server, however, can still be beneficial to ensure the time is accurate. Moreover, if there are multiple recorders connecting to non-IP cameras, the same risk exists with those recorders being out of sync like multiple IP cameras.
What Should I Sync?
To avoid any potential problems, regardless of how the VMS server handles timestamps, we recommend that all cameras, VMS servers, and clients be synchronized to the same time source. Though it may not be necessary, entering time server information requires minimal time during initial setup and eliminates one potential source of issues.
Test Your Knowledge
Click here to take a 6 question quiz
[This report was originally written in 2013, but updated in 2019 with more information and examples]
5 reports cite this report:
Back to Top