In part 3 and 4 of this Starlink discovery series, I’ve been taking a look and the downlink throughput performance. While the standard Cubic TCP congestion avoidance algorithm used by Linux produced only meager results, switching to BBR produced a five-fold throughput increase. So how about throughput in the uplink direction?
In this part, let’s have a look at uplink throughput with Linux’ standard TCP congestion avoidance algorithm, Cubic. The following graph created with Wireshark shows a typical uplink throughput graph of a 30 seconds iperf3 single stream uplink throughput test:
Like in the downlink direction, throughput is quite variable. The graph is quite typical and this is one of the faster transmissions I saw with TCP Cubic at around 5.5 Mbps. Let’s have a look at the tcptrace sequence number graph of this test run, also created with Wireshark:
When right clicking and opening the graph in a new tab, one can see a bit better what is going on: Like in the previous posts for the downlink direction, there are many packet losses (red dots/lines in the graph), which trigger a retransmission.
Below is a zoom on the first 3 seconds of the transmission. Already in the first second, there are many lost packets which have to be repeated, and force the Cubic algorithm to throttle down. Later during the 30 seconds upload, packet losses are not as pronounced, but still occur at a rate of around 1 per second.
And just for comparison: Over a fixed line connection, packet loss in this scenario is 0:
Perhaps a bit of an unfair comparison, as one transmission is over a nice, short and (mostly) reliable copper cable, while the other transmission goes up to a satellite and down to an earth station again before ending up in a cable again. And quite frankly, it still amazes me to no end. Very cool stuff!
But perhaps things can be improved? Due to the frequent packet loss, I predict that uplink performance could be significantly higher when using the Linux TCP BBR congestion avoidance algorithm. Stay tuned, that’s what I will have a look at in part 6 of this series.