urlkit[ CHECK / [TCP] ]
TCP throughput calculator & simulator
Explore how bandwidth, latency, receive windows, and loss shape a TCP Reno flow.
02 / Your result
Your result will appear here.
Start with your own input or try an example.
What it does
A fast link does not guarantee that one TCP connection can fill it. Model a connection’s payload capacity, round-trip time, receive window, and segment loss to compare practical constraints. Simple mode supplies sensible Reno settings; advanced mode exposes MSS, initial windows, duration, and a reproducible loss seed. Two charts let you play, pause, or step through congestion-window growth and modeled payload throughput.
Useful when
- See why a small receive window limits a high-latency connection even with no packet loss.
- Explore Reno slow start, congestion avoidance, fast recovery, and conservative timeout behavior.
- Compare repeatable what-if scenarios before choosing parameters for a separate real network test.
How to use it
- Enter the link capacity, RTT, receive window, and segment-loss percentage, or load an example.
- Run the model. Use advanced mode to change MSS, initial congestion window, slow-start threshold, duration, or seed.
- Compare the analytical limits, inspect the trace one RTT at a time, and copy the report or download every round as CSV.
A few useful details
Does this measure my internet speed or predict modern TCP exactly?
No traffic is sent. This browser tool runs a deterministic, RTT-round teaching model of TCP Reno, with RFC 5681 window rules and an RFC 6298-style timer. It assumes fixed RTT, a fixed receive window, one ACK per segment, and an always-backlogged sender. Link capacity is treated as payload capacity. Queues, individual packet timing, headers, handshakes, CUBIC, BBR, and SACK are not simulated.
How do window limits and the Mathis formula differ?
Bandwidth-delay product is link bits per second multiplied by RTT seconds, divided by eight for bytes. The receive-window rate is window bytes multiplied by eight and divided by RTT. The separate Mathis reference uses sqrt(3/2) × MSS × 8 / (RTT × sqrt(loss probability)), assuming ideal periodic-loss Reno congestion avoidance with one ACK per segment and no timeouts. It is an approximate steady-state reference, not a match for this finite independent-loss simulation; zero loss has no finite Mathis bound.
What do the charts and recovery events represent?
Charts show the congestion window after each RTT and unique payload received during that RTT, including out-of-order bytes. A single early loss can enter fast recovery; late or multiple losses take a conservative timeout path. Recovery sends missing bytes only and approximates outstanding flight with remaining missing payload. Timers round up to whole RTTs. The same seed and inputs reproduce the same trace. Results cover complete RTTs only, up to 2,000 rounds, and the CSV includes all rounds.
Which units and default settings does simple mode use?
Mbps means decimal megabits per second; MB/s means decimal megabytes per second. A KiB is 1,024 bytes. Simple mode uses a 1,460-byte MSS, a 10-segment initial window within the RFC 6928 bound, a 64-segment slow-start threshold, and seed 42. Duration is 20 seconds, shortened automatically for RTT below 10 ms to stay within 2,000 rounds. Advanced mode permits up to 300 seconds while retaining that round limit. Values are model inputs, not detected operating-system settings.