A different way to build a time server
Most production timekeeping architectures rely on a Stratum 1 device directly linked to an authoritative time source, typically a global navigation satellite system (GNSS) receiver or a cesium clock. Many organizations use public NTP pools for this role, in part because they find off-the-shelf time appliances limiting. Those commercial devices often run closed-source software, are difficult to configure and monitor beyond a proprietary CLI or SNMP interface, and are not user-serviceable. A single failed component can mean shipping the unit to a vendor or replacing it outright. Low production volumes also make them pricey enough that alternative designs have been largely out of reach.
Meta's engineering group took a different route: it designed a PCI Express (PCIe) card that converts an ordinary x86 server into a time appliance, and — with the Open Compute Project community — published the design as the Open Compute Time Appliance Project. The card itself, called the Time Card, carries a multiband GNSS receiver, a miniaturized atomic clock (MAC), and a field-programmable gate array (FPGA) that implements the timing logic. The goal was to keep the benefits of a dedicated appliance — accuracy within tens of nanoseconds of GNSS time, with a holdover of roughly one microsecond over 24 hours if the satellite signal is lost — while using open-source drivers and standard server components.
Prototype first, then productize
An initial prototype connected an off-the-shelf GNSS-disciplined oscillator to the external time-stamping input of an NVIDIA Mellanox ConnectX-6 Dx NIC. Using the ts2phc tool, the team synchronized the NIC's physical hardware clock to within a few tens of nanoseconds. That setup proved the concept but left the timing components as discrete, separate hardware.
The follow-up design board brought the GNSS receiver, oscillator, and processing logic together on the PCIe card. The card uses its FPGA to implement a time engine that interpolates between consecutive one-pulse-per-second (PPS) signals from the GNSS receiver, producing nanosecond-resolution timestamps.
A key design tension: GNSS timing is accurate to roughly tens of nanoseconds, while calibrating the atomic clock requires precision on the order of 10 picoseconds. The resolution lies in how calibration is done. GNSS receivers are continuously corrected against standard time from the satellite constellation, so they have almost no long-term drift. By comparing a counter driven by the MAC against the GNSS PPS signal — and by averaging over a longer measurement window — the system can discipline the atomic clock far more precisely than a single pulse comparison would suggest.
The oscillator runs at 10 MHz and feeds both a digital clock module and a digital PLL. The PLL multiplies and divides the signal to produce a 125 MHz reference (8-nanosecond periods). The ToD unit accumulates increments of 0b000001, where the least significant bit corresponds to 250 picoseconds of subsecond time. The PPS signal from the GNSS receiver snapshots this counter. If the 125 MHz clock were perfect, each snapshot would match a theoretical one-second interval; in practice there is always a small mismatch, adjusted by a proportional-integral (PI) control loop. The PI loop can nudge the accumulated value in 250-picosecond steps, fine-tune the digital PLL, and — for the finest adjustments — steer the rubidium oscillator directly.
When GNSS connectivity is lost, accuracy degrades according to a metric called holdover. A MAC is typically specified to stay within one microsecond over 24 hours. Newer chip-scale atomic clocks can accept PPS inputs directly, letting the time engine hand off the syntonization task to the oscillator rather than spending digital resources on it. The expectation is that a more precisely tuned oscillator yields better holdover.
Running as a stratum 1 source
Once the Time Card is installed and the system booted on a modern Linux distribution, the kernel driver (included since version 5.15, or buildable from the OCP GitHub repository on 5.12 and newer) exposes a set of devices: the PTP hardware clock (PHC), GNSS, PPS, and the atomic clock's serial interface. The devlink command-line tool monitors card health and can flash a new FPGA bitstream.
Configuring a chrony NTP server is a matter of pointing the refclock directive at the Time Card device. The result is a stable NTP Stratum 1 server. For PTP service (for instance, with Meta's open-source ptp4u server), the Time Card PHC must be synchronized with the NIC PHC — a task that phc2sys handles, keeping the pair in agreement within single-digit nanoseconds.
For best results, the Time Card and the network interface card should share a CPU PCIe lane, and the card's PPS output can be wired to the NIC's PPS input. To validate the implementation, the team used an external Calnex Sentinel measurement device. Over a 48-hour observation, NTP measurements stayed within ±40 microseconds; PTP offsets stayed in the nanosecond range. Comparing the card's PPS output to the Sentinel's internal reference showed combined error within ±200 nanoseconds. In a separate 24-hour holdover test, PPS drift stayed inside 300 nanoseconds — comfortably within the atomic clock's specification.
The hardware design leaves room for cost scaling: the atomic clock module can be replaced with an oven-controlled crystal oscillator (OCXO) or temperature-compensated crystal oscillator (TCXO) for applications where long holdover is less critical. The PCIe form factor and open driver support mean the same appliance-level precision is achievable on a commodity server, or even a home PC with spare PCIe slots — provided the NIC supports hardware time-stamping.
A Design Built to Share
Bringing the Time Card to life was only part of the goal. To push the industry forward, Facebook engaged with the Open Compute Project (OCP) to launch the Time Appliance Project (TAP). Under this umbrella, all of the design files—including specs, schematics, mechanics, the bill of materials, and the full source code—are now available in the OCP GitHub repository.
The result is a truly vendor-neutral path for building your own Time Card for a fraction of what a commercial appliance costs. The only catch is comfort with printing a PCB and soldering small components. For those looking to skip the build process entirely, vendors such as Orolia are already producing and selling cards, and NVIDIA is shipping precision timing-capable hardware in the ConnectX-6 Dx and BlueField-2 DPU.
To tie the pieces together, an Open Time Server specification is available at www.opentimeserver.com. This spec details how to combine the required hardware components—the Time Card, a networking card, and a standard commodity server—with software such as OS drivers, and either NTP or PTP servers. By building from this blueprint, engineering teams retain complete control over configuration, monitoring, management, and security of their timing devices.
What Comes Next
The Time Appliance is a major step toward healthier timing infrastructure, and work on it is not finished. The team is continuing to improve synchronization precision and accuracy on its own servers, with the plan to keep releasing that work back into the open via the OCP community.
