SpaceX Starlink has some hiccups as expected, but users are impressed
arstechnica.com
arstechnica.com
Source: I ran a small satellite ISP on a base in Afghanistan.
Irrespective of how right or wrong your first paragraph is; this is one of the reasons I absolutely love the HN community.
If you saw a lot of jitter it was because you were in an oversubscribed, contended tdma network. What was your terminal hardware, what modems were you using and what was the rf chain and modem setup at the far end (not in Afghanistan)?
Latency on terrestrial ptp microwave also does not vary. Ducting and diffraction and temperature inversions on long 6GHz links affects rsl and modulation, not latency.
In the case of starlink, each satellite is functioning as a bent pipe relay between cpe and starlink earth station. Latency will vary a ms or two based on satellite position during a pass overhead, but no more than that. The rest of the latency is the same as from any terrestrial internet customer in the same geographic location as the earth station. For instance one of the beta test earth stations is in north bend, wa, colocated with a level3 long haul dwdm site.
People in WA have been posting tests with latencies of 25-26ms to speed test servers in downtown Seattle. That's actually really, really good, considering that latency to your default gateway on a residential cable docsis3 coaxial connection can easily be 16ms on a terrestrial connection. North bend is a few ms from seattle, the brewster starlink teleport site several ms more.
In the case of starlink they are competing against 32:1 or worse oversubscribed geostationary consumer grade vsat services like viasat and Hughesnet. Starlink is far superior tech.
Lost packets increase latency. And weather conditions cause lost packets.
As a note there were lots of people buying and installing cheap COTS 1.2-1.8 meter size ku band vsat terminals at all sorts of military sites in Afghanistan for MWR purposes, it's not rocket science or really hard to do at all. This stuff was, and is, all kept air gapped and separated from anything that is a real DoD or ISAF/RS network. These were networks for peoples' own personal recreational internet and entertainment in their rest time. You absolutely would see weird latency, jitter, packet loss behavior on those.
They can both be right as walrus01 seems to talk about latency of a single rtt in isolation, and withinboredom about what does the TCP endpoint effectively see.
Example: at one location, a 3.8 meter ku band dual linear polarity compact cassegrain dish in somalia, a 200W BUC+SSPA, good quality norsat PLL LNB, a cdm760 modem. Ten MHz of transponder space occupied total. Other end, a 5.5m dish with similar gear on it in a teleport in Cyprus.
If the person I'm replying to isn't willing or able to clarify whether they were in a contended, or dedicated network, or specify the gear, it's hard to say exactly why they're seeing jitter. But I can quite confidently say that excursions above 495ms are not something seen in a dedicated network.
It's how that dedicated capacity can get sliced up and shared that is the most common cause of packet loss, jitter and high latency in geostationary based two way satellite IP links.
The most common thing for a cheap VSAT isp to do is to acquire one chunk of Ku transponder capacity (let's say about $8000 a month worth), install something like an idirect hub with line cards in it, and sell access to individual end users in $developingnation at an 8:1 oversubscription ratio or more. Meaning that an end user vsat terminal might see 495ms at a lucky time when its peers in the same network were not also moving traffic, but could also often see latency anywhere from 500 to 850 during busy periods.
Now that same 8000 bucks a month of transponder space could equally well be assigned to a single high priority end user with money to pay, in which case they would never see above 495ms. Or it could be oversubscribed to all hell, such as if the ISP wanted to sell $280/month service to a bunch of very cost conscious end users in a developing nation environment who can only afford very cheap VSAT terminal hardware (one 1.2m fiberglass compression molded reflector, a 4W BUC, and an idirect modem) and minimal monthly ongoing payments. In which case each user will be in a 16:1 or worse oversubscribed network.
The economics of making a 5500 kilogram $200 million satellite in geostationary orbit pay for itself, before its lifespan is done in 15 years, are not favorable. If you ever want to truly be shocked go price the $ per Mbps per month that results from the 1:1 dedicated setup I described above.
On the topic of what the average hn reader considers "satellite internet". Based on consumer experience with the absolute cheapest consumer grade ku and Ka band vsat terminals in the usa, they almost 99% of the time mean Hughesnet or viasat/wildblue. Very few people actually have money or reason to lay their hands on real two way satellite stuff. Generally if you work for a company that needs something like a $3500/month link for a mine in Nunavut you're paying some third party experts to implement it.
> 3.8 meter ku band dual linear polarity compact cassegrain dish > a 5.5m dish
Are these receiver sizes in the range of what Starlink expects from users? I had in mind something more like a DirectTV dish. If the consumer dish sizes are indeed smaller, how does that affect the discussion about jitter and other aspects of link quality?
The starlink cpe is indeed in the category of directv dish sized.
With only a tiny bit of the relevant subjects under my belt, I would expect the metrics to be significantly worse using a much smaller dish. But it seems like you're suggesting Starlink could achieve similar metrics on a smaller dish? I'm curious how that works. Apologies if I'm misunderstanding.
Note that may be true for one bird in Afghanistan, but the path length isn't exactly the same everywhere, nor are the delays of all modulaiton schemes.
For instance our site in Germany was more than 15ms away by fiber from DE-CIX stuff in Frankfurt. The site in Singapore had better latency to any cdn or hosting operation that was in Singapore itself, but much worse if traffic had to find its way through the terrestrial submarine fiber internet to other places. End to end latency between Afghanistan-germany-seattle or Afghanistan-singapore-seattle was considerably different.
Yes, the position of the two end point sites on the sphere that is the earth will have slightly different speed of light times to a satellite in geostationary orbit. But 99% of that latency in the above 490ms figure is the extreme distance of the satellite, and not whether or not one site is slightly further down the sphere, as viewed from a theoretical observer sitting on the satellite.
It is also worth noting that modern scpc/mcpc modems can be intentionally configured to use more computationally "expensive" FECs, in a trade off of slightly more bps/Hz squeezed into a given sized slice of transport kHz, at the expense of a few ms higher latency. This is a network engineering design decision made when a link is first brought online. Modern modems and ASICs, FPGAs have made this less difficult than it used to be. If I can use an analogy for software developers, this is sort of like the speed vs file size trade off choice made between using gzip, bzip2, xzip, at different settings and compression levels.
Path length varies from ~34500km to ~42000km (~115ms to ~140ms). So, assuming an ideally placed teleport, from 115 * 4 = 460ms to 115 * 2 + 140 * 2 = 510ms speed of light delay on round trips. This is why I said I found 492ms to be an amazingly over-precise number. Just call it 500ms. :P
Let me see if I can answer some of this.
We were on a 1:1, eventually. Tried the 8:1 (or something like that) at first and it was terrible.
Latency was almost always, like you said, almost exactly 495ms at the link. However, we'd suffer transient jitter that directly correlated to weather in the atmosphere. Essentially, satellite communication is a laser (parabolas ftw), so this made sense at the time. Correlation doesn't necessarily mean causation, but it was annoyingly correlated.
I only made this correlation because my "day job" in the military had a lot to do with radar, microwave antennas, and optics. So, I'd observe the refraction personally (being able to see mountains as clutter for example, when the radar rays were pointed well over the mountains) and then notice the observed jitter on the network. Not to mention people coming to tell me how unusable Skype was at the moment and could I fix it please?
No offense, but you probably don't see this at your level as a network engineer unless you're "boots on the ground." When you're there and easily accessible, people will come complain to you when any and every little thing that goes wrong and "their wife is threatening to leave them and they can't even have a conversation, omg, fix it right now plz."
In a more corporate setting, people are far less likely to complain about transient issues because they fix themselves before the complaint can be made, or if they do, it's easy to dismiss as other issues.
To be honest, we had those other issues as well. QoS was a thing, and constantly battling bittorrent clients and their users was also a thing. But those issues were usually only during the evenings when lots of people were trying to call home and get on Facebook. I'm talking about when none of those issues were at play, such as late at night or during the day.
The UDP solution was directly related to periods of saturation, specifically I built a custom transparent proxy forked from Squid. It's sole job was to act as a mediator between a server back in the US that did a few things:
1. On the Afghanistan side, it would wrap the HTTP(S) request packet and send it via a TCP control channel to the server in the US.
2. On the US side, it would do some image compression (if applicable) and other things to the response to make it smaller (in bytes).
3. On the US side, it would also keep track of user flows and how much bandwidth each user got, and spit back UDP packets, reserving a dynamic % of bandwidth for control and unregulated packets. There was also an open TCP control connection for sending back smaller things that fit within a few packets.
4. On the Afghanistan side, it would put all these packets together to reform the stream, keeping track of any dropped packets (rare) and then forwarding the completed stream (or once the buffer was full) to the user at 100mbps. If any were dropped, it sent back a bitmap over the open TCP connection to have those frames retransmitted via TCP and then inserted into the stream before going to the client.
It worked fantastic for things like youtube, since the subscriber could make full use of their subscribed bandwidth with a half-second delay after clicking a link. The only things that didn't use that system were things like Skype. We never really had transport-related congestion issues after this was built as a hack, over several weeks. To be honest, it probably would have worked just fine by forwarding over already open TCP connections to the back-end server and giving each subscriber a dedicated stream. However, time in the desert is a premium and once something works good-enough, it pretty much stays that way forever.
> If the person I'm replying to isn't willing or able to clarify whether they were in a contended, or dedicated network, or specify the gear, it's hard to say exactly why they're seeing jitter. But I can quite confidently say that excursions above 495ms are not something seen in a dedicated network.
It was over ten years ago at this point, so I don't remember the exact models of anything. I do remember it was ku-band, but that's not exactly helpful. :) I sold everything off after getting sent back to the US for a medical discharge. The source was also lost in that pretty crazy time of my life, mostly due to the laptop ceasing to exist. The code still probably exists in SVN somewhere (Google Code, probably).
Even when you can see a mountain multiple times at once, the apparent distance to the mountain is going to have almost no variance as it shimmers around.
Everybody can be wrong about something, no matter how smart / credentialed / experienced they are.
That said unless we're talking about lasers air refraction doesn't usually impact RF(there is tropospheric ducting but that's something different).
Latency as experienced by users might be much worse, however, if suddenly 300Mbps of traffic is trying to be shoved through a 40-75Mbps link, for a period of several minutes or more.
From the point of view of an end user on a LAN at a site dependent on two way satellite it may not be possible for them to determine exact why they're seeing packet loss.
Ultimately, the latter is the kind of latency the user cares about.
I like that to you only one is a random guy on the internet. And I should know, I'm the president of the World Liking Things club, and you random guy on the internet have no business liking things like I do.
Only on HN
But my knowledge of networks is fairly rudimentary and old now and now that I think about it, pings would get sudden spikes in the rain too and that's just a lower layer than I'm talking about. hmm. I was also a child then so I might be misremembering.
For an example of a modern radio google aviat wtm4200.
For something like the af5xhd, it's a great little thing for its price, and with good quality antennas at both ends can make a very effective bridge. But for more serious things? No. It's so bad they haven't even been able to implement snmpv2 on their $1000+ radios. The af11 is so bad it only uses a 56MHz channel mask in an 80MHz channel.
No matter what manufacturer, serious ptp radios can be distinguished by two things: the presence of terminals for a direct -48vdc wiring connection and sfp/sfp+ ports.
At the very low end of cost, ubnt's 802.11ac chipset ptp bridge radios are great and very cost effective, I'm talking about the powerbeam ac series, nanobeam and similar. For when you want to buy a few hundred bucks of stuff on your credit card to link a few buildings together quickly. For anyone looking at that category of stuff they should also look at mikrotik and mimosa radios.
Edit: And, any really good blog series on this? so I know what to expect in such a course
Until very recently you have not been able to move more than 2400 bps through an individual iridium link, limiting it to very low data rate IP networking and single user at a time per device.
The military itself uses a lot more geostationary than you might think at first glance. They don't have their own iridium sized low earth orbit narrow band networks. There's many series of DoD satellites in geostationary, and they also lease a lot of commercial transponder capacity.
The other uplink was a solar powered 4G connection and despite several deep cycle batteries and a few 200 watt panels, the station did not get enough light to stay powered over those weeks.
We finally found a hilltop wireless ISP that can serve us. We’ll try to get Starlink too but I don’t expect that to work well during fire season. It’s tough to be offline for weeks at a time.
When dealing directly with UDP, one can implement different application-level logic for dealing with packet loss: "NAK" packets, different backoff strategies, and even forward error correction.
TCP is designed for encapsulation in IP, this is why it is called TCP/IP. And UDP is very similar to IP, only difference is that UDP gives you source and destination port numbers and a payload checksum, where IP only gives you a protocol numbers and non-checksummed data. None of these "features" is going to have any effect on how TCP is delivered.
So the only effect that use of TCP over UDP would have here is:
- increase the overhead used for headers, thereby decreasing the MSS (segment size)
- "cloak" the TCP traffic as UDP and thereby prevent any routers and/or middleboxes [2] from applying special treatment to TCP (i.e. traffic shaping, buffering etc.)
Maybe the latter effect is what made a difference for the link in question.
[1] https://tools.ietf.org/id/draft-baset-tsvwg-tcp-over-udp-01....
[2] https://en.wikipedia.org/wiki/Middlebox
edit: formatting
But he wrote that he'd used "TCP over UDP". The first lines of the TCP over UDP spec already state
"It provides exactly the same congestion control, flow control, reliability, and extension mechanisms as offered by TCP." [1]
[1] https://tools.ietf.org/id/draft-baset-tsvwg-tcp-over-udp-01....
From the outside it seems that a commercial failure of Starlink would bankrupt all of SpaceX.
He has said many times the slower-than-ideal ramp for the Model 3 assembly line very nearly bankrupted Tesla (it was within a few months).
When the first two SpaceX launches failed he spent all their remaining money on the next one - if it failed, SpaceX would have too.
He has also said if either Tesla or SpaceX go bankrupt, so does he.
He is literally betting the house with every major decision.
They currently pay $70 a month for their phone lines, and I bet a couple million Americans are in the same boat. They could probably cancel their entire bill with ATT if Starlink is reliable, as digital phone service is extremely cheap.
Can you clarify this? I don't know much about it but can't see how they relate.
12 were Starlink.
About half of SpaceX's launch manifest is launching their own satellites for Starlink.
Falcon 9 launch prices are about $62M.
So, Skysat probably paid 3-7% of the rate for an entire launch.
Indeed, see https://spacenews.com/spacex-rideshare-program-putting-downw...
It's likely the cost to launch is significantly lower, especially as they are often the 3rd/4th/5th/6th (has there been a 6th yet?) launch of a booster.
Assuming the $62m pricetag covers the cost of the booster, the marginal cost of the Starlink launches is recovery of booster and fairings + refurbishment of booster and fairings + stage 2 + fuel + operations.
A smallsat rideshare may well be paying a significant portion of those costs.
Yes, SpaceX probably has OK margins, but when we're considering how much of SpaceX's manifest is Starlink, this is not really relevant. There's been 9 launches + 3 launches that are 5% not Starlink = 9.15 launches worth of non-Starlink revenue.
And even having this different argument you're triyng to have, SpaceX's margins are not so good that collecting 5% of nominal market price will put them in the black for that launch... That's just fantasy.
On the broader point, I agree that SpaceX is sinking a lot into the Starlink, but even if it fails I doubt bankrupts the company. Part of that is just how cheap launch is for them, but it’s also because I can’t see a catastrophic fail mode for them. The satellites are clearly already working, worst case they have to sell the constellation to someone else. Probably a failure of imagination on my part though.
The satellite service business is much larger than the launch business and this is why SpaceX is attempting to enter.
Little immediate impact. Of course, if launch gets way cheaper, the things you do to maximize longevity, fault-tolerance, and mass efficiency start to matter less...
That is, payloads are expensive in part because launch is expensive.
Small sats have become so powerful, that on a SpaceX Rideshare you can deploy basically a whole constellation in one shot potentially. Most sats today are no longer that large and heavy that you have dedicated launches.
Many of their launches are government, both domestic and foreign.
SpaceX has not reduced the price 'that much' in the last couple of years. They were already the cheapest on the market and opted for more profit, so they could have better cashflow when going into Starship and Starlink.
What also has to be considered is that even that 12 is a pretty large number. Large rockets usually didn't fly that at the rate SpaceX flies them.
The sat market is slow the respond, 4 years are very little in it. Hopefully people will come up with more great ideas how to use the capability SpaceX offers.
I know a few people who would probably want that thing installed on their boats. For marine applications, it needs to work globally without any fences. Geofencing-wise, international waters == nowhere. In territorial or internal water you normally have some 4G from the land, not much need for satellites there.
That means the connection needs to go directly from the ground, up to a sat, then immediately back to the SpaceX ground station. That means for a while you’ll need to be within a certain range of a ground station, so international waters won’t work for a while.
The marine “anywhere on earth application” won’t be really applicable until they get the next generation of satellites with laser interlinks launched.
I don't doubt that SpaceX will figure out satellite to satellite high capacity trunk links within the next 5-6 years. But for now they are definitely proceeding with building medium sized starlink earth stations in the same general regions as where the CPE will be located.
Still, territorial waters extend for 12 nautical miles. Apparently, these satellites fly at 1100-1300 km. If ground stations (both SpaceX backbone routers, and mobile terminals) can talk to a satellite 45 degree above horizon, the satellite can connect the terminal with the ground station in a circle 1100-1300 km radius underneath (slightly less due to Earth curvature, but not by much).
Not gonna work in the middle of the Pacific, but might be good enough for many. For instance, one can sail from here across Mediterranean Sea all the way to Africa or middle East, while staying within reach of Europe-based routers. That’s assuming SpaceX gonna build them.
SpaceX updated all of their applications to only request 550 km.
Under ideal conditions you could have internet up to 1000km off the coast then even without laserlink. Under normal conditions it would be more like 500km from the nearest ground station.
I'm still hoping that they can use user terminals as ground stations for these maritime scenarios.
He has also said a few times it will work perfectly well on things like moving trains.
So I have to think the geofence will go away, though I assume there will be country restrictions due to legalities.
On a personal boat this is less of an issue, but for most large boats the operate would install it and then offer local WLAN I would expect.
Eg. It costs $50 per month for regular speed, $100 for double regular speed, etc.
You will hopefully get a better signal by having many sats in your view and the ability for the network to make smart choices about where to send what when.
No doubt the scummy high frequency traders are already jockeying to get out in front of this change in the telecom industry.
This is the theory of Non-Intuitive Cumulative Flatness (NICF) and is indeed rather ground breaking. The rugged persistence of flat-earthers over the years demonstrates that their claims must have some validity, and yet every last bit of empirical evidence refutes their viewpoint. NICF offers a unified theory of flat-curved earth geometry, much the same way that science has tried to bridge the gap between general relativity & quantum physics, to bridge these two contradictory theories and thus, demonstrate the earth to be both curved & flat.
Methods & applications that may take advantage of both geometries are currently underway. Most notably, finding the edge of the flat geometry would allow launching of space vehicles under significantly lower escape velocities, at which point the vehicle could transition to the curve geometry.
Softbank is highly interested, and a > $1billion funding round may be closing shortly after a successful MVP demonstration using a highly modded version of Kerbal Space Program.
I think it might remain a pretty ok option for some, but this is definitely going to become a way to pay hella beans for your preferred non-neutral network providing.
That means you want to be sitting right on both of the exchanges, but also that you want the fastest possible link between New York and Chicago.
Because that difference in distance is the actual reason. The geostationary satellites used for your internet in 2009 are at ~2.5 of the earth diameter above ground (35k km, ca 1.5 earth circumference), whereas the starlink satellites are near the atmosphere (less than driving distance SF to LA). And speed of light is rather slow in these dimensions already.
Though if you got 25%... did you calculate 115 milliseconds of speedup? That's the speedup for one leg. A ping to a server has to travel that distance four times.
what happens to get to the next 10x users? 100x?
it's cool that latency seems good.b that is the very first hurdle to viabity. but what hope there is for the future for this being real, useful, affordable broadband I think is still completely unknown.
whatever is happening today is being done at a radical loss, with a radically undersubscribed batch of satellites that is in no way going to reflect what kind of numbers people see if this goes anywhere, succeeds. maybe it can keep acting growing accommodating, providing magnitudes more bandwidth to people. maybe. while retaining this so far moderate price. maybe it's possible this works. but how it grows to serve orders of magnitude more folk, well, there are some constellation size asks, some guidelines, but it's very much indeterminate that the price point & offering now is viable, is really for real. there's a lot more finding out to do.
I think it's highly likely there will be data caps and/or fairly serious traffic shaping on the production version at some point.
I'm also quite nervous about uplinks. According to dlgeek there are 893 satellites up right now [1]. If we grow to 10x that number, and each satellite can do 20Gbit (where is that number from, btw?), how do we begin to provide that throughout, whatever fraction of that max 2.2Tbit/s aggregate downlink for the satellite fleet? What is it going to take to literally uplink such huge volumes? I'm not well versed in satcom & how much spectrum is available, & how good ground stations are at pointing. Can one base station potentially fully saturate 10 or 50 or 250 satellites, once the sky starts to fill? Maybe we are that good, maybe we can shoot tiny narrow high-bandwidth wide-spectrum needles exactly as needed up into the sky, en masse, dozens of high bandwidth beams emmentating from each ground station. Or maybe we just need millions of ground stations, but can work that.
Does even that work? I keep hearing of "constellations," trains of satellites. How close will satellites stick? Can a ground station reuse spectrum across multiple transmitters seen talking to constellation members? or are the satellites too close, lumped together? this filters back to a previous question, how much spectrum is available for uplinks?
Trying to imagine the scale of this project, seeing both how we get data to in to the sky, then down to folks, it's epic. All the "zero to one, one to many" modes of growth discussion feels short of the epic planning & demands it'd take to both hoist satellites up (which SpaceX Starlink seems to be doing!) & the supply network to make the satellites useful.
I don't think uplink is a problem. Even 2TBit/sec of internet capacity is cheap (especially compared to satelite launches) so I imagine this is a rounding error in the costs. I'm sure they have thought about the uplink spectrum requirements.
The above article mentions they think that starlink could serve 1.5million US customers when the full (12k) constellation is deployed.
Put a lot of sat dishes on the top of major Internet exchanges such as DE-CIX and on all data centers of AWS, GCE and Azure.
But what kind of limits does such an attempt run into? Can you just keep adding more and more dishes, as long as you please, each one pointing at one satellite, with zero interference from any other of your ground dishes? No, I rather suspect not. When you are uplinking, there's probably going to be other satellites also getting some of your signal, especially as we move from 1000, to 10,000, to beyond numbers of satellites. This is not my field, but I feel like there are some very interesting limits to uplinking, a lot of constraints, that the sky itself can only hold so much uplink capacity, and it'd be interesting to me at least to have some more back-of-napkin discussions on what those constraints really look like.
Only starlink is going to be using this frequency band, so it doesn't matter if it hits anything else.
And of the starlink sats, you're not going to have more than a handful in view at once, so aiming is easy. And as far as base stations go, you just need one every X hundred miles, with several dishes.
The problems you're imagining could be real on a sufficiently dense constellation, but there is no reason to go anywhere near that density, so it's not a problem anyone has to worry about.
27.5 – 29.1 GHz and 29.5 – 30.0 GHz and 47.2 – 50.2 GHz and 50.4 – 51.4 GHz = 6.1GHz of spectrum for uplink from base-stations ("gateways") to satellites
10.7 – 12.7 GHz and 37.5 – 42.5 GHz = 7GHz of spectrum for downlink from satellite to user "terminals".
According to this page, a year ago they were authorized to run 6 gateways.
I'm not sure how much throughput they can push to a satellite with 6.1GHz of total spectrum. It's still interesting to me to try to consider how even the current 893 satellites get anywhere near enough throughput up to them to be well utilizing their own downlink capabilities. I'm still only inuiting, but it still feels like something doesn't add up, I still don't see how the fleet is going to get enough bandwidth. My previous image of a data-center bristling with dozens & dozens of dishes pointing & tracking upwards indeed doesn't seem quite right (and the side-lobe interference question I was asking about), but the alternative, of a massive network of ground stations each boasting colossal connectivity, seems almost equally hard to imagine.
The satellites are very far apart, so they can use the full 6.1GHz per satellite with near zero interference. At most you'll have two in the same part of the sky.
The earth's surface area is about 200 million square miles. If you have 20 thousand satellites, that gives you ballpark 100x100 miles per satellite. Roughly 100 miles of separation, 350 miles of height, very easy to isolate just one.
With this many satellites, if you had a ground station every 300 miles, it would have to connect to about 10 satellites. It would need 200Gbps of fiber, which isn't hard to do. You'd be using less than 25 terabits per second across the entire continental US. That's less than a single undersea cable. No colossal bandwidth necessary, even at unreasonable numbers of satellites.
- Ground station
- SpaceX allowing you access from that location
Some beta testers have moved around their antennas and they worked even when not at the 'official' location. So currently it 'seem' like they are just relaying on beta tester to be mostly honest.
Once you have real sat-to-sat laser comms (next generation of sats, currently being tested) you can use it anywhere theoretically.
We don't know what the long term strategy is around geo-blocking. In theory they could have an issue where some location is fully subscribed and then somebody is moving there causing an issue. It will be interesting to see what policy they will use.
For the beta it seems to be tied to a geographic location.
Legal issues aside, they're also quite literally beyond the reach of all but a small handful of spacefaring nations, and even a nation like China that has the technical capability would not resort to actively shooting them down unless other avenues were exhausted.
(other than the US, if it so chooses)
This assumes that laser links are working which they are not currently.
This cloud be a nice little DIY project.
The source used for the comment "every 5-10 minutes" doesn't fully clarify that point. Many users in the Reddit subreddit post that is quoted stated that the person likely installed it incorrectly and the cutouts were from trees blocking the signal. So "every 5-10 minutes" is not what most people are seeing. Source reddit post the article uses: https://www.reddit.com/r/Starlink/comments/jsnd52/starlink_d...
Key reply:
> Based on the disconnects every 5-10 minutes. I would definitely say the obstructions are causing issues. I had the same problem last week and timing between disconnects. Put mine a little too close to the house. Moved it yesterday and today my connections were holding with no disconnects for anywhere from 2 to 3 hours with maybe a short 10-30 second disconnect between.
For those with marginal service, this is a material improvement. It’s also firming up the case that StarLink will generate billions of dollars per year in revenue (eclipsing SpaceX’s launch revenues), from both government contracts (rural broadband and DoD) and unsubsidized subscribers. This doesn’t include revenue from StarLink’s contract building missile tracking satellites for the Defense dept (based on StarLink sats) [2].
[1] https://arstechnica.com/tech-policy/2020/10/spacex-gets-fcc-...
[2] https://www.theverge.com/2020/10/6/21503165/spacex-space-dev...
It's even better than DSL and some wireless ISPs or 4G hotspots with marginal connections, which are probably the main competition for Starlink.
The whole reason CowboyNeal was attacking the iPod was that technically it was a step backwards. It couldn't do anything that a Nomad couldn't. The part that it did well (and that he missed the importance of) was the usability and polish.
> Compared to existing satellite ISPs you get dramatically better latency and dramatically faster/easier setup (no professional installation required, plug and play in 5 minutes). It's also likely to be far cheaper if you actually transfer a decent amount of data, and early tests seem to show better reliability in poor weather as well.
All true, but can you see HN caring about any of that if SpaceX wasn't involved? The HN userbase is overwhelmingly city folk; I suspect only a tiny proportion of us have ever used satellite internet before.
these satellites are radically undersubscribed right now, serving a handful of users tops. that's not going to model what happens if this works & grows.
Isn't that true of every product?
It's still very easy to forget.
Sure, in theory, the entire world can have access but that won't come for free and won't be in any way affordable by the vast majority of the world population.
I think you have a pretty misguided view of the developing world and their buying power. There are a lot of middle-income countries with reasonable spending power, but lousy infrastructure, in-between the extremes of the undeveloped Congo (which yes, will take some time to get Starlink penetration) and residents of a NYC condo.
https://www.pcmag.com/news/native-american-tribe-gets-early-...
Another thing you ignore is that if you combine Starlink with a mobile station you can potentially provide internet to a whole village.
Also, the prices will likely not be the same everywhere. SpaceX will want to get higher utility of the overall system and having unused sats fly over Africa is pointless. Lowering the price in some regions to get full utilization if an economic non-brainier if they would actually have issue selling the service.
In addition, the idea that this service wouldn't be worth it for rural people in the first world is very questionable. Don't rural people deserve good internet?