Jitter-Free Clock Offset Measurement via Hardware Timestamping
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Software-only solutions for clock synchronization are limited by system noise, resulting in high jitter and inaccurate microsecond-level synchronization, while hardware solutions like IEEE 1588 face challenges with delays and asymmetry in timestamp exchanges.
Innovation Solution
A method involving concurrent timestamp exchanges between client and server, using a 'pingpong' protocol with optional acknowledgments, determining apparent delays, and selecting minimum values to calculate clock offset, which reduces system noise and jitter by exploiting noise-free time windows and leveraging RDMA for low-latency communication.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of manufacture
If software-only solutions are used for clock synchronization, then implementation simplicity is improved, but measurement precision deteriorates due to system noise limiting accuracy to 10 microseconds or worse
Solution Approach 1:
The patent extracts the timestamp recording function from the software processing path and places it directly in the network adapter hardware. This separation removes the software processing delays and jitter from the critical measurement path, allowing software-only implementation simplicity to be maintained while achieving hardware-level measurement precision.
Solution Approach 2:
The patent introduces an intermediary mechanism where the network adapter hardware acts as a mediator between the network communication and the software synchronization protocol. The hardware captures timestamps autonomously and stores them in buffers, serving as an intermediary that bridges the gap between software simplicity and hardware precision requirements.
2Measurement precision
If hardware solutions like IEEE 1588 are employed to achieve microsecond-level synchronization, then measurement precision is improved, but device complexity worsens due to requiring specialized network adapters with IEEE 1588 support at both ends
Solution Approach 1:
The patent implements a simplified copy of the hardware timestamping functionality within standard network adapters. Instead of requiring full IEEE 1588 hardware support, the solution copies only the essential timestamp capture and buffer storage functions into the network adapter, achieving microsecond-level precision without the complexity of complete hardware protocol implementation.
3Measurement precision
If traditional timestamp exchange protocols are used, then clock offset measurement is achieved, but reliability deteriorates due to high jitter from software and hardware delays
Solution Approach 1:
The patent performs preliminary action by having the network adapter capture and store timestamps in buffers before software processing occurs. This preliminary hardware-level timestamping ensures that the critical measurement data is captured without subsequent software delays or jitter, improving both reliability and precision of the clock offset measurement.
Solution Approach 2:
The patent maintains continuity of useful action by keeping timestamps continuously available in hardware buffers while software processes them at its own pace. This continuous availability of precise timestamp data without software intervention gaps ensures reliable and jitter-free measurements, as the useful action of timestamp recording continues uninterrupted in hardware.
Data Source
AI summary
A clock offset between a client and a server is measured by: (a) the client sending a request to the server; (b) upon receiving the request in step (a), the server optionally sending a server acknowledgement to the client; (c) upon the client receiving the server acknowledgement in step (b) or directly, if no acknowledgement was used, each of the client and the server proceeding to concurrently exchange their respective timestamps with each other a multiplicity (n) of times, thus forming a multiplicity (n) of timestamp exchanges; and (d) determining a plurality of apparent forwards and backwards delays based on the multiplicity (n) of timestamp exchanges. The preferred apparent forwards and backwards delays are then selected based on the minimum values (for each direction) determined in (d) above. The clock offset between client and server is then determined based on the preferred apparent forwards and backwards delays.