This page explains how time is synchronized from a grandmaster clock to a slave device over Automotive/TSN Ethernet using gPTP (generalized Precision Time Protocol, IEEE 802.1AS) and how the STBM (Synchronized Time-Base Manager) in AUTOSAR consumes that time. It walks through every timestamp and every configuration option exposed by the simulator: 1-step vs 2-step, hardware vs software timestamping, and with vs without the Pdelay handshake — each with worked numeric examples.
1. Roles & the big picture
A time-synchronized network has one authoritative clock and one or more devices that follow it:
- Grandmaster / Domain Master — owns the reference time for the domain. Every other clock steers itself toward the master. Selected by the Best Master Clock Algorithm (BMCA); in the simulator the master is fixed as the grandmaster.
- Slave — a device (e.g. an ECU) whose local oscillator drifts and must be continuously corrected to match the master.
- gPTP (IEEE 802.1AS) — the profile of IEEE 1588 PTP used in automotive/TSN. It defines the Sync, Follow_Up and Pdelay messages that carry the timestamps used to compute the offset.
- STBM (Synchronized Time-Base Manager) — an AUTOSAR software module. It takes the corrected gPTP time, maintains one or more synchronized time bases, applies plausibility checks, handles holdover, and notifies applications of time jumps (timeLeap).
Two independent measurements combine to synchronize the slave:
- Offset measurement (Sync / Follow_Up): "How far ahead/behind the master am I right now?"
- Path-delay measurement (Pdelay handshake): "How long does a frame take to travel the cable between us?"
The path delay is subtracted from the offset measurement because the Sync message itself takes time to arrive — without removing it, the slave would always think it is late by exactly the propagation delay.
2. Terminology — every symbol used
3. The core offset calculation
All of gPTP boils down to one equation the slave evaluates every Sync interval. Given the four quantities above:
offsetFromMaster = t₂ − t₁ − δ − cIntuition, term by term:
t₂ − t₁— the apparent transit: slave-receive time minus master-send time. If the two clocks agreed perfectly this would equal just the wire delay.− δ— remove the wire propagation delay (the Sync was "old" by δ when it arrived).− c— remove residence/bridge delays that the network added to the frame.
Whatever is left is the genuine clock error. The slave then corrects itself:
slaveClock := slaveClock − offsetFromMasterA positive offset means the slave is ahead of the master, so it steps its clock back; a negative offset means it is behind, so it steps forward.
4. Peer path delay (the Pdelay handshake)
To measure δ, the slave and master exchange a small four-timestamp handshake. Note these t₁…t₄ are a different set from the Sync t₁/t₂ above — they belong only to the Pdelay exchange:
The one-way delay is the round trip minus the master's turnaround time, halved:
δ = ((t₄ − t₁) − (t₃ − t₂)) / 2(t₄ − t₁)is the total round-trip time as seen by the slave clock.(t₃ − t₂)is the time the request "sat" inside the master (its turnaround).- Subtracting removes the processing time, leaving pure cable time; dividing by two gives one direction.
Example — measuring δ
5. One-step vs two-step timestamping
The master must place its exact transmit time (t₁) into the message. But at the instant the hardware starts sending the Sync, it does not yet know the final egress timestamp. There are two ways to solve this:
| Aspect | 2-step | 1-step |
|---|---|---|
| Messages | Sync then Follow_Up | Sync only |
| Where t₁ & c live | In the Follow_Up, measured precisely at Sync egress | Inserted into the Sync frame on the fly by hardware |
| HW requirement | Lower — just needs an egress timestamp readback | Higher — MAC must rewrite the frame & fix the FCS at line rate |
| Latency to result | Slightly higher (waits for the 2nd message) | Lower (everything in one frame) |
| In the simulator | Sync reveals t₁ & t₂; Follow_Up reveals c & Δp, then the offset is computed | Sync alone reveals t₁, t₂, c & Δp |
6. Hardware vs software timestamping
The accuracy of t₂ (Sync ingress) depends entirely on where the timestamp is captured in the receive path:
| Aspect | HW timestamping | SW timestamping |
|---|---|---|
| Capture point | In the MAC/PHY at the exact moment the frame crosses the wire | In the driver/stack when software gets around to reading the frame |
| Effect of poll delay Δp | None on the value — Δp only delays when STBM is updated, not the timestamp itself | Leaks directly into t₂ as error + jitter |
| Offset equation | t₂ − t₁ − δ − c | t₂ − t₁ − δ − c where t₂ is inflated by Δp → error ≈ Δp |
| Typical accuracy | Sub-microsecond | Tens of µs to milliseconds, jittery |
In the simulator, the RX processing path is drawn as the dashed Δp leg from the SLAVE PORT to the STBM calc point. With HW timestamping, t₂ is latched at the port (start of that leg) so Δp is harmless. With SW timestamping, t₂ is effectively taken at the end of the leg, so the whole Δp is added into the measured offset as error:
SW: offset = t₂ − t₁ − δ − c − Δp (Δp is a correction the slave tries — but Δp is variable, so residual error & jitter remain)7. With vs without Pdelay
Pdelay is what supplies δ. What happens if it is disabled?
| Aspect | Pdelay ON | Pdelay OFF |
|---|---|---|
| δ source | Measured continuously from the 4-timestamp handshake | Assumed 0 (or a static configured value) |
| Offset equation | t₂ − t₁ − δ − c | t₂ − t₁ − c (δ term dropped) |
| Residual error | ≈ 0 from path delay | The entire link propagation delay stays uncompensated — the slave is offset by δ permanently |
| When acceptable | Always the correct choice for accuracy | Only for very short links where δ is negligible, or lab/demo setups |
8. What the STBM does with the corrected time
gPTP produces a corrected time; the STBM turns it into a robust, application-facing synchronized time base. Its jobs:
- Rate + offset correction — applies the gPTP offset to the local time base.
- Plausibility check — a new sync is only accepted if the implied jump is within a plausibility window (in the simulator, 6.25% of the time since the last valid sync). Wild values are rejected to reject glitches/attacks.
- Holdover — if syncs stop arriving or keep failing the check, the STBM keeps running on its own oscillator (flywheel) rather than following bad data. After a sync-loss timeout it drops to UNSYNCHRONIZED and adopts the next Sync unconditionally.
- timeLeap notification — if an accepted correction is large enough to be a discontinuity (≥ configured threshold), the STBM raises a timeLeap flag so applications can react to the jump (forward or backward).
9. Phase vs frequency correction — the servo & rateRatio
Correcting a clock has two independent parts. Getting the slave to read the same value as the master is phase correction (synchronization). Getting the slave to tick at the same rate as the master is frequency correction (syntonization). A naïve implementation only does the first; a real gPTP/STBM stack does both.
Why phase-only correction produces a sawtooth
If the slave oscillator is, say, 2000 ppm slow, it loses 2 µs of time every millisecond. A phase-only servo waits for each Sync, computes the offset, and hard-steps the clock back onto the master — then does nothing until the next Sync, during which the clock drifts away again at the full 2000 ppm. The result is the familiar sawtooth: snap to zero, drift, snap, drift. The average error is non-zero and every correction is a small discontinuity.
What the frequency servo does instead
A frequency (PI) servo does not jump the clock. From each Sync it estimates the residual rate error and adjusts the speed at which the slave clock advances — a correction expressed in ppm (rateCorr). Once it has learned the oscillator's drift, that steady rate correction cancels the drift, so between syncs the slave stays aligned instead of running away. The deviation curve collapses from a sawtooth into a flat, converging line.
The servo used here is a classic proportional-integral (PI) controller:
- the proportional term reacts to the current error e (the implied ppm needed to null this sync's offset over one sync interval);
- the integral term accumulates past error and settles to exactly the value that cancels the constant oscillator drift — this is what lets the steady-state error reach zero;
- the output is clamped to a sane ppm range so a bad measurement can't fling the clock.
rateRatio — measuring the frequency ratio
To correct the rate you first have to measure it. rateRatio (called neighborRateRatio in 802.1AS) is the ratio of master frequency to slave frequency. It is measured from two consecutive Sync exchanges by comparing how much master time elapsed with how much the slave's own hardware clock advanced:
- the numerator is the master interval carried in the Sync/Follow_Up timestamps;
- the denominator is the slave's local hardware interval — deliberately taken at HW ingress so it is independent of any software phase step already applied;
- rateRatio > 1 ⇒ the slave clock advanced less than the master ⇒ the slave is running slow and must speed up.
In a real multi-hop network every bridge measures the rateRatio of its upstream link and passes an accumulated ratio downstream, so each device can scale the correctionField and residence times into its own timescale. In this single-hop simulator the measured rateRatio feeds the servo and is shown live in the rateRatio tile alongside the current rateCorr (ppm) and the acquiring/LOCKED state.
How this maps to AUTOSAR StbMTimeCorrection
In a real AUTOSAR stack the phase-vs-frequency choice is not a single toggle — it is configured through the
StbMTimeCorrection container on a synchronized (slave) time base. That container exposes the same
two mechanisms this simulator models, just with more granularity:
| Mechanism | In this simulator | AUTOSAR StbMTimeCorrection parameters |
|---|---|---|
| Phase (offset) | Applied as an immediate hard step every sync. A step ≥ the STBM time-leap threshold raises timeLeap. |
StbMOffsetCorrectionJumpThreshold (jump vs ramp boundary) and StbMOffsetCorrectionAdaptationInterval (window over which a sub-threshold offset is ramped in smoothly instead of jumped). |
| Frequency (rate) | A continuous PI servo estimates the residual rate error and outputs rateCorr (ppm). |
StbMRateCorrectionMeasurementDuration (window used to measure drift) and StbMRateCorrectionsPerMeasurementDuration (how many samples per window). |
| Master rate (gateway) | Not modelled — single master → single slave. | StbMAllowMasterRateCorrection and StbMMasterRateDeviationMax — only for a time gateway (slave upstream, master downstream) that corrects its own rate before forwarding time. |
StbMTimeCorrection. Two deliberate
simplifications: (1) real STBM rate correction is a windowed measurement average recomputed each
MeasurementDuration, not a continuous PI loop; and (2) real offset correction is
threshold-gated — small errors ramp over the adaptation interval (smooth, monotonic) while only
large ones jump — whereas the simulator always applies phase as a hard step and flags large steps as
timeLeap.
10. The epoch value — is a non-zero epoch a convention?
The simulator's Epoch field is essentially cosmetic, but it mirrors something real about how PTP time is represented. Real PTP time is never zero-based from "simulation start" — the timestamps are seconds/nanoseconds since a defined epoch, and that epoch is a large fixed point in the past.
Standard epochs
preciseOriginTimestamp, though 802.1AS is often used as an arbitrary / relative timescale where the master just counts from power-on.Why a non-zero epoch matters
- Realistic magnitude / wraparound testing. PTP seconds are a 48-bit field and nanoseconds a 32-bit field. Today's TAI value is ~1.77 × 10⁹ seconds since 1970. Using a large epoch exercises the same high-order bits and 32-bit millisecond wrap that a real device sees, instead of tiny near-zero numbers that never stress rollover.
- It's what the wire actually carries. A grandmaster transmits absolute timestamps, not "ms since boot." A large value makes the display honest.
- Cosmetic only for accuracy. Epoch just shifts the absolute display; it does not change offsets, δ, or accuracy — those are all differences, so the epoch cancels out.
Typical non-zero value
To look like a real automotive/PTP clock, use current TAI seconds since 1970, in the simulator's millisecond unit:
- Seconds since 1970 (TAI) ≈ 1.77 × 10⁹ s (mid-2026).
- In milliseconds that is ≈ 1.77 × 10¹² ms (e.g.
1771000000000).
Other realistic choices:
- Power-on relative (802.1AS arbitrary) — start at
0or a small value; common for master-relative time bases where absolute wall-clock time is not needed. - A "nice" large demo value — e.g.
1000000ms (~16.7 min), just to show the clock isn't zero without being unwieldy.
11. Full worked example (2-step, HW, Pdelay on)
Given
Sync exchange
Compute offset
Correct
Now compare the same scenario with SW timestamping and a poll delay Δp = 0.250 ms:
SW timestamping — t₂ is taken 0.250 ms late
And the same scenario with Pdelay off (δ dropped):
Pdelay off — δ assumed 0
12. Cheat sheet
Offset (Sync): offset = t₂ − t₁ − δ − c Path delay: δ = ((t₄ − t₁) − (t₃ − t₂)) / 2 Phase corr.: slaveClock := slaveClock − offset (hard step) rateRatio: r = (t₁ − t₁ₚᵣₑᵥ) / (t₂ₕw − t₂ₕwₚᵣₑᵥ) (>1 ⇒ slave slow) Freq. servo: rateCorr = −(Kₚ·e + Kᵢ·∫e) ppm (no step, converges)- 2-step: t₁ & c arrive in the Follow_Up → offset finalized on Follow_Up.
- 1-step: t₁ & c are inside the Sync → offset finalized on Sync.
- HW timestamp: t₂ latched at the port → Δp harmless.
- SW timestamp: t₂ taken after Δp → error + jitter ≈ Δp.
- Pdelay on: δ measured and removed → accurate.
- Pdelay off: δ = 0 → link delay uncompensated.
- Phase-only: hard-step each sync → sawtooth deviation.
- Phase + frequency: PI servo steers the rate → flat, LOCKED deviation.
13. Standards & references
The behavior modeled here is defined across IEEE timing standards and the AUTOSAR time-synchronization stack. The primary normative documents:
IEEE — gPTP & PTP
- IEEE 802.1AS-2020 — Timing and Synchronization for Time-Sensitive Applications (gPTP). Defines Sync, Follow_Up, and the peer-delay (Pdelay) mechanism, the one-step/two-step behavior, and the gPTP profile of PTP used in TSN/automotive. standards.ieee.org/ieee/802.1AS
- IEEE 1588-2019 — Precision Clock Synchronization Protocol for Networked Measurement and Control Systems (PTP v2.1). The base standard defining timestamps (t₁–t₄), correctionField, meanPathDelay, and the offset/delay equations. standards.ieee.org/ieee/1588
- IEEE 802.1AS-2011 — the original gPTP edition (superseded by the 2020 revision), still widely referenced in existing automotive designs.
AUTOSAR — Ethernet Time Synchronization & STBM
- AUTOSAR SWS Synchronized Time-Base Manager (StbM) — Specification of Synchronized Time-Base Manager. Defines the synchronized time bases, rate/offset correction, time leap detection and thresholds, timeout/holdover handling, and the customer/OS notification interfaces modeled on this page. AUTOSAR_SWS_SynchronizedTimeBaseManager.pdf
- AUTOSAR SWS Time Synchronization over Ethernet (EthTSyn) — Specification of Time Synchronization over Ethernet. The AUTOSAR realization of gPTP: Sync/Follow_Up/Pdelay message handling, one/two-step, hardware vs software timestamping via the Ethernet driver, and correctionField processing. AUTOSAR_SWS_TimeSyncOverEthernet.pdf
- AUTOSAR PRS Time Synchronization Protocol — Protocol Requirements Specification: Time Sync Protocol. The on-the-wire protocol (message formats, sub-TLVs, status/user-data) shared by EthTSyn/CanTSyn/FrTSyn. AUTOSAR_PRS_TimeSyncProtocol.pdf
- AUTOSAR SWS Ethernet Driver (Eth) —
Specification of Ethernet Driver. Defines the hardware egress/ingress timestamping API
(
Eth_EnableEgressTimeStamp/Eth_GetIngressTimeStamp) that makes MAC-level (HW) timestamping possible. AUTOSAR_SWS_EthernetDriver.pdf - AUTOSAR EB / RS Time Synchronization — Requirements on Time Synchronization. Higher-level requirements tying StbM, EthTSyn, and the bus-specific TSyn modules together. AUTOSAR_RS_TimeSync.pdf
Supporting / background
- IEEE 802.1AS timing model — background on residence time, transparent clocks, and correctionField accumulation across bridges.
- TAI & the PTP epoch — the 1 January 1970 TAI epoch and the TAI−UTC offset (37 s as of 2026) referenced in §9. International Atomic Time (TAI)
- IEEE 802.1Q (TSN) — the broader Time-Sensitive Networking framework that 802.1AS provides the time base for.