WirelessMoves – Page 19 – My Thoughts on the Evolution of Wireless, FOSS and the Past, Present and Future of Computing

Starlink – Part 11 – Obstruction Diagram

How much of the sky can be obstructed for Starlink to still work without connectivity breaks (in Germany)? This has been one of the most important questions I had about Starlink before I could try it out on my own.

Here’s an image that shows an obstruction diagram, which the Starlink app on a smartphone produces after ‘Dishy’ has been up and running for about 6 hours. The blue sphere shows the parts of the sky that are visible, while the black area shows where obstacles are in the way. The red arrows were put into the image by me. For this image, the Starlink dish was at my rooftop, and the sky was blocked as follows:

1) About half the sky to the south was completely blocked by a near vertical part of roof, which is about 2.5m high (red arrow on the top left). Dishy was about 0.5m away and hence, this part of the roof pretty much obstructed half of the sky.

2) Towards the north, there was a solid obstacle about 1 meter away and about 1.5 meter high which is also shown nicely on the image (red arrow at the bottom.

3) And finally, there was another 1.5m high obstacle towards the west, also around 1m away from the antenna, which also blocked the sky.

Starlink – Part 10 – Windows over Starlink – Uplink Performance

Windows 11 uplink throughput over Starlink with iPerf3

Part 8 of this series took a closer look at the downlink performance of two Windows 11 based machines over Starlink. This episode now takes a closer look at the uplink.

Before I go on, let’s set expectations: As was shown in part 5 and 6, there is a significant difference in uplink performance on Linux machines depending on which TCP congestion avoidance algorithm is used. With the default TCP Cubic algorithm, throughput was around 5 Mbps, whereas TCP BBR pushed uplink throughput to 30 Mbps.

So here’s how uplink throughput looks like on Windows with the default TCP parameters:

Starlink – Part 9 – Speedtest.net and LibreSpeed

Wireshark ‘Conversations’ analysis of a speedtest.net speed test

In part 8 of my Starlink series, I’ve been looking at downlink throughput with a Windows notebook. The maximum speed I could achieve with iperf3 was around 30 Mbps, while tools like speedtest.net and LibreSpeed could easily reach 150 to 200 Mbps. So what’s the difference and which speed test reflects real world use?

Starlink – Part 8 – Windows over Starlink – Downlink Performance

In my previous posts on Starlink, I’ve used Linux as the operating system on my notebook and on the network side server for my iPerf3 throughput measurements. Due to packet loss on the link, there is a significant difference between using different TCP congestion avoidance algorithms. When the standard Cubic algorithm is configured on both sides, the data transfer over a single TCP connection is 5 times slower than with BBR. So what happens when I use a Windows client over Starlink?

Starlink – Part 7 – Voice over Starlink

After seeing the many transmission errors over the Starlink air interface that TCP can handle quite well, particularly on Linux with the BBR congestion avoidance algorithm, I was of course wondering if this has an audible impact on real time voice services when used over Starlink. So here’s how that went:

8W vs. 400W – Notebook vs. Workstation

Quick thought of the day: Yes, there is a reason why flight simulation software does not run so well on notebooks: They are optimized for power efficiency and not performance. That’s quite OK for every day tasks such as word processing, which typically requires less than 8 watts on my notebook, or running specialized software for mobile network analysis in virtual machines, which typically requires between 15 and 20 watts. But when simulating a virtual world, the stop-gap of around 25-30 watts of small notebooks is nowhere near enough. But just how much more power is used by a workstation when running flight simulation software took me quite by surprise when thinking about it a bit.

Starlink – Part 6 – Uplink Performance with BBR

Starlink iperf3 uplink throughput with the TCP BBR congestion avoidance algorithm.

So here we go: After the interesting but somewhat slow Starlink uplink throughput results discussed in part 5, let’s have a look if the TCP BBR congestion avoidance algorithm can improve the situation. BBR is not configured out of the box, but I use it on all of my servers and workstations. BBR could be particularly helpful for uplink transmissions, as it is a sender side measure. Thus, it doesn’t matter which TCP algorithm is used on the receiver side, which, for this test, was a box in a data center .

Starlink – Part 5 – Uplink Performance – Standard Cubic

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?

Starlink – Part 4 – Downlink Performance – Standard Cubic

Data throughput during a 30 seconds TCP iperf3 session with TCP cubic for congestion avoidance.

In part 3 of this series, I’ve taken a look Starlink’s downlink performance with the non-standard TCP BBR congestion avoidance algorithm. Overall, I was quite happy with the result as, despite the variable channel and quite some packet loss, BBR kept overall throughput quite high. Cubic, the standard TCP congestion avoidance algorithm, is not quite as lenient on packet loss, so I was anxious to see how the system behaves in the default Linux TCP configuration. And it’s not pretty I’m afraid.

Starlink – Part 3 – Downlink Performance – The BBR Version

Starlink downlink throughput over 30 seconds.

After the more high level parts 1 and 2 on Starlink, it’s now time to have a closer look at how the Starlink downlink channel behaves. I’m totally amazed by the system and it performs very well in Germany. That being said, it probably comes as no surprise that on the IP layer, the graphs produced by the data transmission over satellites look very different from the same graphs produced by a data transfer over a fixed line VDSL link. For the comparison, I’ve used Starlink over the router’s built in Wi-Fi and compared it to my VDSL line at home, which is also connected to a 5 GHz Wi-Fi router.