Do You Actually Need Acceleration? Measuring Before Buying

The pitch usually arrives right after a painful transfer. A dataset took all weekend to reach the overseas office, somebody important noticed, and now there is a quote on the table for a commercial accelerated-transfer product with an impressive demo and a price to match. The product category is legitimate — on the right link, UDP-based acceleration delivers everything it promises. The problem is that "the right link" is a measurable condition, and most organizations sign the purchase order without ever measuring.

This article is the measurement. In roughly an afternoon, with free tools and no changes to production, you can determine which of four very different problems is actually making your transfers slow — and only one of the four is the problem acceleration solves. You will finish with hard numbers: your link's real capacity, its latency and loss, what TCP currently achieves, and the size of the gap a product could close. Whichever way the decision goes, you will be able to defend it with data.

This is part of our Accelerated Transfer series, and it leans on the arithmetic from the bandwidth-delay product article — skim that first if the phrase is new to you.

The Question You Are Actually Answering

"Our transfers are slow" is not one problem. It is a symptom with at least four distinct causes, and they have four distinct fixes:

1. A window limit. TCP's throughput ceiling is window ÷ round-trip time. If buffers are at defaults, a single stream on a long path may use one percent of the link. Fix: free tuning, or parallel streams. No purchase.
2. Latency multiplied by loss. Even tuned TCP collapses when a long path drops a fraction of a percent of its packets, because congestion control backs off hard and recovers at round-trip pace. This — and only this — is the condition where UDP-based acceleration shines.
3. A path or capacity problem. The link itself cannot carry the advertised rate — congestion, shaping, a saturated middle hop. No protocol fixes this; a carrier conversation might.
4. An application bottleneck. The network is fine, but the endpoints are not: slow disks, encryption maxing out a CPU core, or thousands of tiny files paying per-file overhead. Acceleration products cannot help what the network is not causing.

The measurement protocol below separates the four in a few hours. Keep the goal in mind as you work: you are not testing whether a vendor's product is fast. You are testing which problem you have.

The Four Numbers You Need

Everything rests on four measurements, taken between the two real endpoints (or machines sitting next to them):

• Link capacity — the contracted or provisioned rate of the narrowest link on the path. You usually know this from paperwork; the UDP test below verifies it.
• Round-trip time (RTT) — one ping away. Multiply by bandwidth for the BDP, the window size a single TCP stream needs.
• Packet loss — the quiet killer. Fractions of a percent matter, so it must be measured under load, not with a handful of pings.
• Achieved throughput — what TCP actually delivers, single-stream and parallel, plus what your real transfer tool delivers.

The workhorse tool is iperf3, a free traffic generator that runs on Linux and Windows alike. One end runs it as a listener, the other as a client, and it reports throughput, retransmissions, and — in UDP mode — loss and jitter. You need a machine at each end and one firewall opening for its port (default 5201) for the duration of the test.

The Measurement Protocol, Step by Step

Run every test three times and keep the median; single runs lie. Record everything — the numbers become your baseline for any future tuning, and your evidence in any purchase discussion. The commands below assume a 500 Mbps intercontinental link; scale the UDP rates to your own capacity.

# On the far-end machine, start the listener:
iperf3 -s

# ---- From the near end ----

# STEP 1 - Round-trip time (record min/avg/max; on Windows use ping -n 30)
ping -c 30 far-end.example.com

# STEP 2 - Single TCP stream, 30 seconds. This is what one untuned
# connection achieves today. Note the "Retr" (retransmission) count.
iperf3 -c far-end.example.com -t 30

# STEP 3 - Eight parallel TCP streams. If the total jumps well above
# the single-stream result, the single stream was window-limited.
iperf3 -c far-end.example.com -t 30 -P 8

# STEP 4 - UDP at ~80% of link rate. This measures what the raw path
# can carry, and reports packet loss under load - the key number.
iperf3 -c far-end.example.com -u -b 400M -t 30

# STEP 5 - Repeat steps 2-4 in the reverse direction (add -R).
# Long paths are often asymmetric.
iperf3 -c far-end.example.com -t 30 -R

# STEP 6 - A real transfer with your actual tool and a representative
# file set (one large file AND a folder of small ones), timed.

Step 6 matters more than it looks. iperf3 measures the network alone; your nightly job also pays for disk reads, encryption, and per-file protocol overhead. The gap between step 2 and step 6 is bottleneck inside the endpoints, and it is invisible to every network-level fix.

Reading the Results

Now match your numbers to a row. The patterns are distinctive enough that the diagnosis is rarely ambiguous.

Two of the five rows end in "free fixes." One ends at the carrier, one inside your own servers, and exactly one — high RTT plus measurable loss that nobody can engineer away — points at an accelerated product. In our experience that distribution is representative: the loss-plus-latency row is real, but it is one row, not five.

A worked example makes the window-limited row concrete. Suppose the 500 Mbps link shows RTT 150 ms, single-stream 22 Mbps, eight streams 165 Mbps, UDP clean at 400 Mbps with 0.0% loss. The single stream implies about a 412 KB effective window (22 Mbps × 0.150 s ÷ 8), the parallel jump confirms windows are the constraint, and the clean UDP run rules out loss. Verdict: raise the buffer limits, described in the TCP tuning article, and this link will move bulk data at several times its current pace for free.

