Baeldung - CS

Learn all about Computer Science

Clock Offset vs Clock Skew in Distributed Networks
2025-06-13 14:56 UTC by Sandip Roy

1. Introduction

Clock offset and skew are two important terms in networking and distributed systems. They are similar but distinct concepts that relate to networked systems’ time differences.

Accurate time synchronization in distributed systems is critical to ensuring reliable network operations. Clock synchronization on multiple platforms is fundamental to everything from event logging, consensus procedures, event ordering, to database transaction consistency. However, it isn’t easy to achieve because there is no universal clock to serve as a reference and because hardware and software differences introduce challenges to synchronization.

In this tutorial, we’ll explain clock offset and skew, their role in time synchronization, and methods to achieve it.

2. Clock Skew and Clock Offset

Clock skew is the difference in the rates at which two clocks progress over time. Even if one clock’s ticking rate is marginally faster than the other’s, the difference will accumulate, producing a substantial drift between them.

The clock offset is the difference in the timestamps of two clocks at a given time.

Let’s visualize these concepts:

The left pair shows the offset: at the same reference moment, the first clock displays 10:10:15, and the second displays 10:10:20. The offset is 5 seconds (the absolute value).

The right pair shows the skew: the second clock’s rate is slightly longer than one second per tick, meaning it gradually diverges from the first clock over time, leading to cumulative drift. The skew is 0.01. The difference may seem negligible, but the offset grows. After 100 seconds, it will be a second. After 10,000 seconds (2.8 hours), the lag will reach 100 seconds. The difference will exceed 14 minutes if left unsynchronized for a day (86,400 seconds).

2.1. Where Is Synchronization Important?

For time-sensitive applications like logging, transaction ordering, or system coordination, these are function-disrupting differences.

For example, servers must maintain strict consistency in distributed database replication. When clocks drift, transaction timestamps may misalign, resulting in data integrity concerns or ordering conflicts.

Trading orders could be misinterpreted if one transaction logs them at 12:00:00 and another at 12:00:05, leading to compliance issues or financial loss.

Let’s consider another example: autonomous vehicle systems. Here, several sensors gather data in real time for obstacle detection. The system may erroneously combine data if the clock skew causes the LIDAR sensor timestamps to differ from the camera’s, which could result in unsafe obstacles being positioned incorrectly.

3. Causes of Skew and Offset

There are several contributing factors.

The one-way delay asymmetry, for example, means communication delays vary based on the transmission direction. Hardware inconsistencies, network congestion, and transmission path variations frequently cause this.

Additionally, hardware variability affects how each clock develops over time and reflects variations in oscillator stability and hardware configurations. External factors like temperature variations or system load can change clock precision and impact synchronization. Skew (and offset) can result from software, not just hardware. For example, OS scheduling can cause skews, and delays in interrupt handling can accumulate over time and produce a significant offset.

4. NTP

NTP is one of the most popular and established protocols for synchronizing computer clocks across networks. It guarantees the timekeeping precision in distributed systems.

On LANs, it is usually better than a few milliseconds over the public internet. The following figure shows the structure and timestamps exchange between a client and a server:

NTP Time Synchronisation

Here, NTP uses timestamps exchanged between the client and server to determine the clock offset and network delay.

4.1. Pros and Cons

NTP has its pros and cons:

Pros	Cons
Widely accepted and simple to implement.	Unpredictable network conditions (such as jitter or packet loss) might cause accuracy to deteriorate.
Utilises common internet infrastructure.	Usually work between 1 and 50 ms, which is insufficient for applications requiring extreme precision (like stock trading).
Many non-real-time applications can benefit from it.

NTP guarantees that all systems are within a few milliseconds of one another, which is sufficient for precise event ordering in many non-real-time use cases.

5. PTP

With its sub-microsecond accuracy, PTP serves for high-precision time synchronization. It uses a master-slave architecture in which slave devices modify their local clocks in accordance with reference timestamps provided by designated time masters:

PTP Time Synchronisation

The network’s master clock is the authoritative time source and is frequently synchronized with atomic clocks or GPS. PTP slaves receive time signals from the master and update their clocks accordingly.

