How the 92 ms was measured
A speed ratio is a claim about two things, and the interesting one is usually the denominator. Here is exactly what was timed, on what, with which flags — and the baseline figure that had to be corrected upward.
Measured 4–5 August 2026 · GeForce RTX 3060 against an i5-8600K in the same desktop
Both sides of every figure on this site come from one machine, in one sitting, on the same SRTM1 tile, the same 0.6° domain and the same transmitter. Nothing is scaled between machines or between years. The workload is 5 950 136 receiver points at 800 MHz — full ITM, terrain profiles included.
| Same grid, same tile, same transmitter | Time | vs GPU |
|---|---|---|
| BALROG — RTX 3060, full pipeline | 92 ms | — |
| BALROG — further scenario on the same terrain | 51 ms | — |
| NTIA reference, sharded over 6 cores | 11.4 s | 124× |
| NTIA reference, 1 core — the published ITM code | 55.0 s | 598× |
What is being timed on each side
The baseline is the NTIA/ITS reference implementation — public source, not
ours — compiled -O3 -march=native from the unmodified original,
and handed its terrain profiles pre-built. That last point matters: what is
timed is the model's arithmetic, not its file handling. Timing a reference
implementation's fscanf loop and calling the result a propagation
benchmark would inflate the ratio for free.
Sharding it across all six physical cores is the best a user could realistically do with it, and it is included for exactly that reason. 124× is the number that survives the obvious objection; 598× is the single-core figure the published code actually gives you. Sharding efficiency comes out at 4.8× on six cores, which is what one expects once memory traffic is shared.
The correction that ran against us
An earlier version of these figures quoted 38.9 s for the reference on one core. That measurement was taken on profiles 851 points long. The run it was being compared against uses profiles of 1 336 points — a Longley-Rice call costs more the longer its profile, so the reference was being timed on a smaller problem than the one it was credited with.
| NTIA reference, i5-8600K | Quoted before | Re-measured |
|---|---|---|
| One core | 38.9 s | 55.0 s (median of five) |
| Six cores, sharded | 7.1 s | 11.4 s |
| Ratio against 92 ms | 423× | 598× |
The error made the reference look faster than it is, and so made the engine look less far ahead than it is. That is the comfortable direction — which is exactly why it is worth publishing. An error nobody complains about is one that survives.
Anyone repeating this needs the same three things: the real profile length, the same
terrain, and -march=native. Dropping to -march=x86-64-v2 —
what a portable comparator has to use, since it runs on processors you do not know —
costs the reference about 15 %, in its disfavour.
The GPU side has its own trap: clocks
Consecutive runs of the same binary on the same data gave 126,
then 202, then 62, then 62 ms for one stage — bimodal, and unrelated to run order.
Recording clocks.sm before each launch explained it in one line:
| Clock before launch | Total | Δh stage |
|---|---|---|
| 210 MHz (idle) | 267.3 ms | 214.6 ms |
| 540 MHz | 113.7 ms | 62.9 ms |
| 1942 MHz (working clock) | 107–116 ms | 57–65 ms |
The card idles at 210 MHz, nine times below its working clock, and the first run after a pause spends its heaviest stage ramping rather than computing. The proof that this is what is being measured: at 210 MHz an old and a new engine report the same stage time to within 0.3 %, while at full clock one is twice the other.
The rule that came out of it, and that every figure here now follows: wake the card with one run, take the median of several, verify the clock, and never publish a first run. Both sides of any comparison in the same sitting.
A cross-check that nobody designed
When the engine first ran on rented hardware, a warm T4 returned 34.3 ms for 1 488 291 points — 23.0 ns per point. The RTX 3060 does 92 ms for 5 950 000, or 15.5 ns. The ratio between the two cards is 1.49; their published fp32 throughput ratio is 1.57.
Nothing is left unexplained by the silicon. That is the strongest single piece of evidence that the port is sound: the engine is limited by the hardware it runs on, not by anything clever or anything broken.
Two caveats we would rather state than be asked
- Cost does not scale linearly. It grows as points1.2, so figures for other domain sizes must be scaled, not interpolated. Doubling the points costs about 2.3×, not 2×.
- Terrain preparation is paid once. Of the first 92 ms, 41 ms is terrain. Every further frequency, mast height or reliability quantile over the same ground costs 51 ms — which is what makes coverage volumes and moving transmitters affordable at all, and it is the figure that matters more than the headline.
The point of publishing this
A benchmark you cannot reproduce is an advertisement. The baseline is public source, the tile is a standard SRTM1 tile, the parameters are five plain-text files, and the method is above. The 90-day evaluation exists so you can run it on your terrain, on your machine, against whatever tool you already trust — we never ask anyone to benchmark us against a CPU version of ourselves.