Seems like pretty solid latency :)
Sub 100ms for satellite internet is incredible, hopefully it'll be cheap enough for people to actually get, compared to the current satellite internet we have.
Can't wait for humanity to become a multi-planet species, as then application developers would have to start taking multi-minute latencies into account, and hopefully that'll help me as someone with ~500ms latency to most services.
Pardon my ignorance, but what are some exampes of applications that wouldn’t work with +100 latency?
I think Adobe been one of the worst companies I've dealt with personally, as many of the endpoints have ridiculously low timeouts (for someone with really shitty latency).
Around about 100ms things stop appearing instantaneous, beyond the scope that everything starts to suck if you're not a patient person.
< 100ms is usually the "minimum", > 150ms is often "unusable", and for a smooth experience you might need < 30ms depending on the application (e.g. depending on the game you might need < 90ms or <60ms or <30ms).
The other two things on your list are both gaming.
But if your calls normally have lively discussion where someone different jumps in any time there's a pause, the higher the latency the more likely people will say "meeting in person is much better"
Likewise, with things like remote desktop, 100ms of latency isn't a dealbreaker but it'll certainly leave some of your users saying "things that run locally just feel snappier"
Up to 100ms is kind of ok-ish barely-sluggish, but over 100ms latency, it becomes extremely annoying to maintain a conversation.
Video conferencing often makes this worse, because it is what people use for meetings, etc. and that involves more than 2 people maintaining a conversation, so latency becomes even more important there.
Otherwise 3-4 people start talking over each other, and none of them notices until they receive what the others are saying. Which is extremely annoying.
Stuff that requires realtime (or near realtime) communication simply won't be possible.
What remains is bulk data transfer, here I guess the only viable way is:
1) on both ends in both directions, massive buffers (at least bandwidth x 4)
2) massive FEC (of course it will reduce the net bandwidth, but there's no real other way to avoid lots of retransmissions)
3) sender station transmits the data in blocks, with each object of data having a specified number of blocks
3) receiver station checks all the data blocks for integrity, places it in buffers, and transmits back a list of broken blocks and a list of successfully received blocks
4) sender station receives the list of broken/successful blocks, deletes successful blocks from its buffer and retransmits those marked as broken
5) receiver station waits until all the blocks for an object of data have been successfully transmitted, and delivers the message to the recipient system
Here's an anecdotal example for you, in practice with actual equipment:
1) Mac pro via ethernet to router:
# ping -c 5 -S 192.168.1.88 192.168.1.1
PING 192.168.1.1 (192.168.1.1) from 192.168.1.88: 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=0.413 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.396 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.417 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.553 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.514 ms
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.396/0.459/0.553/0.063 ms
2) Same machine via wifi over Unify AP to router: # ping -c 5 -S 192.168.1.72 192.168.1.1
PING 192.168.1.1 (192.168.1.1) from 192.168.1.72: 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=2.992 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=4.136 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.873 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=2.293 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=2.552 ms
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.873/2.769/4.136/0.774 ms
That's an average of 2.3ms extra latency, or 6x higher.Edit: Surprisingly little of the UK is actually built up areas: https://www.sheffield.ac.uk/news/nr/land-cover-atlas-uk-1.74...
The Isle of Man isn't part of the UK, though it is a Crown Dependency.
This is all just as confusing as it sounds...
Could definitely lead to more investment into space, more money to SpaceX / Blue Origin / etc for their new-gen lift vehicles.
Also, where'd you get the power? Solar panels will only yield a kilowatt per square meter at most, for half of the orbit. Beam it up from Earth?
Starlink network is nowhere near complete so I’d expect things to only get better (until customers start piling on)
Light in vacuum is faster than light in fiber.
The satellite mesh is not, a straight line from point A to point B is not possible most of the time, given the number of satellites available and range of laser communication in space.
There are enough satelites and low enough routing on the lasers to mean packets will arrive from London to NY faster than even a great-circle fibre.
In reality how much bandwidth is available is a function of money, and HFTs tend to have a lot of money.
I don’t understand this, why? Does light travel faster than the speed of light in fibre optic glass?
Financial capitalism shouldn't be praised, at the very best it's a lesson, we got useful tools out of it and that is all.
Berkshire Hathway has $1000+ spreads yet you dont see a lot of people complaining.
[1] https://youtu.be/giQ8xEWjnBs?t=288 (the whole video is worth watching, but that timestamp answers your specific question.
I watched it -- no it doesn't :) It is comparing fiberoptics latency with straight line light propagation. So the worst case scenario of non-existing inter-satellite communication could easily be worse than fiberoptics.
But I guess if the hedgefunds knew exactly which packet travels in a straight line, they could send one packet via Starlink and others via fiberoptics.
Judging from their high launch cadence, it seems satellite-satellite communication was just a means to excite the fanboys and motivate their employees, the same way the peddle the Mars stuff.
ground <--> satellite <--> ground
With satellite links: ground <--> satellite <--> satellite <--> ground
How can the latter possibly be faster?Edit: Thanks for all the responses. I'd been assuming it was a test of Starlink latency only, but if it's Starlink -> ground station -> open internet -> ISP then it would make sense how that would be slower than a pure Starlink connection.
1. Hop count is not one on the ground to go same distance.
2. Speed of light is significantly faster in vacuum.
3. The path is potentially straighter for longer distances.
ground <--> satellite <--> ground <------------> ground
With satellite links:
ground <--> satellite <--> satellite <--> ground
i.e. the sat-to-sat link should be faster than the ground-to-ground link, on the basis that light transmitted in vacuum goes faster than light transmitted in glass. That's the theory at least.
Currently:
ground <--> satellite <--> ground <--> ground farther away via legacy infrastructure
With satellite links: ground <--> satellite <--> satellite <--> ground farther away directlyLow altitude orbits mean that the hops up and down can be compensated by faster hops across.
That all of course is not there yet and depends on Starlink implementing the cross sattelite links.
I can get satellite Internet right now with 40Mbps down / 5 up, but the latency is 800 to 1000 ms, so it's slow.