How WarpSend achieves 618× faster than FTP

618×. That’s how much faster WarpSend transferred 1,024 small files compared to FTP in our benchmark — US East to Frankfurt, real machines, real network conditions.

If that number sounds inflated, fair — most “Nx faster” marketing collapses the moment you ask “Nx faster than what, in what scenario.” So here’s the math, in full.

The test

Two machines. One in us-east-1, one in eu-central-1. Both on clean connections — no traffic shaping, no artificial caps. Two scenarios:

1. A single 1 GB file (the easy case)
2. 1,024 × 1 MB files (the hard case — same total bytes, very different protocol behaviour)

Same source, same destination, same network. Only the transfer engine changes.

Why TCP is the wrong tool for this distance

This is a long-fat network problem, and it’s textbook.

The round-trip time between us-east-1 and eu-central-1 is roughly 85 ms. TCP throughput on a single connection is capped by:

throughput ≤ window_size / RTT

That’s the Bandwidth-Delay Product ceiling. With a default 64 KB receive window and 85 ms RTT, you’re limited to about 750 KB/s — regardless of how much capacity the link actually has. On a 10 Gbps pipe, that’s 0.06% utilization. The other 99.94% is just sitting there.

You can fight this on the kernel side. Larger receive buffers, window scaling, BBR instead of CUBIC, SACK, TCP offload. All real, all helpful, all complicated, all per-host. And BBR — the congestion control algorithm everyone reaches for — degrades as RTT grows. It’s not a silver bullet across continents.

Even with everything tuned, a single TCP stream typically struggles to exceed 20% utilization on a long-haul link before you start fighting routing fairness. That’s the ceiling FTP, SFTP, and rsync all sit under.

The small-file problem makes it worse

The 618× result isn’t only TCP latency. It’s what FTP does when you give it a thousand files instead of one big one.

FTP opens a new data connection for each transfer. Each new connection needs a TCP handshake — three round trips before a single byte of payload moves. At 85 ms RTT, that’s ~255 ms of dead time per file.

1,024 files × 255 ms = 261 seconds of handshake alone

Over four minutes of pure overhead before any data leaves the source. SFTP isn’t meaningfully better here — it’s still packet-oriented over TCP, with a similar read-ack loop per chunk. The bottleneck isn’t bandwidth, it’s the conversation.

What WarpSend does instead

Three changes that compound:

1. UDP transport with custom reliability. No wait-for-ack between packets. Our engine handles loss detection, retransmission, and ordering on our own terms. This is the same architectural move FASP (Aspera), AFTP (bTrade), GridFTP, and UDT all make — none of them are TCP-based for the same reason. The trade-off is more code on our end. The win is that congestion control becomes ours to tune.

2. Packet packing. Before transfer, we scan and bundle small files into large chunks. A thousand 1 MB files don’t get a thousand handshakes — they get one stream, framed internally. The per-file overhead drops to roughly zero.

3. Multi-threaded pipeline. Scanning, packing, encrypting, and transmitting all run in parallel. The transmission thread is never blocked waiting on the disk; the disk is never blocked waiting on the network.

The result: on the 1,024-file test, WarpSend completes in ~21 seconds where FTP takes over 3.5 hours. On the single 1 GB file, the gap is narrower — 15 seconds vs ~85 seconds — because TCP gets to amortize its handshake over more data.

Where this matters

The 618× number is most relevant if you regularly move large numbers of files:

• Raw camera footage from a shoot day (often hundreds of small clips before the editor consolidates)
• Project assets between offices (npm-style trees with thousands of small files)
• NAS-to-NAS backups and replication
• ML training datasets (often millions of small tensors)

Anything with a “1 GB total looks fine, why is this taking three hours” shape — that’s the FTP small-file penalty showing up in your workflow.

If you’d rather see it than read about it, try it free — 1 TB of monthly traffic, no card.