Summary

  • RIPE Atlas firmware 5130 says the preceding 5120 release reported half the round-trip time as the NTP clock offset. Offsets produced by 5120 are incorrect; the reported RTT is unaffected.
  • A cache-bypassed RIPE Atlas API snapshot on 31 August returned 2,721 probe records that were both Connected and on firmware 5120, against 2,350 on 5130 and 14,680 connected records overall.
  • Those 2,721 records are not 2,721 bad measurements or users. Yet raw NTP results already carry the fw, prb_id and timestamp needed to identify 5120 rows, so the product has a natural key for a machine-readable erratum.
  • The missing receipt should bind the bad field, unaffected fields, per-probe time bounds, exclusion or correction rule, superseding release and revision history. Firmware rollout and historic data correction are different controls.

The version remains present after the warning

At 03:12 UTC on 31 August, a public RIPE Atlas API query returned 2,721 probe records with two properties: status=1, which the response names Connected, and firmware_version=5120. A parallel query returned 2,350 connected records on 5130. The total connected population was 14,680.

The 5120 group was therefore about 18.5% of all connected probe records in that snapshot. It is a striking number, but not a failure count. The API does not say how many of those probes performed an NTP measurement, when each installed 5120, whether a host saw the release notice, or whether one organisation operates several probes. Live counts also move between requests. That is why “thousands” belongs in the headline and the exact 2,721 belongs beside a timestamp.

What the count does establish is narrower and operationally useful. More than two weeks after firmware 5130 was published, the version named in its NTP warning remained the reported software state of a substantial connected population. Code release, fleet migration and data repair had not collapsed into one event.

One attempted fix created a different wrong answer

The public chronology begins before either release.

RIPE NCC issue 130, opened on 11 July 2025, described an older problem in the Atlas NTP calculation. The four exchange timestamps were said to be correct, but the offset formula used them in the wrong order and returned the opposite sign relative to the NTP specification.

Firmware 5120, released on 29 October 2025, listed “Fix NTP offset calculations” among its changes. The release explicitly applied only to software probes. A same-day issue comment named the repair commit and marked the fault fixed.

That closure did not hold. On 23 July 2026, a RIPE NCC maintainer reopened the issue after testing for the next release, writing that the 5120 commit may not have fixed the problem and “may have made it worse”. The proposed replacement code calculated delay and offset directly from four 64-bit fixed-point timestamps using the RFC 5905 equations.

Firmware 5130, published on 12 August, supplied the decisive public boundary. It says the 5120 regression reported half the round-trip time instead of clock offset. It then states plainly that NTP offsets reported by 5120 are incorrect and that round-trip time is unaffected. The issue was closed against 5130 and commit 197b599a7faa811d97ebd273078be176842264bb.

This is not merely a longer description of the original sign error. The issue record describes an initial defect, an attempted correction and a regression with a different output. A correction notice must keep those states separate. Otherwise a downstream analyst may apply advice meant for the old sign defect to rows produced by the later half-RTT regression.

The raw row already carries the join key

RIPE Atlas is in a better position than many measurement platforms because its documented result format preserves the software version with the data.

The NTP result schema includes fw for firmware, prb_id for the source probe and a Unix timestamp. Inside each result are offset, rtt and the four NTP timestamps: origin, receive, transmit and final. A consumer who knows the 5130 warning can reject rows whose fw is 5120 without knowing the probe host's identity.

That fact changes the diagnosis. The evidence is not untraceable. Nor would it be accurate to say that every value in a 5120 NTP row is corrupt: RIPE NCC specifically preserves RTT as unaffected, and the older issue said the four timestamps were correct at that stage. The public record does not, however, authorise a universal arithmetic rewrite of every stored offset. Error rows, retry paths, architectures and individual upgrade times still require a bounded rule.

The conservative action available to a downstream user is exclusion. The stronger product action is a machine-readable erratum that a client can discover and join without reading a human release page first.

A release note is not yet a data-quality state

The checked release pages, issue, result-format documentation and probe API provide most of the ingredients, but they leave the consumer to assemble the correction contract.

A durable erratum should name a stable ID and revision; product and schema; firmware 5120; result[].offset as the affected field; RTT as unaffected; the selector using firmware, probe, result identity and timestamp; first and last affected bounds for each probe or result stream; the required action—exclude, recompute or replace; the superseding 5130 release and commit; notification channels; and a history of changed advice.

Those time bounds cannot simply be 29 October 2025 and 12 August 2026. The first is a release date, not proof that every software probe installed 5120 that day. The second is a replacement-release date, not proof that every probe left 5120 then. The 31 August API snapshot demonstrates exactly why per-probe or per-result bounds matter.

The rollout receipt should remain separate. It can report connected probe counts by firmware and capture time, perhaps with privacy-safe platform cohorts. It answers whether the fleet is moving. The erratum answers what a saved result means. A probe can migrate successfully while its old data remains unmarked; old data can be correctly excluded while the probe still runs 5120.

Preserve the row, add the status

Correction should not mean silently overwriting Atlas history. The raw result is evidence of what the probe emitted under a named software version. Reproducibility requires preserving it, then attaching a versioned quality state and providing an explicitly derived corrected or filtered view.

That approach also respects the distribution of control. RIPE NCC owns the result schema, release metadata and authoritative correction statement. Probe hosts control installation. Measurement owners decide what was scheduled and how outputs are used. Researchers, operators and archives decide whether to reprocess cached data. None of them can make the chain complete alone.

The 5130 release note is unusually candid and precise about the bad field. The public API supplies a denominator. The raw record supplies a join key. Turning those three strengths into one discoverable erratum would let the correction travel as far as the data does.

Sources