Consistent 30ms would be pretty excellent, and make it useful for many things. Consistent 50ms, similarly. It starts to get a bit more of an issue at 80ms or 100ms, but my worry is more that jitter may be huge, and 30-100ms is a huge jitter window that could limit usefuless not just for games, but also many other things such as voice calls.
A 100ms ping is perfectly playable in everything except twitch-based shooters. In voice calls you will notice it, but it won't get in the way like say a 1-2s delay would (like you get if you phone from one end of the world to the other). It's really a very good result bearing in mind that this can work absolutely anywhere.
I don't think that's still true with 802.11ac. My Wi-Fi adds only 1 or 2 ms latency. There is way more jitter, but it doesn't really matter if the total is always under 10ms.
The shared medium (frequency spectrum) is what can add latency. If a device wants to talk over Wifi but another device is transmitting it has to wait. This introduces (variable) latency, aka jitter.
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.
I speak a lot with customers on satellite phones more or less every day. When they are calling from a BGAN terminal the latency can be a problem. Latency is around 1000-1500ms. But when speaking on a VSAT Ka-band terminal the latency is less of a problem. Data latency is around 600-800ms on VSAT. So I doubt latency of 100ms would be a problem at all. Most VOIP solutions have some mechanisms to reduce the perceived latency.
I'm struggling to imagine a network path that could induce a 1-2 second delay from one side of the world to the other. Even at just 50% of c-in-vacuum that's only a tenth of a second.
There's a lot of active gear introducing delays between those ends. Pinging www.govt.nz, which is about 17000km from me and as close to the antipode as I can find in a quick search, pings at around 300 to 400ms, so only at about 15 to 20% of c.
Even in an FPS unless you are trying to play at a pro level or something 100ms will be barely noticeable. Your reaction time is already probably over 300ms
One thing that may be a game changer: inter-satellite relaying. With the whole network, Starlink client to Starlink client latency might actually drop.
Count yourself lucky you don't live in either South America, Africa or Asia, where +100ms latency is more common than not. Fortunately I can count on one hand the applications that don't work with +100ms latency (not counting gaming). Usually it's the fault of the application developers (or rather the infrastructure team) where they put too low timeouts for requests rather than letting the requests go for a bit longer.
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.
Depends on where on the +100ms range we're on. Once you start hitting 1s latency, lots of applications (or rather, their servers) have a hard limit on 1s for every request. So when loading data from the backend, you have to continue to retry the request until it gets below 1s and then you will finally get the data.
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).
Anything that requires real-time interaction between a client and a server and other clients, e.g., gaming, stadia/geforce now, videoconferencing, ...
< 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).
Gaming and video conferencing come to mind. Videoconferences need bandwidth for obvious reasons but it's also nice if you don't have any delays in when you says something and when the other side hears it. I've been in some calls lately with very noticable delays. Especially people joining from mobile phones tend to be affected (shit latency, variable bandwidth).
> 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.
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
Yeah, in short: content-addressable systems are needed if we're ever to send data between planets on a larger scale. Systems like IPFS and alike solves this problem nicely, at least in my tests with high-latency scenarios.
This got me thinking... people _will_ start putting infra into space sooner or later, just for the better latency. Imagine the new availability zones in aws/gcp/azure :)
Could definitely lead to more investment into space, more money to SpaceX / Blue Origin / etc for their new-gen lift vehicles.
Would that not be impossible because of the lack of effective cooling in space? The only way to get rid of heat in space is by radiation, which is a very inefficient process. Assuming temperatures cannot rise above 100°C, every square meter of radiator fin emits at most a kilowatt. And because half the orbit is spent in direct sunlight, a significant part of the surface area will have to be reflective, making it useless for radiating heat.
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?
That really is surprising considering it’s just an island (or a few islands? I can never remember wether Ireland/isle of man is included.) It’s weird how expensive housing can get when there’s so much empty space.
Part of the island of Ireland, Northern Ireland, is part of the UK the rest being the Republic of Ireland (which everyone not in NI refers to as just Ireland).
The Isle of Man isn't part of the UK, though it is a Crown Dependency.
:strip_exif()/i/2003786186.jpeg?f=imagenormal){kind=link}