Timing & precision time (NTP, PTP)
Every log line, certificate, trade, broadcast frame and cellular handoff depends on clocks that agree. The Network Time Protocol (NTP, RFC 5905) keeps ordinary servers and devices within milliseconds of each other over a normal network, and Network Time Security (NTS, RFC 8915) adds TLS-based key setup and authenticated packets so a forged time reply can be detected. We design the time hierarchy for a business: which sources are trusted, how many, and how clients are told to use them.
What we do
- Time-source architecture with redundant, authenticated NTP/NTS
- PTP deployments with grandmaster, boundary and transparent clocks
- Profile selection for telecom, broadcast and enterprise needs
- Hardware-timestamping setups on Linux servers and NICs
- GNSS antenna, holdover and spoofing-resilience planning
- Offset, path-delay and clock-class monitoring and alerting
- Audit-ready time evidence for logs and regulated records
Where milliseconds are not enough, the Precision Time Protocol (IEEE 1588-2019) synchronizes clocks across a packet network to well under a microsecond when switches help with timestamping. Profiles tune it for a field: ITU-T G.8275.1 for telecom phase and time with full on-path network support, and SMPTE ST 2059-2 for professional broadcast. A grandmaster clock, usually disciplined by GNSS (satellite time), feeds boundary and transparent clocks in the switches, and ordinary clocks on the endpoints.
This is part of our network and server practice for trading floors, broadcast plants, telecom edges and any regulated environment that must prove when something happened. We pair it with monitoring that watches offset and path delay, and with a plan for GNSS loss, jamming or spoofing, including a holdover oscillator and a second source.
Leading platforms we work with
- Meinberg
- chrony
- linuxptp
- Microchip
Platforms and practices
- NTP servers and pools (RFC 5905)
- Network Time Security (RFC 8915)
- PTP IEEE 1588-2019
- ITU-T G.8275.1 telecom profile
- SMPTE ST 2059-2 broadcast profile
- GNSS-disciplined grandmaster clocks
- Boundary and transparent clocks
- Hardware timestamping on Linux
- Holdover oscillators
- Offset and path-delay monitoring
References
- RFC 5905: NTPv4
- RFC 8915: Network Time Security for NTP
- IEEE 1588-2019 Precision Clock Synchronization Protocol
- ITU-T G.8275.1: PTP telecom profile, full timing support
- SMPTE ST 2059-2: PTP in professional broadcast
- Meinberg
- chrony
- linuxptp
Sources last checked .
Product names are trademarks of their owners and are listed to describe our experience; they do not imply endorsement or partnership.
How we use Timing & precision time (NTP, PTP) for clients
Managed IT Services
We run your IT day to day so it stays secure: help desk, devices, Microsoft 365, Exchange, Active Directory, backups, networks and monitoring.
Learn moreCybersecurity
We find out whether everything you run is safe from attackers, then we fix it.
Learn moreTailored Software
Software built around your business in weeks, and you own the code.
Learn moreFrequently asked questions
Direct answers to the questions we hear most. Something else on your mind?
Send us a messageWhen is NTP enough and when do we need PTP?
NTP (RFC 5905) keeps ordinary servers and devices within milliseconds of each other and is enough for most business systems and log correlation. Choose PTP (IEEE 1588-2019) when you need well under a microsecond, such as trading, broadcast or telecom, and only if the switches on the path support PTP timestamping.
Does NTS make NTP secure by itself?
NTS (RFC 8915) uses TLS-based key setup so a forged time reply can be detected, which closes a real gap. It does not protect the time source itself. If the upstream server or the GNSS signal is wrong, clients will faithfully authenticate the wrong time, so source choice and cross-checking still matter.
What happens to our clocks if GNSS is jammed or spoofed?
A grandmaster that trusts only GNSS can drift or, worse, follow a false signal. We plan for it with a holdover oscillator that keeps good time for a limited period, a second independent source and monitoring that raises an alert when offset or clock class changes, instead of silently continuing.
Can PTP run across ordinary switches?
It runs, but accuracy degrades. Sub-microsecond results depend on boundary or transparent clocks in the switches and hardware timestamping on the endpoints. Unaware switches add variable delay that software cannot remove, so we check the path hardware before promising a figure.
How many time sources should a business use?
Use more than one independent source so a single bad clock can be outvoted. Chrony and NTP clients can compare several servers and discard an outlier. Which sources, how many and how clients are told to use them is the hierarchy we design with you.
How do we prove when something happened for an audit?
Keep every system on the same authenticated time hierarchy, monitor offset continuously and retain those measurements with the logs. Auditors usually care less about perfect accuracy than about evidence that clocks agreed within a stated tolerance at the moment in question.