Now the contrasting example — the row that justifies a purchase. Same link, but the UDP test carries its 400 Mbps while reporting 0.4% loss, single-stream TCP wobbles around 2 Mbps with a high retransmission count, and even eight streams total under 20 Mbps. The path has the capacity; TCP simply cannot hold onto it, because every loss event at 150 ms triggers a deep backoff and a slow, round-trip-paced recovery. Tuning buffers will barely move these numbers — the window is not the constraint, the backoff is. If the loss cannot be engineered away, this link is the textbook case where a rate-based protocol earns its license fee, and you now have the two measurements — RTT and loss under load — that prove it.

Two Traps That Skew the Numbers

Trap one: trusting ping for loss. Ping is excellent for RTT and nearly useless for loss. It sends a few tiny packets into an idle path, and many routers deprioritize ICMP (ping's protocol) when busy, so it can show both false health and false sickness. Real loss — the kind that throttles TCP — appears under sustained load, which is exactly what the iperf3 UDP test creates. Always take the loss number from step 4, never from step 1.

Trap two: measuring through a VPN without noticing. If the transfer path rides a site-to-site VPN, your test measures the tunnel, not the line. Encryption overhead, encapsulation, and the VPN endpoints' own CPU limits all land inside your throughput numbers, and a fragmenting tunnel can manufacture loss that the underlying path does not have. Test both with and without the tunnel where policy allows; if the numbers differ sharply, the VPN gateway — not the ocean — may be your real bottleneck, and no transfer product on either side of it will help until that is resolved.

The Thresholds Where Acceleration Starts to Pay

With clean measurements in hand, the buy/no-buy line is easier to draw. Honest rules of thumb, assuming bulk transfers of large files:

• RTT under ~30 ms: acceleration is essentially never worth it. Tuned TCP fills almost any affordable link at these distances.
• RTT ~30–80 ms, loss near zero: still a tuning story. Buffer sizing and a few parallel streams reach line rate in nearly every case.
• RTT above ~80 ms with loss persistently ≥ 0.1%: now the physics favors rate-based protocols, and the gap tuning cannot close grows with both numbers. Evaluate seriously if the volumes justify it.
• Any RTT, but volumes are small or schedules are loose: even a wide percentage gap may not matter. A nightly 20 GB sync that finishes at 2 a.m. instead of 1 a.m. harms nobody; a product subscription harms the budget every month.

That last bullet deserves expansion, because the business math is where most acceleration cases actually collapse. The value of acceleration is hours saved on transfers that block something — a production deadline, a recovery-time objective, a person waiting. Multiply the hours a product would save per month by what those hours cost you; compare with the license. A media company pushing terabytes of footage against daily deadlines clears that bar easily. A mid-size firm whose overseas replication merely needs to finish before morning usually does not — especially once the free fixes have widened the nightly window. Scheduling helps here too: a tool like Sysax FTP Automation can shift bulk jobs to off-peak hours and compress data before sending, which quietly buys back much of the time a purchase was meant to save.

And always price the unglamorous alternative: moving fewer bytes. Compression and delta techniques — transferring only the changed parts of files, the approach covered in our rsync and delta transfer series — routinely cut repetitive transfer volumes by large factors, which no transport speedup can match.

If You Do Evaluate a Product, Make It a Fair Fight

Suppose the numbers genuinely point at acceleration. The evaluation itself deserves the same discipline as the diagnosis:

1. Tune TCP first, then baseline. The comparison that matters is the vendor's product versus your best free configuration — proper buffers and parallel streams — not versus the untuned defaults their demo was designed to embarrass.
2. Use your path and your files. Real link, real loss profile, real file sizes, both directions. Lab demos on simulated latency flatter everyone.
3. Test at the rate cap you would run in production. An uncapped accelerated flow will crowd the link; production will run capped, so benchmark capped.
4. Measure the whole job, not the burst. Include session setup, checksumming, and resume-after-interruption behavior, which matter more than peak rate for very large sets.
5. Bring the security team in before the trial, not after. Sustained UDP flows and new listening ports raise fair questions, and the approval path is much smoother when review starts early — our security review guide walks through exactly what they will ask.

When the Answer Is "No, You Don't"

Most mid-size organizations that run this protocol land in the no-purchase rows, and it is worth saying plainly that this is a good outcome, not a failure of ambition. A tuned TCP stack moving data over SFTP or FTPS — served, for example, by Sysax Multi Server on the receiving end — with jobs scheduled into quiet hours and volumes trimmed by compression or delta transfer, covers an enormous range of real-world requirements at zero incremental cost. The transfers finish inside their windows, the security review stays simple because everything rides familiar TCP protocols, and the budget goes elsewhere.

File the measurements when you are done, whatever the verdict. Six months from now, when someone forwards the next "transfers are slow" email, you will re-run five commands, compare against a documented baseline, and know in an hour whether anything actually changed. That habit — measure, compare, then spend — is the entire discipline this article exists to install.

The Version to Tell Your Manager

Slow long-distance transfers have four possible causes, and paid acceleration fixes exactly one of them: high latency compounded by packet loss. An afternoon with free tools tells us which cause we have — we measure round-trip time, loss under load, and what TCP achieves single-stream and parallel. If parallel TCP approaches link capacity, tuning solves it for free. If the path itself underperforms, it is a carrier problem. If the endpoints are the drag, no network product helps. Only if the link is long and measurably lossy and the volumes are large does an acceleration purchase clear the bar — and then we evaluate it against a tuned baseline, not against defaults.

Next reads in this series: the free TCP fixes to apply before any purchase decision, and how the accelerated protocols actually work so vendor conversations happen on equal footing.

Frequently Asked Questions