In Stratum 1, we see a boundary clock. These clocks are specialized network switches that distribute timing data downstream after processing and refining it. Transparent clocks modify timestamps while they are in transit to compensate for network delays and guarantee accuracy throughout hops.

PTP is extensively used in industries that demand a high degree of temporal precision, such as industrial automation, telecommunications, and financial trading.

5.1. Pros and Cons

The following table compares PTP pros and cons:

Pros	Cons
Sub-microsecond accuracy	Need specific hardware, such as switches that are aware of PTP
Supports synchronisation at the hardware level	More difficult to set up and manage than NTP
Perfect for applications that require quick responses	Ideal for controlled settings such as labs or data centres

To comply with requirements such as MiFID II, trades in financial markets must be timestamped within nanoseconds. PTP allows trading servers to precisely and deterministically synchronize their time.

6. NTP vs PTP

PTP is the preferred option when accuracy is crucial, although NTP works well for the majority of general-purpose distributed applications:

Feature	NTP	PTP
Accuracy	Between 1 to 50 milliseconds	Sub-microsecond
Hardware Dependency	No	Often yes
Use Case	General computing	Telecom, Finance, Industrial
Complexity	Low	Moderate to High

In contrast to NTP, PTP uses switches and network interface cards (NICs). NICs can timestamp packets in hardware, which lowers delay variability. In the power, telecom, and banking sectors, timing is in nanoseconds or microseconds, so PTP suits these sectors.

However, if milliseconds are adequate, NTP will be sufficient.

7. Clock Drift Compensation Algorithms

Clock drift compensation techniques aim to ensure nodes stay synchronized in distributed environments.

7.1. Linear Regression-Based Drift Correction

This method predicts clock offset trends using linear regression-based drift correction. Here, historical behavior is used to adjust the time offset.

We assume the offset is a linear function of time and increases at a constant rate $\boldsymbol{\alpha}$ :

$\Delta T(t) = \Delta T_0 + \alpha t$

where $\alpha$ represents the skew and can be computed using the least squares method, which yields:

$\alpha = \frac{\sum (t_i - \bar{t})(\Delta T_i - \overline{\Delta T})}{\sum (t_i - \bar{t})^2}$

Here, $t_i$ denotes the $i$ -th recorded time instance, $\Delta T_i$ is the corresponding time offset, $\bar{t}$ is the mean of all $t_i$ values, and $\overline{\Delta T}$ is the mean of all $\Delta T_i$ values.

The following figure shows a plot of clock drift and a linear regression-based drift-corrected plot: Linear Regression Based Drift Correction 1

The circles represent measured clock offsets at various timestamps. The dotted line shows the corrected time at any instant.

Here’s an example. Let’s assume that at time $t = 0$ , the observed offset between clocks A and B is 0 seconds. After 100 seconds, the offset increases to 2 seconds. At 200 seconds, the offset grows to 4 seconds, followed by 6 seconds at $t=300$ , and 8 seconds at $t=400$ .

After computing the mean values of $\bar{t}=200$ and $\overline{\Delta T} =4$ , we calculate $\alpha$ :

$\alpha = \frac{\sum (t_i - \bar{t})(\Delta T_i - \overline{\Delta T})}{\sum (t_i - \bar{t})^2}$

$\alpha = \frac{(0 - 200)(0 - 4) + (100 - 200)(2 - 4) + \ldots + (400 - 200)(8 - 4)}{(0 - 200)^2 + (100 - 200)^2 + \ldots+ (400 - 200)^2}$

$\alpha = \frac{800 + 200 + 0 + 200 + 800}{40000} = \frac{2000}{40000} = 0.05$

The computed skew $\boldsymbol{\alpha}$ is 0.05, meaning that every second, A gets ahead of B by an additional 0.05 seconds. Thus, after 500 seconds, the total drift will be:

$\Delta T(500) = \Delta T_0 + \alpha \times 500 = 0 + 0.05 \times 500 = 25$

To synchronize the clocks at any moment, we subtract the calculated offset from the B’s timestamp at that moment (or add it to the corresponding timestamp of A).

The offset will grow linearly without correction, leading to significant mismatches in time-sensitive applications.

This method performs best with steady, gradual drift patterns where linear models are adequate and is frequently applied in log synchronization and distributed databases.

