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:
Continue reading Starlink – Part 7 – Voice over Starlink8W 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.
Continue reading 8W vs. 400W – Notebook vs. WorkstationStarlink – Part 6 – Uplink Performance with BBR

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 .
Continue reading Starlink – Part 6 – Uplink Performance with BBRStarlink – 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?
Continue reading Starlink – Part 5 – Uplink Performance – Standard CubicStarlink – Part 4 – Downlink Performance – Standard Cubic

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.
Continue reading Starlink – Part 4 – Downlink Performance – Standard CubicStarlink – Part 3 – Downlink Performance – The BBR Version

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.
Continue reading Starlink – Part 3 – Downlink Performance – The BBR VersionStarlink – Part 2 – Radio Shadow, Rain and Umbrellas

Summer seems to have taken a break in the second half of July, and the day I wanted to test Starlink at another place and demonstrate it to some people was as inhospitable as it could probably get during a summer day in Germany: The temperature was well below 20 degrees Celsius, it was very windy, and we had everything from very cloudy but dry weather to periods with light to strong rain showers throughout the day. Or to look at it from a positive side: Perfect for testing Starlink in less than ideal conditions. So here’s how that went.
Continue reading Starlink – Part 2 – Radio Shadow, Rain and UmbrellasStarlink – Part 1 – First Bring-Up

I’m sure you’ve seen the one or other satellite focused post on this blog over the last year. So far, I’ve mostly been looking into handheld satellite text messaging, but I always had a close eye on Starlink as well. Recently, Starlink has lowered their prices and introduced mobile tariffs that can be activated and deactivated on a monthly basis. Mobility is important for me, as I wanted to test and potentially use satellite based Internet access in a number of different places. Also, I don’t need it all year around, so being able to only pay for the months while in use is just what I was waiting for, too. In other words, the time had come for me to order a terminal and see how it really performs in the Cologne area in Germany.
Continue reading Starlink – Part 1 – First Bring-UpTrain Windows Permeable For Cellular Signals – From Theory to Practice

While heat insulating windows are a great thing, they have one big disadvantage: They also block RF signals. That means that cellular reception inside buildings and trains becomes very difficult. Back in 2016, I first heard about the concept of modifying the heat insulation layer of windows so they would let RF signals through. At the time I had little hope that I would see this in trains in my lifetime. But I was wrong, it has really happened now!
Continue reading Train Windows Permeable For Cellular Signals – From Theory to PracticeHow to Fix Flickering Videos in Impress – X Quirks

Just a quick note today about what to do when videos inserted in OpenOffice Impress start to flicker: I had this strange behavior with Ubuntu 20.04 and the rather old OpenOffice version that comes shipped with it by default. And it seems I’m not the only one. But here’s the fix: Instead of using the default X-window compositor, switch to Wayland during login. There’s a little cogwheel at the bottom right side of the login screen where the compositor can be changed after selecting an account. And there we go, after starting the desktop with Wayland, no more flickering! That’s not a permanent solution for me, because apps for taking screenshots and recording the screen as well as remote desktop sharing do not work any longer, at least not with Ubuntu 20.04. Over time, these issues will probably go away anyway, as Wayland is the default compositor starting with Ubuntu 22.04. I guess that’s probably why nobody is keen to fix this in the first place. But I’m not quite there yet.