Ask five people what time it is.
In a room, you ask five people for the time. Nobody says "10:00 sharp": one says "about 10, maybe a bit earlier", another "just after 10". Each answer is really an interval.
Line the intervals up and a stretch appears where everyone agrees. That is the time you can prove. And if a sixth person says "noon", they fit no overlap at all: they are left out, and you know exactly who got it wrong.
Now imagine the rule demands the time to within one minute, and the shared stretch is four minutes wide. You can say neither that you are right nor that you are wrong. The honest answer is "cannot tell". That is what PLUMB does with computer clocks.
There and back, and half the trip.
To set its clock, a computer asks a server for the time over the internet. The question goes out, the server notes its time and the answer comes back. The catch: you cannot know how long the trip out took and how long the trip back took.
PLUMB does not pretend to know. It computes the interval where the true instant must lie: half the round trip, plus the uncertainty the server itself declares. It does this with several independent servers and keeps the stretch where most of them agree. A server that disagrees is left out, with proof that it disagreed.
Finally, it compares the interval with the yardstick (for example, ±100 µs under the European rule for high-frequency trading) and returns one of three verdicts: proven inside, proven outside or cannot tell.
A real laptop, 43 hours, 1,728 queries.
We measured the clock of an ordinary Mac, one query per minute, against five servers. At first the clock ran fast by 135.9 parts per million, about 11.7 seconds a day. The first measurement already showed the machine ~60 ms off official time, and the worst divergence reached 575 ms, 5,756 times the yardstick.
Then we installed a clock-tuning program (chrony). With the machine awake, the typical offset dropped from 27.75 ms to 1.90 ms, about 13 times better, and readings proven outside the yardstick dropped from 59.8% to zero.
Even so, the verdict stayed non-compliant, and PLUMB explained why. Over Wi-Fi, the measurement uncertainty never drops below ±12 ms, 120 times wider than the yardstick: the clock may well be good, but it cannot be proven. And every reading proven outside after tuning came right after the machine woke from sleep.
The tuning program reported itself as 140 µs off. That is the actor speaking about itself through a single path. PLUMB is the auditor: five independent sources, trusting none, and it can only prove ±12 ms. Keeping those roles apart is exactly the product.
| Measure | Before tuning (18.5 h) | After, awake (12.4 h) | After, whole period (24.4 h) |
|---|---|---|---|
| Median offset | 27.75 ms | 1.90 ms | 2.00 ms |
| Offset 95% of the time | 366.9 ms | 10.45 ms | 82.0 ms |
| Largest offset | 472.9 ms | 87.3 ms | 431.0 ms |
| Median measurement uncertainty | 12.70 ms | 12.18 ms | 12.18 ms |
| Proven outside the yardstick | 59.8% | 0% | 6.6% |
| Cannot tell | 40.2% | 100% | 93.4% |
| Proven inside the yardstick | 0% | 0% | 0% |
The same tool, on a machine with a precision clock (PTP, simulated with ~2 µs offset and ~8 µs uncertainty), returned compliant. And when we changed a report's verdict to "compliant", the verifier redid the math from the raw data and rejected it. The tool takes no sides.
When the time becomes evidence.
A good fit
- High-frequency trading: the European rule (MiFID II, RTS 25) requires proving the clock within ±100 µs of official time. PLUMB delivers the proof, or says honestly that it does not exist.
- Substations and grid measurement: the IEC 61850 standard asks for 1 µs. PLUMB attests whether the expensive gear delivers what it promises (see the synchrophasor case).
- Ordering events with proof: if two events' intervals do not overlap, the order is proven; if they overlap, the honest answer is "cannot tell".
- Forensics: tampered clocks, spoofed GPS, virtual machines losing the beat. A +473 ms jump was caught in the measurement.
Not enough on its own
- It does not replace timing hardware: over the ordinary internet, precision is in milliseconds. Proving microseconds needs a better path (hardware PTP or GPS; a low-cost Raspberry Pi with a GPS receiver is enough to start).
- Uneven paths: the math assumes the trip out and the trip back take similar times. An attacker in the middle can break that unseen by a single query.
The stretch where the true instant must lie, computed without trusting any single server.
The precision the rule requires: ±100 µs for high-frequency trading, 1 µs in substations.
When the interval is wider than the yardstick. It is not "wrong": it is "this measurement proves neither way".
Where this could be wrong.
The floor is the measurement
Over Wi-Fi, the uncertainty never drops below ~12 ms. PLUMB exposes the problem; fixing it needs a better measurement path.
Assumes similar trips
If the trip out takes much longer than the trip back, the interval may be shifted. Several independent sources lower the risk, but do not remove it.
One measured laptop
The long measurement was on an ordinary Mac. The precision-clock scenario was simulated, not measured on real PTP hardware.
Servers that lie together
The vote catches one server that disagrees. If most of them lie the same way, the vote follows the majority.
← Certified telemetry · stickybit.com.br
- Our own measurement, 18–20 Jul 2026: time probe against five servers, one query per minute, ~43 h and 1,728 queries; chrony tuning from 19 Jul, 15:47 UTC.
- MiFID II / RTS 25 (European Union): maximum divergence of 100 µs from UTC for high-frequency trading. IEC 61850-9-2: 1 µs.
- Server voting with Marzullo's algorithm; interval from NTP's correctness invariant (RFC 5905).