7.2. Kalman Filter for Drift Estimation

Kalman Filter uses statistical modelling and dynamically corrects drift. It adjusts for measurement noise and changes in clock speeds, which is why it’s suitable for high-precision synchronization settings.

It assumes that system dynamics and drift variations can be modeled probabilistically, that the noise has a Gaussian distribution, and frequent updates use iterative refinements to increase accuracy.

This method is widely used in GPS-based time synchronization, where atmospheric delays necessitate constant calibration of satellite clocks.

Let’s assume a GPS receiver compares its local clock to the satellite’s transmitted timestamps. The Kalman Filter predicts the drift trend and applies corrective adjustments based on the following equation:

$T_{\text{corrected}} = T_{\text{measured}} + K \left( T_{\text{predicted}} - T_{\text{measured}} \right)$

Here, $K$ is the Kalman gain, which determines how much correction is applied based on noise estimates. This iterative improvement in synchronization ensures accurate positioning and timestamping in navigation systems.

7.3. Adaptive Drift Correction

This technique maintains synchronization in extremely variable environments by dynamically modifying the clock synchronization model in response to changes in real-time offset. The adaptive correction mechanism tracks real-time clock metrics and makes adjustments when observed offset behavior deviates from expected trends.

A constant model can’t accurately capture the offset pattern’s dynamics in these environments because it unpredictably changes over time. Therefore, to maintain accuracy, the correction model needs to be re-fitted or entirely changed whenever significant changes take place.

Depending on the type of offset behavior, the correction model can be anything from neural networks to Kalman filtering to linear regression. For example, if a linear regression-based correction begins to fail because of nonlinear offset variations, the system may adjust by adding a neural network that better captures intricate changes.

In contrast, the Kalman Filter uses probabilistic modeling of clock offset trends.

Adaptive correction is crucial for autonomous vehicle networks because external conditions can change quickly, so it’s crucial to have synchronized sensor data for just-in-time decision-making.

7.4. Comparing Drift Correction Methods

Let’s compare these three methods:

Method	Mechanism	Best Use Case	Key Assumptions
Linear Regression-Based Drift Correction	Predicts clock drift trends using historical data and applies continuous corrections	Log synchronization, distributed databases, blockchain validation	Offset follows a steady, linear pattern over time
Kalman Filter	Probabilistic drift modeling	GPS synchronization, financial trading	Measurement noise follows a Gaussian distribution; offset trends are structured and predictable
Adaptive Drift Correction	Real-time clock modification	Cloud-based systems, autonomous vehicles	Offset behavior is unpredictable; continuous monitoring ensures timely recalibration

The kind of offset behavior determines the best approach, such as whether it requires real-time flexibility (adaptive drift correction) or follows a predictable pattern (linear regression, Kalman filters). In situations where physical synchronization is not feasible, we can use logical clocks.

8. Logical Clocks

Unlike traditional clocks that record actual time, logical clocks provide a relative ordering of events within a system.

Logical clock types include:

Lamport clocks, which are straightforward counters that increase with each event to guarantee a consistent order of events
Vector clocks, which track the causality between various processes and help systems to identify which events are dependent or concurrent

Logical clocks can support event consistency in PTP when physical time synchronization is unreliable or impractical. For instance, we can use them to track transaction order in distributed databases where system nodes may encounter variable delays.

9. Synchronization Tools

Several tools and protocols make time synchronization in distributed systems easier, such as Chrony, a lightweight and flexible Linux NTP implementation perfect for managing network latency.

Further, Linux-based systemd-timesyncd implements SNTP (Simple Network Time Protocol), making it suitable for basic timekeeping needs without the complexity of full NTP configurations.

There is also the TrueTime API, created by Google, that gives distributed cloud apps globally synchronized timestamps.

10. Conclusion

In this article, we discussed the importance of clock synchronisation in distributed systems. At any moment, the skew is the difference in tick rates, and the offset is the difference in timestamps.

Clock synchronization is essential for consistent distributed systems, as unsynchronized clocks impact the accuracy of real-time sensor data, log correlation, and transaction ordering.

The post Clock Offset vs Clock Skew in Distributed Networks first appeared on Baeldung on Computer Science.