Benchmarks
Measured, not modeled
Every number on this site comes from a real run, with encryption on and every transfer verified end to end. Here is what was measured, on what hardware, and how.
100 Gbps networking
Two Google Cloud n2-standard-80 VMs (80 vCPU, 100 Gbps networking) in one zone, October 2026. 100 GiB per
transfer, 16 parallel flows, AES-256-GCM on, BLAKE3-verified. Memory to memory: the receiver discards the data instead of
writing it, so this measures the network path, not the disks.
| Packet size | Sustained | 100 GiB end to end |
|---|---|---|
| Jumbo frames (MTU 8896): private links, VPCs, data centers | 91–94 Gbps | 76–78 Gbps · 11.0–11.3 s |
| Standard 1500-byte packets: internet-sized | 37–41 Gbps | 35–37 Gbps · 23.5–24.2 s |
"Sustained" is the steady transfer rate; "end to end" is the whole transfer, including connection setup and the ramp to full speed. Ranges cover repeated runs; sustained rates were measured on two different VM pairs. fft picks the largest packet size the path allows on its own.
10 Gbps, disk to disk
Two Google Cloud n2-standard-16 VMs with local NVMe SSDs and the link capped at 10 Gbps, October 2026.
One 100 GB file of real data, read from SSD and written to SSD, encrypted and verified.
| Packet size | Goodput, disk to disk | CPU per side |
|---|---|---|
| Jumbo frames | 9.76 Gbps · 98% of the link · 100 GB in 88 s | ~1.9 of 16 cores |
| Standard 1500-byte packets | 8.95 Gbps | ~1.9 of 16 cores |
Long, lossy paths
The same VMs, with WAN conditions emulated by Linux tc netem: delay split between both directions, loss on the
data direction. Standard 1500-byte packets, 16 flows, AES-256-GCM on, memory to memory. 50 GiB per transfer (5 GiB and
2 GiB on the rate-limited paths); every transfer verified end to end.
| Network condition | Falcon fft goodput | Retransmitted | What it represents |
|---|---|---|---|
| 100 ms RTT, 1% packet loss | 33–40 Gbps | 1.2% | A typical intercontinental path with loss |
| 300 ms RTT, 2% packet loss | 17.0–18.5 Gbps | 2.7–2.9% | Satellite or very long haul |
| 100 ms RTT, 1 Gbps bottleneck | 0.90 Gbps | 0.01% | ~94% of the link after packet headers |
| 500 Mbps link, 80 ms RTT, 10% loss | 0.39–0.40 Gbps | 11.2% | Heavy random loss; near the ~0.45 Gbps the link carries after loss |
| NAT to NAT, no open ports* | 14.9 Gbps | 2.8% | 93% of a direct connection on the same VMs (15.9 Gbps); both CPU-limited on 8 vCPUs |
| 100 GiB disk to disk, 100 ms, 1% loss* | 3.24 Gbps | 1.0% | 4 min 25 s; limited by the VM's SSD (~410 MB/s) |
*Earlier runs on two c3-standard-8 VMs (8 vCPU, ~23 Gbps network), 10 GiB unless noted.
Against TCP on the same paths
TCP measured with iperf3 on the same VMs and packet size, 8 parallel streams and no encryption, so the
conditions favored TCP. Falcon fft was encrypted.
| Path | Falcon fft | Default TCP (CUBIC) | Tuned TCP BBR ×8 |
|---|---|---|---|
| 100 ms RTT, 1% loss | 33–40 Gbps | 0.024–0.034 Gbps | 17.7–19.8 Gbps |
| 300 ms RTT, 2% loss | 17.0–18.5 Gbps | 0.007 Gbps | 4.9–5.0 Gbps |
| 100 ms RTT, 1 Gbps bottleneck | 0.90 Gbps | 0.92 Gbps | 0.91 Gbps |
| 500 Mbps, 80 ms RTT, 10% loss | 0.39–0.40 Gbps | 0.004 Gbps | 0.44–0.45 Gbps |
Default TCP is what most file tools use. Against it, fft is about 1,000× faster at 100 ms / 1% loss and 2,500× faster at 300 ms / 2% loss. Against hand-tuned multi-stream BBR, which needs kernel changes on both ends, fft is 2× faster at 100 ms / 1% and 3.5× at 300 ms / 2%. It matches BBR at a bandwidth bottleneck and at 10% random loss, and BBR with 8 unencrypted streams can be faster on a clean, short path.
Light on the machine
From the 100 Gbps runs above, plus a Windows receiver test.
| Metric | Sender | Receiver |
|---|---|---|
| CPU at 76 Gbps, encrypted | ~13 of 80 vCPUs | ~7 of 80 vCPUs (decrypt and verify included) |
| Peak memory | ~155 MB | 20–300 MB |
| Memory for a 100 GiB transfer | Flat, bounded | ~310 MB, flat throughout |
| Packets dropped by the receiving NIC | n/a | 0 in every run |
| Windows Server 2022 receiver | n/a | 5.2–7.6 Gbps, ≤222 MB, 0 NIC discards |
Methodology
- Harness: every cloud result comes from the fft test harness, which creates a Spot VM pair in one zone, runs the transfers, records CPU time, peak memory and NIC packet counters on both ends, and tears the pair down.
- Goodput is file bytes delivered per second during the data phase, excluding connection setup (a few round trips). The 100 Gbps table reports both the sustained rate and the end-to-end rate including setup.
- Retransmitted counts repeated and redundant packets as a share of the file's packets.
- Emulated loss drops packets in bursts for both fft and TCP. Real paths differ, which is why we set up trials on your own network.
- Raw data is available on request.
What limits speed in practice
- Storage. Above a few Gbps, the disks at either end usually set the ceiling. One cloud SSD writes about 410 MB/s, or 3.3 Gbps. fft runs at whatever the storage can sustain.
- NAT to NAT. Above ~10 Gbps, NAT-to-NAT transfers benefit from several punched paths, which add a few seconds of setup.
- Strict NATs. Some carrier-grade and enterprise firewalls (symmetric NATs) can't be traversed peer to peer yet. Run one side on a reachable host, such as a cloud VM or DMZ server, and connect directly.
Falcon fft and Makai Systems: not in the path
No middleman. We never see your data.
Every transfer goes peer to peer, straight from one machine to the other, encrypted with keys that exist only on those two machines. There is no Falcon cloud, relay or storage in between, so neither Falcon fft nor Makai Systems ever sees your files, their names, or who you send them to.
Try it on your own network
Falcon fft is in early access. Leave your email and we'll set up a trial on your own links.