Time synchronization serves a fundamental role in any network, but it’s too often added as an afterthought. However, it can mean the difference between correctly troubleshooting a conflict in minutes and having no idea why the server is figuratively on fire. For financial and scientific institutions, time synchronization must be accurate to a billionth — or in some specific cases even a trillionth — of a second, but even commercial and industrial organizations are starting to push for synchronization accuracy in the sub-millisecond range.
Why can’t we just update our computers to the public NTP servers at NIST, which runs one of the world’s most accurate clocks, and call it a day? Unfortunately, latency exists everywhere, and it makes perfect synchronization impossible. The speed of light is fast — in a vacuum, a photon could circle our world more than seven times per second — and even though it travels approximately 31 percent slower through a typical optical fiber network, you could easily transmit a single bit of data halfway around the world in less than a tenth of a second.
However, we all know that that ideal world doesn’t exist. Add in switches, routers, and other network infrastructure, and that tenth of a second multiplies several times over. Without specialized equipment, your network is suddenly off by the better part of a second from NIST or NPL in the UK.
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.
Network Time Protocol
NTP, or Network Time Protocol, has been widely adopted as a means of network timekeeping, and it’s currently in its fourth major version. The hierarchical system has different layers called strata. Stratum 0 devices at the very top include atomic clocks, like those in GNSS satellites.
Stratum 1, or primary time servers, each have a one-on-one direct connection with a Stratum 0 clock, achieve microsecond-level synchronization with 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.
A 64-bit timestamp as currently implemented is split up into two equal 32-bit parts:
- The first half counts the number of seconds up to just over 136 years
- The second half express fractions of a second down to the picosecond scale
A proposed update to 128-bit timestamps to NTPv4 would increase the time scale to just under 600 billion years and the time resolution to less than a femtosecond.
Precision Time Protocol
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.
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 actually timestamp the amount of time that synchronization messages spend in each device, which accounts for device latency.
Every PTP sequence involves a series of four messages between master and slave:
- The initial sync message from master to slave
- A followup sync message from master to slave
- A delay request message from slave to master
- A final delay response message from master to slave
This sequence produces four different timestamps:
- T1 when the master sends the initial sync message
- T2 when the slave receives the initial sync message
- T3 when the slave sends the delay request
- T4 when the master receives the delay request
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.
NTP networks have extra latency and less accuracy simply because they’re software-based, and all timestamp requests have to wait for the local operating system. For most companies, NTP provides a sharp enough time resolution to resolve conflicts in a timely manner, but certain organizations including the aforementioned physics laboratories require a far greater level of synchronization. Governed by the IEEE 1588 standard, both our GMR 1000 and GMR 5000 PTP Grandmaster Time Servers:
- Support multiple outputs including PTP, NTP, PPS, PPO, 10MHz, SMPTE, IRIG-B, IRIG- A, IRIG-E, NMEA 0183, NENA
- Provide accuracy to within 15 nanoseconds of UTC
- Offer SSH configuration with AES256 encryption
- Include IPv4/IPv6 network compatibility
- Can function as an NTP client and/or server
Why Bother with a Time Server at All?
Timestamping and client synchronization is vital for your network, but some network engineers still feel like they can get away with simply syncing their servers to a public internet clock. While perfectly fine for consumer devices like smartphones, internet clocks are poorly suited for business networks for one simple reason: security.
To connect your server to an internet clock requires you to first open up port 123 on your firewall. Will something horrible happen as a result? We don’t know, but we don’t know in the same way that we don’t know if a burglar will break in because you left the front door unlocked on your home. Why take the chance? A dedicated NTP server keeps your network secure while providing more accurate timestamping.
What Happens If My Time Server Is Disconnected?
No network is perfect, and all you can hope to do is minimize downtime instead of eliminating it. If your NTP or PTP time server is unable to connect to a GPS satellite or other input for whatever reason, you can rest assured that it will continue to synchronize your devices and maintain accurate timestamping.
For example, our NTP100-GPS NTP server has a holdover stability of 3 seconds per year, meaning that your server will still be synchronized to within 3 seconds of UTC after an entire year in the dark. The high-stability model with an oven-controlled crystal oscillator boasts even greater holdover stability of 250 milliseconds per year — that’s less than 1 millisecond per day. Our HSO-3 oscillator option, which is only available on our GMR5000 NTP Server and PTP Grandmaster, further reduces drift to a maximum of 1 millisecond per year.
Do you have questions about network timing? Need help deciding what network timing technology is best for you?
Contact Progreso Today
Reference: Network Timing Technology: NTP vs. PTP