This post is based on a Gestalt IT Showcase by Intel Corporation
If you’re like me, being stuck in quarantine is just like Groundhog’s Day… the same moment playing over and over endlessly until the end of time. Monday, Tuesday, and Wednesday blur into Thisday, Thatday, Whatday. So, I thought it was deliciously ironic to be part of a lively discussion on hyper-accurate network timekeeping while stuck in the void.
In this latest installment of …Just for Fun! we explore network timekeeping in general, and trends that have pushed network time to its hyper-accurate limit.
What Time Is It, Anyway?
Having a way for all the devices in a network to be on the same clock is such a ubiquitous idea that we take time synchronization for granted. For example, every GPS enabled device needs an accurate time, and GPS is everywhere! Smartphones, tablets, and laptops are obvious. But more and more, GPS is showing up everywhere. Cameras, fitness trackers, and dog collars. Jewelry, for Pete’s sake!
Traditionally, network time synchronization relied upon Network Time Protocol, good old NTP. And NTP could keep a network reasonably synchronized to within a few tens of milliseconds if you were relying on an Internet-based reference clock. For many, if not most, applications, NTP remains a perfectly adequate timekeeping standard. Most, but not all. Some industries have pushed time sync requirements to well beyond what NTP can handle.
Enter Precision Time Protocol. PTP achieves time synchronization to below the microsecond level.* PTP is now used in several industries:
- Telecommunications, especially for 4G/5G, and 911 trilateration
- Finance, to prevent fraud
- Energy, to monitor for and prevent blackouts
- Manufacturing, to synchronize robotic production
One Clock? Two Clocks?
There’s an old joke that goes if you have one clock you always know what time it is, but if you have two you never know. Both NTP and PTP tackle this thorny issue by having a master source of time. In turn, the master sources ultimately take their time from an atomic clock, which calculates time by relying on the regular oscillation of electrons.
Once the time from the master clock is obtained, that information will travel throughout the network, whatever that network happens to be. NTP and PTP both must account for the travel time of the data and calculate some offset for all devices to actually be in sync. And, therein lies the rub.
Since the offset is a function of the physical distance between network devices and their time master, at some distance, the offset will be so large as to make the synchronization ineffectual.
One solution to the faraway time-master problem is to create a master within your own network. Take, for example, Intel’s new Ethernet 700 Series Network Adapter, AKA Edgewater Channel. This PCIe adapter natively supports hardware-enhanced PTP, and when coupled with a GPS input can be used to create a PTP grandmaster. Interestingly, the adapter comes equipped with its own high-precision oscillator on board, which allows the device to generate its own synchronizing pulse. While Intel originally thought to leverage this new adapter in edge servers, Intel was interested in using its new adapter in other arenas.
One such arena is in autonomous cars. Human drivers have an average reaction time somewhere in the neighborhood of a quarter of a second, and to put that into some perspective, a car traveling at 60MPH will travel one inch in one millisecond. So, it’s no wonder that human drivers are always banging into things. We can’t actually react as fast as we can drive. An autonomous car that can synchronize with its neighbors and surroundings can. And as time sync becomes more accurate, self-driving cars become more responsive.
As I mentioned, the discussion was lively. And as always, keep networking …Just for Fun!
*Do you remember your high school metric conversions? One microsecond (abbreviated ms or msec) is 0.001 millisecond (µsec).
