A recent study created by the research group ROADMAP-5G at the Carinthia University of Applied Sciences (CUAS) has tested SpaceX’s new Starlink constellation of Low Earth Orbit (LEO) ultrafast broadband satellites under different usage scenarios, which reveals some interesting findings.
SpaceX has already launched over 1,740 LEOs into space (c.1,600 are fully active) – orbiting at an altitude of between 540 and 570 kilometres – and their initial ambition is to deploy a total of 4,425 by 2024, which could then be followed by as many as 12,000 at a later date (possibly late 2026). The service has already gone live in the USA, Canada, the UK and is now extending into other parts of the world, albeit in a pre-launch phase.
Customers in the UK currently pay £89 a month for the service, plus £54 for shipping and £439 for the kit (dish, router etc.). But for that the operator claims you can expect to receive unlimited usage, fast latency times of 20-40ms, download speeds of between 50-150Mbps and uploads of c.20Mbps (such figures will improve as their network grows). Much of that has been validated by several recent studies (example).
Advertisement
However, the new CUAS analysis (PDF), which was conducted in Vienna (Austria), has now uncovered some interesting facts about the system. But it should be noted that this was based on using a single test system in just one country (very anecdotal data), although some of its findings will apply more generally to Starlink’s global network.
Summary of the Findings
• An average download throughput of approximately 170 Mbit/s and a maximum download throughput of approximately 330 Mbit/s could be reached in a time window of about 7 hours.
• An average upload throughput of approximately 17 Mbit/s and a maximum upload through-put of approximately 60 Mbit/s could be reached in a time window of about 15 hours.
• The observed latencies to a server in Vienna vary widely between less than 30 milliseconds and over 2 seconds.
• In approximately 98% of the time, the latency is below 90 milliseconds and in approximately 77% of the time, the latency is below 50 milliseconds.
• During a continuous ping test (one ping per second) for nearly 7 days, a downtime of 2.4% could be observed. This percentage is expected to decrease when reducing the ping intervals to less than 1 second.
• Steady continuous video streaming via YouTube delivers a satisfactory experience. In very rare cases there might be some short interruptions of up to 4-6 seconds.
• The automatic switching between the satellites seems to follow a pre-defined timing of 15 seconds. This means that changes in latencies (for better or worse) nearly always occurs between these 15-second windows.
• No conclusive evidence for a correlation between the current satellite constellations and the observed outages could be found. This does not mean that this correlation doesn’t exist, it rather means that this topic requires further investigation.
• In an observed period of approximately 56 hours, the power consumption of the whole client-side system (router and satellite dish) was 105 Watts on average with a maximum of 190 Watts.
• Officially, Starlink Internet access is only offered in selected regions. However, we could prove that the connection also works outside these regions at four tested positions.
• The time between powering the system up and having a working Internet connection varies between 5 and 20 minutes. The factors that influence that time have not been evaluated so far.
• As far as we could observe, the public IP address assigned to a router remains the same. In our case, the address was 188.95.144.107.
Perhaps one of the most interesting observations above is that the team couldn’t find much solid evidence of a link between the current satellite constellations and observed outages. Previously, it had been assumed that connection reliability, as well as performance, would improve as more LEOs join the constellation (this should improve signal acquisition and retention). But right now it seems as if outages did not reduce as more satellites were overhead. On the other hand, you’d need a wider sample base in order to answer this question properly.
Meanwhile, a separate study undertaken by the University of Southampton’s Astronautics Research Group has reported that near-misses involving Starlink satellites happen 1,600 times every week (i.e. a near-miss is deemed to occur when satellites pass within 1km of each other), which will only grow as the constellation expands. Most of these events actually occur between Starlink’s own LEOs (500 each week).
The results have relevance because one of the ongoing concerns about LEO networks is that they don’t just disrupt observational sciences (telescopes etc.), but they also increase the risk of a catastrophic run-away collision event between orbital objects in space (i.e. damaging other satellites and disrupting future access to space).
Advertisement
Assuming an orbital period of 95 minutes, switching very 15 seconds would require 380 satellites to fill an orbit.
I’m getting 18ms pinging that IP address from FTTP in the UK.
they’ll be doing the icmp response on land at the CGN VM, so all you are testing is how fast you can get (at best) to the relevant ground station.
IIRC incoming pings are terminated at the ground station.
So isn’t that cheating? Wouldn’t something that was latency sensitive testing for latency going to get the wrong information? So if I had Starlink and wanted to test if my link was from another location up I couldn’t ping it then to test, as it doesn’t show end to end connectivity using a basic ping diagnostic?
Welcome to the fun world of Carrier-Grade NAT. If only there was some way to get access to an almost-unlimited pool of IP addresses…
Ah I missed the bit about carrier grade NAT in play, I assumed the IP address was one handed to the customer by DHCP.
Incoming pings get answered at the POP even for IPv6 (Or they did when I last tried it).
Incoming TCP/UDP for IPv6 does seem to get forwarded through to the CPE
Here is an Reverse F8lure (outbound ping)
https://f8lure.mouselike.org/index.asp?DoAction=ViewHost&HostName=AEAC0A7A-BF51-42BF-8CAF-00C1BB3B6790
I do have an incoming ping graph but it’s via a Tunnel and involves some Nat hackery on a VPS so the traffic would be routed via the VPS providers network first.
“During a continuous ping test (one ping per second) for nearly 7 days, a downtime of 2.4% could be observed.”
= 4 hours downtime in 1 week.
I have customers complaining if there is 5 minutes downtime in 1 month…
Starlink is not the solution.
Starlink = space junk
Starlink is not intended to be competition to FTTP or good FTTC. It’s for those who can’t get either, and perhaps no good mobile data either.
I bet if I was in a location (e.g. rural) where I could suffer dial-up speeds at best through a fixed line, had limited or no mobile data, but could get Starlink, I’d definitely put up with a few niggles for 97% uptime in a week. Yes, far from perfect. It’s early days. I’m no defender of Starlink / Elon etc, nor like seeing even more space ‘junk’ flying around, but it certainly serves a purpose and apart from the equipment costs, it’s not outrageous monthly pricing.
I should think many in locations without any other option will be delighted with the service, despite the shortcomings.
Of course you’re not going to hang a server rack off it.
Perspective is sometimes dulled by our own luxuries – I’m on a 500/70 FTTP connection at home but I sure as hell remember 56K – and out in the sticks (or even in some very built up areas), the internet connection can be pretty crap!
I know this keeps being overlooked, but Starlink is not finished yet. It’s still in beta, they’re still deploying capacity. So the current loss etc is to be expected and it is progressively getting better.
And trust me, for many it *IS* the solution because the alternatives are utterly unusable.
I’ve been doing automated pings on my 4G at 1 minute intervals for the past 2 years. It frequently goes many days between any interruption, and most dropouts are only for a minute or two. Hopefully Starlink will get to the same performance as the network grows.
So an extra £42.00 a quarter on the average electricity bill. Why do they use so much power? I can understand it needing to use power to send a signal back up, but wouldn’t that only be when it was actively uploading data? Would it not mainly just be listening most of the time and just need the same sort of SoC as used in most routers?
Hypothesis – there will be a fair amount of service related activity as the system looks for and keeps switching to the next satellite as they zoom past overhead.
That power consumption is a little worrying, even at the lower end quoted consumption with a competitive unit rate that’s going to be at least £15 a month in electricity.
Compared to the findings here that’s quite a chunk: https://www.ispreview.co.uk/index.php/2017/01/energy-usage-uk-home-broadband-routers-big-isps-compared.html/3