Starlink upload speed - TCP CUBIC vs BBR congestion control

[Sean]

Having recently moved from a deteriorating 4G service to Starlink, I tried some experimenting to see if I could get some extra upload speed.  From what I've found out in this presentation, Starlink has significant uplink packet loss as well as varying latency as the satellites fly past, i.e. lowest latency directly overhead and highest when going out of view towards the horizon.

 

As the BBR congestion control does not use packet loss as a congestion indicator and adapts well to varying latency such as cellular networks, this should work well with Starlink uploads.  The Ookla Speedtest makes multiple simultaneous uploads, so it generally reports much faster upload speeds than uploading a large file, however, with the Linear test on TestMy (i.e. Multithread disabled) the difference from my testing is huge.  So far I had no l luck finding any way of configuring Windows 10 or 11 to use BBR, however, this is possible with Linux with Kernel 4.9 and higher, such as much recent Linux distros.  While Windows 11 supports the BBR2 congestion control, it seemed to have little to no effect on upload speeds.

 

With a Linux root terminal:

modprobe tcp_bbr

 

Add the following lines to the end of /etc/sysctl.conf

net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq

 

The following is a set of 5 upload tests across 5 different servers at varying distances from my location in Ireland, the final being Sydney at the other side of the globe.  I tried running a 50MB block in each, but after Germany, the CUBIC tests failed with a "Too Slow" message 😁, so used smaller blocks for those CUBIC tests.  Each upload test was run on the same Windows 10 PC (CUBIC congestion control) with Linux Mint running in a Hyper-V virtual machine configured for TCP BBR.

 

As the TCP BBR congestion control only affects uploading, for faster download speeds the remote server must use the BBR congestion control.