Throughput & Migration Timing Modeler
Enter your dataset volume and the effective bandwidth to generate precise migration timelines, adjusted for protocol overhead and real-world network entropy.
1. Theoretical Limits: The Shannon-Hartley Theorem
In any physical communication channel—whether fiber optic, copper, or satellite—the maximum possible rate of error-free information transfer is limited by the available bandwidth and the Signal-to-Noise Ratio (SNR).
The Capacity Equation
Where is the bandwidth in hertz and is the Linear SNR.
2. OSI Stack Overhead: The Payload Efficiency Matrix
A 10Gbps link rarely yields 10Gbps of file transfer speed because each layer of the OSI model introduces its own \"tax.\" For a standard 1500-byte Ethernet frame, the overhead is non-trivial.
L2: Ethernet
Adds 26 bytes (Preamble, SFD, IPG, FCS). This is a fixed L1/L2 tax on every packet regardless of size.
L3: IP (v4/v6)
IPv4 (20 bytes) vs IPv6 (40 bytes). IPv6 slightly reduces effective Goodput but eliminates NAT processing latency.
L4: TCP/TLS
Adds 20-32 bytes for TCP, plus TLS encryption. Standard HTTPS overhead is often ~4-6% total.
3. The BDP Collapse: Modeling Long Fat Pipes
The **Bandwidth-Delay Product (BDP)** represents the total data \"in the air.\" On high-latency links (NYC to Tokyo, 180ms), your bandwidth is effectively useless if your protocol isn't tuned.
Example: On a 1Gbps link with 100ms RTT, if your Windows scale factor is disabled (defaulting to a 64KB window), your actual speed is capped at 5.12 Mbps. You are wasting 99.5% of your expensive transit link.
4. Congestion Dynamics: BBR vs. CUBIC
The algorithm governing your transport layer determines how you react to \"Network Friction.\"
CUBIC (Loss-Based)
Treats ANY packet loss as a sign to slow down. Excellent on fiber LANs, but collapses on noisy WiFi or long-haul links where random bit-errors are common.
BBR (Model-Based)
Ignores packet loss until the bottleneck is saturated. It measures the physical 'drain rate' to maintain maximum throughput regardless of link quality.
5. Throughput vs. Goodput: The Reality Gap
Users care about Goodput (L7)—the bits of their actual file arriving. We model this by subtracting the multi-layer protocol headers and the control plane traffic.
The Calculation
Real-World Scenario
On a 10Gbps link with 1500 MTU, IPv6, and TLS 1.3, your absolute maximum theoretical Goodput for a raw dataset is approximately 9.32 Gbps.
Loss Factor: -6.8% Efficiency
Cloud Egress Dynamics
When timing a data transfer out of AWS, GCP, or Azure, you have to account for Per-VNIC Shapers and Per-Flow Policing.
The Single-Flow Cap
Most cloud providers cap a single TCP flow at 5Gbps or 10Gbps, even if your instance has a 100Gbps interface. You MUST use multi-threading to achieve full line rate.
Burst Credits
Many cloud instances use a 'Token Bucket' for networking. Your transfer might start at 25Gbps but drop to 10Gbps after 15 minutes as your burst credits are exhausted.
Frequently Asked Questions
Technical Standards & References
Related Engineering Resources
Serial vs Parallel Transfer Strategies
When transferring large datasets between GPU clusters, the choice between serial (single-stream) and parallel (multi-stream) transfer strategies determines whether the bottleneck is bandwidth or latency. For AI training workloads with tight deadlines, this distinction can mean the difference between meeting and missing job completion time targets.
The Serial Transfer Limit
A single TCP or RDMA stream is limited by the bandwidth-delay product. For a link with RTT (transcontinental), the BDP is . A single stream requires a receive window of 4 GB to saturate the link. In practice, TCP window scaling limits make this impractical, and the stream achieves only .
Parallel Stream Efficiency and Fairness
Parallel streams approach a Gaussian distribution of completion times when the number of streams is large (). The completion time is approximately the mean due to tail latency from TCP congestion window resets. Using RDMA with independent queue pairs avoids TCP's slow-start overhead, reducing tail latency by . However, too many parallel streams (>1024) can overwhelm the NIC's TX scheduler, causing internal packet drops that degrade overall throughput.
TCP Congestion Window Dynamics and Slow Start Modeling
The TCP congestion window (cwnd) governs the number of outstanding bytes a sender can transmit before waiting for an acknowledgment. During the slow start phase, cwnd doubles every round-trip time (RTT) until a packet loss is detected or the slow start threshold (ssthresh) is reached. The cwnd evolution during slow start follows an exponential growth: cwnd(t) = cwnd_initial ∗ 2t/RTT, where cwnd_initial is typically 10 segments (IW10, per RFC 6928). For a 100 Mbps link with 50 ms RTT, slow start reaches cwnd = 625 segments (approximately 937 KB at 1500-byte MTU) in 6 RTTs (300 ms), after which the sender enters congestion avoidance where cwnd grows linearly by 1 segment per RTT. The slow start duration for large transfers is negligible when the BDP is small, but for high-BDP paths it dominates the transfer time. On a 10 Gbps link with 100 ms RTT (BDP = 125 MB = 83,333 segments at 1500-byte MTU), slow start requires ceil(log2(83,333 / 10)) = 14 RTTs = 1.4 seconds to reach the full window, during which only 10 ∗ (214 − 1) = 163,830 segments have been transmitted, representing approximately 246 MB of data. For a 100 GB transfer, the first 0.25% of the data takes 1.4 seconds, and the remaining 99.75% takes the remainder of the transfer at the full bandwidth rate. The slow start overhead is a fixed latency cost independent of the transfer size: a 10 MB file on a 10 Gbps link with 100 ms RTT spends 20% of its transfer time in slow start, while a 100 GB file spends 0.02%.
The congestion avoidance phase uses Additive Increase Multiplicative Decrease (AIMD): for each RTT without packet loss, cwnd increases by 1 segment (MSS), and upon detecting packet loss (via three duplicate ACKs or a timeout), cwnd is halved (for TCP Reno) or set to (cwnd + ssthresh) / 2 (for TCP NewReno). The cwnd evolution in congestion avoidance is a sawtooth waveform with period proportional to the square root of the maximum cwnd. The average throughput during congestion avoidance is bounded by the Mathis equation: Throughput ≈ MSS ∗ sqrt(3/2) / (RTT ∗ sqrt(p)), where p is the packet loss rate. At p = 10-5 (one loss per 100,000 packets), RTT = 50 ms, and MSS = 1460 bytes, the maximum throughput is limited to approximately 1460 ∗ 1.225 / (0.05 ∗ 0.003162) = 1460 ∗ 1.225 / 0.000158 = 11.3 Mbps. This is the critical insight: a loss rate of 10-5 that appears negligible in absolute terms (one packet loss per 150 MB of data) caps the TCP throughput to 11.3 Mbps regardless of the link capacity. To achieve 10 Gbps on a 50 ms RTT path, the loss rate must be below p = (MSS ∗ sqrt(3/2) / (RTT ∗ Throughput))2 = (1460 ∗ 1.225 / (0.05 ∗ 1010))2 ≈ (2.98 ∗ 10-7)2 ≈ 8.9 ∗ 10-14 ≈ 1 packet loss per 1014 bytes, which requires a fiber-optic BER below 10-15 with forward error correction enabled.
The CUBIC congestion control algorithm (the default in Linux since kernel 4.19) replaces AIMD with a cubic function of the time since the last loss event: cwnd = C ∗ (t − K)3 + Wmax, where C is a scaling constant (0.4), Wmax is the cwnd size just before the last loss, t is the elapsed time since the loss, and K = (Wmax ∗ β / C)1/3 where β is the multiplicative decrease factor (0.3 for CUBIC, compared to 0.5 for Reno). The cubic function has three distinct phases: the plateau phase near Wmax where the cwnd increases very slowly (exploring near the previously sustainable window), the growth acceleration phase where the cwnd increases rapidly (utilizing the available bandwidth that the previous flow was not exploiting), and the maximum probing phase where the cwnd is far beyond Wmax and the growth rate decelerates. CUBIC’s key advantage for long-distance file transfers is its RTT-independence: the cwnd growth is a function of absolute time, not RTT count, so a flow with 200 ms RTT (transatlantic) grows its cwnd at the same rate as a flow with 10 ms RTT (same data center). This fairness property allows high-BDP flows to converge to their fair share faster than AIMD-based algorithms, which penalize longer RTT paths. On a 400 Gbps link with 100 ms RTT, CUBIC achieves full bandwidth utilization within 3-5 seconds after a loss event (depending on Wmax), compared to 15-25 seconds for Reno. Our bandwidth timer models the congestion window evolution across all three phases (slow start, congestion avoidance, and loss recovery) using the specified congestion control algorithm, computing the instantaneous throughput as a function of elapsed time and reporting the transfer duration with and without the congestion window dynamics penalty.
The TCP initial window (IW) and receive window auto-tuning are the two Linux kernel parameters that most directly affect transfer timing for short to medium sized transfers. The default IW of 10 segments (IW10) was adopted in RFC 6928 to accelerate Web page downloads, where the first RTT of the connection typically carries the HTTP request, and the second RTT carries the response data under IW10. The Linux kernel’s receive window auto-tuning (tcp_moderate_rcvbuf, enabled by default since kernel 2.6.7) automatically scales the socket receive buffer based on the measured BDP of the connection. The buffer size is clamped by net.core.rmem_max (default 212,992 bytes = 208 KB in many distributions, increased to 16 MB in tuned network profiles). When the auto-tuned buffer exceeds rmem_max, the receiver cannot advertise a window larger than the clamped value, artificially limiting the throughput on high-BDP paths. Running sysctl -w net.core.rmem_max=134217728 (128 MB) and sysctl -w net.core.wmem_max=134217728 before initiating a large transfer over a high-BDP path removes this clamp. The bandwidth timer tool includes a kernel buffer validation step: the user inputs the sender and receiver kernel buffer sizes (rmem_max/wmem_max), and the modeler flags whether the buffers are sized to accommodate the BDP of the specified link. If the buffers are undersized, the modeler reports the effective throughput ceiling as Throughput_effective = min(Link_BW, Buffer_Size / RTT), and recommends the required buffer size to saturate the link. For a 100 Gbps link with 80 ms RTT, the recommended rmem_max is (100 ∗ 109 / 8) ∗ 0.08 = 1,000 MB. This is why OS-level buffer tuning is the first action in any WAN transfer optimization playbook, and why cloud VM instances with 100 Gbps networking require explicit kernel parameter tuning beyond the default distribution settings.
Throughput Predictability: Markov Models for Variable-Bitrate Network Paths
Internet network paths exhibit time-varying throughput characteristics that deterministic models cannot capture. The throughput observed during a 10-second transfer window can differ from the throughput in the following 10-second window by 3-5× due to cross-traffic, congestion control algorithm interactions, and buffer occupancy dynamics. For AI training data transfer involving multi-terabyte datasets with transfer durations of hours to days, modeling this variability is essential for producing realistic completion time estimates rather than naive optimistic predictions. A hidden Markov model (HMM) approach treats the instantaneous available bandwidth as a latent state variable that transitions between discrete throughput states according to a Markov chain. The simplest implementation defines three throughput states: High (90-100% of link capacity), Medium (40-90%), and Low (10-40%). The transition probability matrix P = [p_ij] where p_ij = P(state{t+1} = j | state_t = i) is estimated from empirical throughput traces collected over representative paths.
The auto-correlation function (ACF) of the throughput time series determines the Markov model order required for accurate prediction. A first-order Markov model (memory of one time step) is sufficient when the ACF decays exponentially with lag, which is typically true for congested backbone links with hundreds of competing flows. For paths with dominant periodic congestion patterns — such as transoceanic links where daily traffic patterns follow a 24-hour cycle driven by business hours in interconnected continents — a higher-order Markov model or a model with explicit periodic components is required. The ACF of a 24-hour periodic component decays as a modulated sinc function, requiring at least 4-6 lag terms (corresponding to 40-60 seconds of history at 10-second sampling intervals) to capture the periodicity. The throughput predictor in the bandwidth timer tool applies a model selection criterion (Akaike Information Criterion, AIC) to determine the optimal Markov order for the user's specific path based on prior throughput measurements. If no prior measurements are available, the tool defaults to a three-state model with transition probabilities derived from a meta-analysis of published internet throughput studies, which show that the duration of "goodput bursts" (periods of sustained high throughput) follows a log-normal distribution with a median of 45 seconds on intercontinental paths and 180 seconds on metropolitan-area paths.
The completion time distribution derived from the Markov model is not a point estimate but a probability density function. Given the initial throughput state s₀ (typically "High" at the start of a transfer when the TCP congestion window is opening), the model simulates the throughput state trajectory over the transfer duration using Monte Carlo sampling with N = 10,000 independent simulations. Each simulation generates a sequence of throughput states [s₁, s₂, ..., s_T] by drawing from the transition probability matrix at each time step, then computes the cumulative data transferred as Σ B(s_t) × Δt. The simulation stops when the cumulative transfer equals the file size, and the stopping time t_stop is recorded. The resulting distribution of 10,000 stopping times yields the P50 (median), P90, and P99 completion time estimates. The critical finding from this analysis is that the ratio P99/P50 for intercontinental file transfers (RTT > 100ms) is typically 1.8-2.5×, meaning that a user planning for the median completion time has a 10% chance of experiencing a transfer that takes 2× longer than expected. For AI training data pipeline scheduling, this means the data prefetch buffer must be sized to absorb these tail-latency events, or the training job will experience periodic GPU starvation as data loading stalls.
The congestion regime identification layer extends the basic Markov model by classifying the dominant congestion control algorithm active on the path based on the observed throughput jitter characteristics. Algorithms like CUBIC exhibit a characteristic "sawtooth" throughput pattern with a period of 5-20 round trips, while BBR maintains a more stable throughput near the estimated bottleneck bandwidth with periodic probe cycles. The throughput jitter standard deviation normalized by the mean throughput (the coefficient of variation, CV) is typically 0.15-0.25 for BBR-controlled paths, 0.3-0.5 for CUBIC, and 0.05-0.10 for QUIC with its improved loss detection and smoother rate control. By applying a random forest classifier trained on throughput trace features (CV, autocorrelation at lag 1, skewness, and the spectral power at the RTT frequency), the model identifies the dominant congestion algorithm and applies algorithm-specific transition matrices. This enables the throughput predictor to distinguish between a path that is genuinely congested (requiring rate reduction) and a path that is experiencing CUBIC's natural sawtooth oscillation (self-correcting within a few RTTs), avoiding unnecessary rate reduction penalties that would extend the completion time.
"You are our partner in accuracy. If you spot a discrepancy in calculations, a technical typo, or have a field insight to share, don't hesitate to reach out. Your expertise helps us maintain the highest standards of reliability."
Contributors are acknowledged in our technical updates.