Of even greater concern is synchronizing different clients within the same network. Imagine a financial institution that has exactly 100 shares of Company X’s stock. Big news breaks concerning Company X, and the financial institution sells those 100 shares not to just one investor but several over the span of a second, but because the institution’s servers aren’t synchronized with one another, there is no way to tell which buy order came first.<\/p>\n
The most secure and precise method for network time synchronization is using a local GNSS (Global Navigation Satellite System) time server as your master network clock. The time source from the GNSS network is highly accurate atomic clocks based in the satellites and synchronized with even more accurate ground stations. A GNSS based network time server provides you a Stratum 1 time source within your internal network that will be reliable, and unlike a public time server, is not impacted if the internet goes down. Up until a couple of years ago the standard network time protocol was NTP, but with much higher speeds on networks today then you have to decide whether NTP will meet the requirements, if not then you need to go to PTP. So how do you decide which protocol is right for you.<\/p>\n
NTP Servers<\/h2>\n
NTP servers can synchronize clocks and other local network devices within microsecond accuracy, which suits most business and industrial needs for time serving accuracy.<\/p>\n
NTP, or Network Time Protocol, has a hierarchical system with different layers called strata. Stratum 0 devices at the very top include atomic clocks, like those in GNSS satellites.<\/p>\n
Stratum 1, or primary time servers, each have a one-on-one direct connection with a Stratum 0 clock, achieve microsecond-level synchronization with the Stratum 0 clocks, and connect to other Stratum 1 servers for quick sanity tests and data backup. Stratum 2 servers can connect to multiple primary time servers for tighter synchronization and improved accuracy, and so on and so forth. NTP supports up to a maximum of 15 strata, but every stratum slightly decreases client synchronization from Stratum 0.<\/p>\n
A 64-bit timestamp as currently implemented is split up into two equal 32-bit parts:<\/p>\n
- \n
- The first half counts the number of seconds up to just over 136 years<\/li>\n
- The second half express fractions of a second down to the picosecond scale<\/li>\n<\/ul>\n
NTPv4, designed for broadcast applications, has a 128-bit timestamp, and provides time resolution to the microsecond range. This is fine for networks that run at the IPv4 level, or wireless data comms networks run in the MB\/s range.<\/p>\n
However, if greater than microsecond synchronization accuracy is required, a PTP server might be the best bet.<\/p>\n
PTP Servers<\/h2>\n
PTP, or Precision Time Protocol, is another network-based time synchronization standard, but instead of millisecond-level synchronization, PTP networks aim to achieve nanosecond- or even picosecond-level synchronization. For most commercial and industrial applications, NTP is more than accurate enough, but if you need even tighter synchronization and timestamping, you’ll need to migrate to a PTP server. With the introduction of faster digital networks such as 5G a PTP network is mandatory.<\/p>\n
Why is PTP timestamping so accurate? It uses hardware timestamping instead of software, and like any other fine scientific instrument, PTP equipment is dedicated to one specialized purpose: keeping devices synchronized. For that reason alone, PTP networks have much sharper time resolutions, and unlike NTP, PTP devices will timestamp the amount of time that synchronization messages spend in each device, which accounts for device latency.<\/p>\n
Every PTP sequence involves a series of four messages between master and slave, and this sequence produces four different timestamps. The master sends all four timestamps to the slave during the delay response phase, and the slave is able to calculate the network latency between the master and slave in both directions. By having specialized hardware fetch timestamps from the local clock, slave devices can avoid extra latency introduced by the local operating system.<\/p>\n
NTP networks have extra latency and less accuracy simply because they’re software-based, and all timestamp requests must wait for the local operating system to respond. For most companies, NTP provides a sharp enough time resolution to resolve conflicts in a timely manner, but for a growing number of organizations a far greater level of synchronization is required. Read our article on Smart Grids for example.<\/p>\n
Benefits of Time Server versus Public Internet Time Source<\/h3>\n
Let\u2019s start by talking about latency. If you use a time source from your internet provider you need to understand the delays that occur through all the connections from your service providers time source to your local router. Your service provider will most likely use a GNSS Time Server to obtain UTC (Universal Time Code) to input into their network controller. Then the time code will be switch through internet switches, firewalls, through cables and more switches to finally arrive at your premises. Every time that the time code has to pass through a network node like a switch, then a delay is introduced, so by the time the time code arrives at your desk it has been delayed for a long period of time.<\/p>\n
It may not be important that your time source is out by more than a few seconds to UTC, but if it is important then you must find another source that will give you accurate time to within microseconds to UTC. The most simple, secure and cost-effective way is to use the GNSS that allows you to place your time source within your firewall and have all your local network devices to be time synched to within a few microseconds, or with a PTP server, within nanoseconds. This is critically important if you need to have synchronised time between different locations. Because the GNSS time source from every satellite is highly accurate as well as being synchronised back to earth stations, then by using either NTP or PTP time servers in each location, the timing will be accurate to milliseconds or nanoseconds as required.<\/p>\n
What Happens if My Time Server is Disconnected?<\/h3>\n
The GNSS network consists of multiple satellite constellations such as GPS, GLONASS, BEIDOU, QZSS, etc. and these networks also transmit time signals over multiple frequencies. So, if one satellite constellation goes down then you still have other constellations or frequencies to obtain the time code.<\/p>\n
But if the problem is more localised, for example, your antenna was damaged during a storm, then you need to use a time server that has built in \u201chold-over\u201d capability. Hold Over is where the time server has a highly stable Real Time Clock that is able to keep accurate time for the period that it takes to restore satellite signals. For highly secure installations then it is recommended to use redundant time servers with individual GNSS antennas.<\/p>\n
Introducing the Trimble Thunderbolt NTP TS200 Time Server<\/h3>\n
![](\"https:\/\/stepglobal.com\/wp-content\/uploads\/2022\/07\/Trimble-Thunderbolt-TS200.jpg\")
![](\"data:image\/svg+xml,%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20viewBox%3D%220%200%20300%20171%22%3E%3C%2Fsvg%3E\")
![](\"https:\/\/stepglobal.com\/wp-content\/uploads\/2022\/07\/Trimble-GM200-Grandmaster-Clock.jpg\")
![\"Trimble](\"https:\/\/stepglobal.com\/wp-content\/uploads\/2022\/07\/RES-720.jpg\")
![\"Precision](\"https:\/\/stepglobal.com\/wp-content\/uploads\/2020\/01\/Email-Footer-300x103.jpg\")
![\"Precision](\"data:image\/svg+xml,%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20viewBox%3D%220%200%20300%20103%22%3E%3C%2Fsvg%3E\")