[capableweb]

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.

[ColoradoDev]

> Fortunately I can count on one hand the applications that don't work with +100ms latency (not counting gaming).

Pardon my ignorance, but what are some exampes of applications that wouldn’t work with +100 latency?

[capableweb]

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).

[fluffything]

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).

[Dylan16807]

Videoconferencing does not need imperceptible latency.

The other two things on your list are both gaming.

[michaelt]

Depends how much you care about people talking over one another. If your call is a presentation/lecture/class with few switches between speakers, latency's no problem.

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"

[fluffything]

For mobile phone networks, >20ms latency in audio is "unacceptable" from the point-of-view of standards conformance and a client "accepting" the hardware of some vendor.

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.

[jillesvangurp]

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).

[TheSpiceIsLife]

Voice chat is obnoxious with more than a few tens of ms latency.

Around about 100ms things stop appearing instantaneous, beyond the scope that everything starts to suck if you're not a patient person.

[mschuster91]

> 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

[skissane]

We already have a protocol spec for stuff like this

https://tools.ietf.org/html/rfc5050

https://tools.ietf.org/html/draft-ietf-dtn-bpbis-26

[capableweb]

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.