Coverage over an area, not a link budget along one path — and it comes back while the question is still open. Raise the mast, move the site 200 m, sweep the band: the map returns inside your working loop, not after a batch job. The same model your regulator recognises, measured against the published NTIA/ITS reference on real terrain — never against a strawman of our own.
Drag to orbit. The first demo is the one everybody asks for — how fast. The other two are the ones that matter: they are not possible at all when a single coverage map takes the best part of a minute.
Same computation, same instant, both engines. The map is finished while the grey reference sweep is still leaving the starting line.
The baseline is the NTIA/ITS reference implementation — public source, not ours — so the ratio is one you can reproduce without trusting anything we wrote.
5.95 million receiver points across 60×60 km of SRTM terrain, one transmitter at 800 MHz — full ITM, terrain profiles included.
Terrain preparation is 41 ms of that first 92, and it is paid once. Every further frequency, mast height or reliability quantile over the same ground costs three video frames.
Worst of sixteen probes against the reference on 108 m of relief, driven point-to-point on the engine's own terrain profile. Median 0.01 dB; 0.06 dB on smooth ground.
| Same grid: 0.6°, 5.95 M points, 800 MHz, SRTM1 30 m | Time | vs GPU |
|---|---|---|
| BALROG GPU — GeForce RTX 3060, full pipeline | 92 ms | — |
| BALROG GPU — further scenario on the same terrain | 51 ms | — |
| NTIA reference implementation, sharded over 6 cores | 11.4 s | ×124 |
| NTIA reference implementation, 1 core — the published ITM code | 55 s | ×598 |
| For reference: BALROG GPU on a Tesla P100 (2016) | 522 ms | — |
One machine, one afternoon. Every figure above the P100 row was measured on
4 August 2026 on the same desktop — a GeForce RTX 3060 against the six-core i5-8600K beside
it, same terrain tile, same 0.6° domain, same transmitter. Both sides are medians of repeated
runs at verified clock, and both are compute time. The baseline is the ITM code the FCC's
OET-69 procedure rests on, compiled -O3 -march=native and handed its terrain
profiles pre-built — so what is timed is its arithmetic, not its file handling. Sharding it
across all six cores is the best a user could do with it; ×124 is the number that survives
that objection. The 2016 Tesla P100 row is there only to show that a €300 consumer card now
does in 92 ms what a datacentre card did in 522.
Speed is worth nothing if the answer is wrong, which is why the same reference that
sets the baseline also checks the result — the agreement figures above. One caveat on
scaling: cost grows as points1.2, not linearly, so figures for other domain sizes
must be scaled rather than interpolated.
The evaluation repeats every comparison on this page using your terrain, your machine, and whatever tool you already trust. We never ask you to benchmark us against a CPU version of ourselves: a ratio is only worth something when you control both ends of it.
The engine for Linux x86-64 and Windows x64, the container image, nine SRTM1 tiles covering Europe, North America and Asia, and the five parameter files already filled in for a working scenario. SHA-256 published for every archive.
One Ed25519-signed licence file, tied to your organisation and an expiry date, verified by the engine offline. No activation server, no callback, no network access at any point — which is what makes it usable behind an air gap.
Nothing is metered and nothing is reported back. The evaluation engine is the production engine with an expiry date and a watermark on its output — the attenuation figures themselves are untouched, so every number you measure is a number you can hold us to.
Your organisation already has the maps, the terrain library and the people. BALROG supplies the computation. It ships as a single binary and a container image, driven by plain-text parameter files, so it drops into an existing pipeline without a framework, a runtime or a network call.
Linux x86-64 and Windows x64, statically linked against the CUDA runtime. No installer, no service, no telemetry. Copy it onto the machine that has the GPU.
The same engine on the NVIDIA CUDA runtime base, for orchestrated and air-gapped estates. Image digest published with every release.
Five parameter files in, an attenuation grid out. Readable, diffable, scriptable, and reviewable by whoever has to approve what runs on your network.
SRTM1 and SRTM3, as raw .hgt or ESRI ASCII grids. Multiple local domains, multiple transmitters and multiple frequencies in a single run.
Every ITM parameter is yours to set — surface refractivity, ground permittivity and conductivity, polarisation, radio climate, the reliability and confidence quantiles, mast and receiver heights. Nothing is hidden behind a default you cannot see or change. Out comes a path-attenuation grid in dB, centred on the transmitter or resampled to your own geographic grid, at whatever resolution your GIS layer, tile server or mission planner wants.
Per developer, per product, or per site — priced so the decision is about the engine and not about the paperwork.
One person reads these. Say what terrain, what frequency band and what you are comparing against, and the reply will be about your case rather than about our page.