Not a faster machine — a different algorithm. The parallelisation method
behind that factor is filed with the INPI, France's patent office.
What the factor buys, concretely: move the mast. Sweep the band. Stack ten altitudes.
The map comes back before you let go of the mouse.
Drag to orbit. The first is the question everyone asks. The other three are the ones that change what you can sell.
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.
Same 5.95 million receiver points, same SRTM terrain, same transmitter at 800 MHz, against the published NTIA implementation on one core. Both were timed on one machine, so the ratio is a measurement, not a guess across hardware.
Spread across every physical core, which is the most the published code can be made to do. Even then it does not close the gap.
Worst of sixteen probes against that same reference on 108 m of relief, driven point-to-point on the engine's own terrain profile. Median 0.01 dB; 0.000 dB on smooth ground.
| Same grid: 0.6°, 5.95 M points, 800 MHz, SRTM1 30 m | Time | vs GPU |
|---|---|---|
| BALROG — one GPU, full pipeline | 92 ms | — |
| BALROG — every further scenario on the same terrain | 51 ms | — |
| NTIA reference implementation, sharded over 6 CPU cores | 11.4 s | 124× |
| NTIA reference implementation, 1 core — the published ITM code | 55 s | 598× |
Both sides run on one machine, same tile, same transmitter, and the reference is given every advantage: latest compiler flags, terrain profiles prepared in advance, so the clock covers the model and nothing else. One caveat for your own sizing — cost grows faster than the point count, so scale these figures rather than reading across. How it was measured →
One more measured number, for band sweeps: a further frequency over the same geometry reuses the terrain and irregularity stages and costs 2.6–6 % of the first — from the author's own run logs, five 300 km cases between 8 and 51.6 million points per frequency. Ten channels cost well under twice one.
One setting decides it. The terrain-irregularity parameter Δh is the engine's most expensive stage, and by default it is computed every eighth profile point and interpolated between. Turn that off and it is computed everywhere.
| Setting | vs the reference | Worst Δh error | Its worst contribution |
|---|---|---|---|
| Default — Δh every 8th point | 598× | 6.44 m | ~0.58 dB |
| Δh at every point, nothing approximated | 277× | 1.99 m | ~0.18 dB |
At maximum precision — every approximation off — the engine is still 277× the reference implementation. So this is a setting you choose on your terms, not a compromise made for you: both rows are far beyond what a CPU can reach, and there is nothing useful between them.
Run every comparison on this page yourself — your terrain, your hardware, your current tool. Both ends under your control.
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.
Need something for the technical review first? The validation & benchmark summary (3 pages, PDF) — no form, no email. Or the full validation note. And the benchmark's exact input files (terrain tile included) let you time the public CPU baseline before ever talking to us.
This market sells breadth: dozens of models, a global map library, a finished interface. We sell one thing, and you should know which you need before either of us spends a call finding out.
Longley-Rice ITM, nothing else, and no plans to change. If your work is governed by ITU-R P.1812, P.452 or P.528, look elsewhere.
No terrain library, no clutter, no buildings, no antenna patterns. You bring the terrain. If you have no geodata pipeline, a suite that bundles one serves you better.
It draws nothing. Out comes a path-attenuation grid in dB for your own map layer. Want a picture at the end of a command? Wrong product.
The computation, and proof it is right. The model your regulator names, matching the public reference to the decibel, in your own process, offline, nothing metered.
If one of the first three is a blocker for you, say so now and we will tell you straight — there are better tools for that job, and we would rather point you at one.
You have the maps, the terrain and the people. BALROG supplies the computation — inside your process. No account. No key to rotate. No host to reach. No quota. No second request to fetch the result you just computed.
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 — in memory, on the machine that computed it. 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.
Deliberately ruled out: activation servers and callbacks — the licence is one
Ed25519-signed file, verified offline. Rate limits, on our hardware or yours. Round-trips to
collect a result from someone else's host. Metering of any kind: we cannot see your runs,
your terrain or your results.
An integration you cannot take offline is not an integration. It is a dependency.
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.
The answers below are what we would say on a call. Where the answer is "no", it says so.
The card already in your rack, most likely. Any CUDA-capable NVIDIA GPU: T4 in a rugged 1U or a vehicle, L4 or A10G in a workstation, L40S in a datacentre. One card is enough — there is no cluster to build and no second machine to buy.
Headroom is wide in both directions: the same grid runs on a small T4 and on a datacentre L40S, and a workstation card does it in 92 ms. Compare classes without owning them in the live console. The binary is statically linked against the CUDA runtime — copy it onto the machine that has the card. No installer, no service.
No — it is Longley-Rice ITM and nothing else. That is the model the FCC's OET-69 procedure rests on, and the one we can check against a public reference implementation to the decibel.
And that will not change with a release. What was parallelised is the ITM algorithm itself — the method filed with the INPI is built around how this particular model walks terrain, not a wrapper that any propagation model drops into. Adding another one is new mathematics, not a feature on a roadmap.
So if your study has to be ITU-R P.528, P.1812 or ITWOM, this is not the engine for you — better to know now. If it is ITM, the model the FCC's procedure actually names, this is the fastest implementation of it in existence and it matches the reference to the decibel.
A licence is a plain-text file signed with Ed25519. The SDK ships only the public key; verification is a single offline signature check. There is no activation server, no callback and no network access at any point — which is what makes it usable behind an air gap or in a classified estate.
Licences can be node-locked to a machine fingerprint or floating. Expiry carries a configurable grace period (14 days by default) so a slow renewal never causes an outage. Evaluation licences are the production engine with an expiry date and a watermark on the output — the attenuation figures themselves are untouched, so every number you measure during an evaluation is a number you can hold us to.
Nothing is metered and nothing is reported back. We cannot see your runs, your terrain or your results.
It is shown to you before it is sent, it is used for your run, and it is deleted within 24 hours by a storage lifecycle rule — not by a script someone has to remember to run. Your computed results expire the same way, on the same clock, so download what you want to keep. The only thing held longer is the engine's own log when a run fails (seven days), because a fault is rarely looked at the day it happens.
The console is a convenience for evaluating, not the product. If your terrain cannot leave your building, that is precisely the case the on-premises engine and the offline licence exist for.
Domain 0.1° to 1.0° — a computation reads one SRTM tile, which is one degree on a side, so beyond that there is no relief left to read. Frequencies 20 MHz to 20 GHz, up to 8 per run. Up to 32 receiver altitudes (that is what builds a coverage volume), transmitter height 0.5 m to 3000 m, uploads up to 50 MB.
The engine itself is not limited this way: multiple local domains, multiple transmitters and multiple frequencies in one run, over as many tiles as you feed it. The console's limits exist so one visitor cannot rent the GPU for the day.
Against the NTIA/ITS reference implementation, on the engine's own terrain profile: 0.000 dB on smooth ground across sixteen distances with a 1000 m antenna, and 1.122 dB worst case on 108 m of relief, with fourteen of sixteen probes inside 0.2 dB and a median of −0.01 dB.
The two probes above 0.2 dB — +1.12 dB at 13.5 km, +0.40 dB at 4.5 km — both sit in the line-of-sight regime, where the model is most sensitive to the terrain-irregularity parameter Δh. Measured on the reference alone, that sensitivity is about 0.09 dB per metre of Δh across this distance range, so the two gaps correspond to Δh differing by roughly 4 m and 13 m on ground carrying 108 m of relief. Smooth ground cannot show this up, since that parameter is zero there — which is why the relief test is the one that matters.
Full validation note · three-page PDF for a technical review.
One setting, explicit and documented. The terrain-irregularity parameter Δh is the engine's most expensive stage; by default it is computed every eighth profile point and interpolated between, which is worth 598× the reference with a worst Δh error of 6.44 m. Compute it at every point instead and you get 277× with 1.99 m.
There is nothing useful between the two: it is a two-way choice, not a dial. The default is the faster one, and it is the setting every figure on this site was measured under — so what you see published is what you get out of the box.
Not linearly. Cost grows as points1.2, so doubling the receiver points costs about 2.3×, not 2×. Figures for other domain sizes must be scaled that way rather than interpolated.
The figure that matters more than the headline: of the first 92 ms, 41 ms is terrain preparation and it is paid once. Every further scenario over the same ground — another mast height, altitude or quantile — costs 51 ms. A further frequency is cheaper still, because it reuses the irregularity stage too: 2.6–6% of the first, from the author's own run logs.
Usually you would not want to replace it — you would want it to answer faster. BALROG is sold to be embedded: a single binary and a container image, five plain-text parameter files in, an attenuation grid in dB out, resampled to whatever geographic grid your GIS layer, tile server or mission planner already uses.
The cases where that is worth money are the ones a 55-second map forecloses: coverage as a volume of receiver altitudes rather than a footprint, coverage that follows a moving transmitter, or ITM placed inside an optimiser that evaluates thousands of candidate sites. See OEM terms.
The working notes behind the figures on this page — method, defects and corrections included. They are what we would send an engineer who asked "how do you know?"
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.