Packet Loss Impact Calculator: Mathis TCP Throughput Loss

Network performance is reduced by packet loss, something that can hide in plain sight even when your raw bandwidth look good. You might get a decent score on speedtest, but that doesn’t mean everything will work well when you make large downloads or call someone via video: some of your data simply won’t get there. That’s what this little tool above tells you: it measures your path and shows you your loss rate, then uses the Mathis equation to calculate how much your throughput is being reduced, and finally turns all these numbers in a simple quality rating for your traffic.

When you send data over a network, some of it may fail to arrive at its destination. The percentage that doesn’t make it is called packet loss. If I send one hundred thousand packets down a path and one hundred don’t make it, then my loss rate on that path is 0.1 percent. It sounds small, and it’s fine if your goal is getting a phone notification. However, if you’re trying to do a sustained TCP transfer, each drop will cause the protocol to react strongly, which will greatly impact performance.

Why Packet Loss Slows Down Your Internet

However, TCP assumes that any lost packets are due to congestion (not some random error), and therefore when it detects a drop, it reduces its congestion window approximately by half. It then increases the window gradually back up, in a sawtooth fashion. Frequent drops result in more window reductions, leading to a lower average sending rate. This means that even though the link might have plenty of physical bandwidth, a 1 percent loss can result in only a small fraction of this available rate. This happens because the loss eliminates most of the possible throughput, not just 1 percent.

The formula, developed by Matthew Mathis and his colleagues, explains how TCP throughput relates to loss. To find the maximum bandwidth, take the maximum segment size and divide it by the round trip time, then multiply that result by the inverse square root of the loss probability. The inverse square root is key; as loss gets smaller, it increases rapidly, but as loss goes up, it drops sharply, forcing the network to demonstrate its stability before pushing any more packets out.

The effect, however, is highly nonlinear: The throughput scales by the inverse square root of loss. That means halving the loss rate doesn’t increase throughput by just a small amount. Instead, halving the loss multiplies the throughput ceiling. In other words, cutting your loss rate from one percent to 0.25 percent cuts your probability to a fourth. This doubles your throughput ceiling because you took the square root of it. Lowering it another four times doubles your ceiling once more. While losing just a drop in a bucket would seem irrelevent, this is precisely what engineers pay attention to. Even a loss of a single percent or half a percent can cut your achievable throughput in half.

The Mathis cap is round-trip time divided by something, which is why latency makes it worse. This means distance also increases the issue. Shorter local paths can tolerate a certain level of packet loss much more than longer intercontinental paths. For instance, a 20 ms link could support roughly 58 Mbps per flow with only 0.1 percent loss, while increasing that same loss over a 150 ms transoceanic link decreases the limit down to 8 Mbps. Satellite connections in particular are very susceptible to loss; after all, they’re inherently disadvantaged in terms of throughput even without dropping any packets, and this calculator accommodates for this if you put your RTT in.

The tool calculates goodput, which is the portion of useful data carried by a connection rather than the overhead from resending every lost packet. It shows this as the throughput carrying genuinely new data. This does not count the overhead of retransmitting old bytes. At low loss, raw throughput and goodput are close together, but they start diverging as loss increases because sending packets again takes up some of the useful data rate, and fewer and fewer bytes is actually delivered effectively. It then plots the Mathis ceiling next to your link capacity, so you can see what’s really the bottleneck: the math or the math + your link?

Different types of traffic don’t react the same as loss: Real time apps like online games generally use UDP because waiting for retransmissions isn’t an option. Choppiness will show itself as lagged game play instead of slower transfer rates; voice becomes muddy at around 1 percent loss and drops off rapidly after that. To feel snappy enough for competitive gaming, loss must be less than a few tenths of a percent.

So if you’re trying this out, start with one of the presets appropriate to your situation, enter your packet counts and see how your connection stacks up. Take that and look at the reference table on the page. It gives you concrete data about what happens when loss increases from 0.1 to 5 percent. It drops the throughput of TCP like a stone. If you’re trying to size a link, or diagnose the cause of a slow download, this is useful information. If you want to explain to your colleague why 2 percent loss really does matter, here are the numbers. This makes something invisible obvious. And once you measure the right thing in networking, you can do something with those measurements.