SheepDev

Infrastructure estimates

Why does a distant transfer depend on more than bandwidth?

Tools to use

Transfers to a nearby server can be fast while distant transfers lag. Contracted link speed alone does not explain every difference. Bandwidth-delay product estimates how much data can be in flight during a round trip. SheepDev does not measure the connection; use explicit inputs to explore how the estimate changes.

Try 100 Mbps and a 40 ms RTT

Calculate bits and bytes separately
100,000,000 bit/s × 0.040 s = 4,000,000 bit
4,000,000 ÷ 8 = 500,000 byte
500 kB = 488.28125 KiB

Enter bandwidth 100 Mbps and RTT 40 ms. The result is 500000 bytes. Convert milliseconds to 0.040 seconds and divide bits by eight. Treating 40 as seconds gives a thousandfold error; reading bits as bytes gives an eightfold error. Check units at both ends.

The 500 kB is not the file size; it is the amount carried at that rate during one round trip. A 1 GiB file does not imply all of it is awaiting acknowledgment at once. Separate total transferred bytes from bytes in flight.

RTT is a round trip, not one-way latency

RTT measures sending and receiving a response. Do not double a value already reported as RTT. If you only know one-way latency, do not silently assume equal forward and reverse paths. The tool does not contact the peer or validate your measurement.

If RTT varies, try several explicit cases such as 20, 40 and 100 ms. Label averages and temporary peaks separately. The exercise shows sensitivity to delay; it does not establish distance as the cause of a slowdown.

A faster link has a larger product at the same RTT

Change bandwidth and RTT one at a time
100 Mbps × 40 ms → 0.5 MB
1 Gbps × 40 ms → 5 MB
1 Gbps × 100 ms → 12.5 MB

Ten times the bandwidth gives ten times the product; changing RTT from 40 to 100 ms adds a factor of 2.5. A sender unable to keep enough data in flight may underuse a fast link. The product helps reason about that situation; it is not a speed-test score or measured buffer capacity.

Contracted 1 Gbps, available shared-path bandwidth and observed application throughput are different inputs answering different questions. Keep an upper-bound scenario separate from a measurement-based scenario so a theoretical estimate is not reported as an observation.

Do not paste the result directly into an OS setting

The product can inform reasoning about TCP windows, but inserting its byte count into one OS setting does not guarantee improvement. Congestion control, receiver behaviour, connection count, memory and application I/O matter. Changing an autotuned system to a fixed value requires separate investigation.

The screen changes no OS settings and sends no measurement traffic. Record bandwidth, RTT, product and the provenance of both inputs. Treat insufficient in-flight data as a hypothesis to test, not a conclusion established by multiplication.

Estimate whole-file duration separately

For a 1 GiB file at 100 Mbps and 80% efficiency, Transfer Time gives 107.3741824 seconds. Do not subtract the 500 kB product once from file size or treat it as seconds. Duration uses total bytes and effective rate; the bandwidth-delay product uses rate and RTT.

Sources

Tools to use

Guides →