Live data from Hacker News

Engineering for Slow Internet

brr.fyi

31–40 of 406 posts

Re: Engineering for Slow Internet

#31

Having a lot of experience commuting on underground public transport (intermittent, congested), and living/working in Australia (remote), I can safely say that most services are terrible for people without "ideal" network conditions. On the London Underground it's particularly noticeable that most apps are terrible at handling network that comes and goes every ~2 minutes (between stops), and which takes ~15s to conne…

I guess in London you get wifi only on stops, it's the same in Berlin. In Helsinki the wifi connection is available inside the trains, and in the stations. So you never get a connection loss when moving. I never understood the decision in Berlin to do this, why not just provide internet inside the train...

And yeah, most of the internet works very badly when you drop the network all the time...

Re: Engineering for Slow Internet

#33

As a web developer I actually resisted much faster internet for ages. Until 2022 I had a rock-solid, never-failed 7 megabit/s-ish down, 640k up connection and I found it very easy to build sites that others describe as blazing fast. This was slow really by the standards of much of the UK population even by 2015. So all I had to do was make it fast for me. A change of provider for practical reasons gave me an ADSL2+ c…

As a web developer you can just throttle your connection in developer tools though, no self-limiting required. But nobody does that in big corporations building most of the sites needed by people with slow connections.

Re: Engineering for Slow Internet

#34
post #31

Having a lot of experience commuting on underground public transport (intermittent, congested), and living/working in Australia (remote), I can safely say that most services are terrible for people without "ideal" network conditions. On the London Underground it's particularly noticeable that most apps are terrible at handling network that comes and goes every ~2 minutes (between stops), and which takes ~15s to conne…

I guess in London you get wifi only on stops, it's the same in Berlin. In Helsinki the wifi connection is available inside the trains, and in the stations. So you never get a connection loss when moving. I never understood the decision in Berlin to do this, why not just provide internet inside the train... And yeah, most of the internet works very badly when you drop the network all the time...

Berlin did not have mobile connections inside the tunnels until very recently (this year, I believe). This included the trains not being connected to any outside network. Thus wifi on the subway was useless to implement.

Re: Engineering for Slow Internet

#35
post #2

I still think engineering for slow internet is really important, and massively under appreciated by most software developers, but ... LEO systems (like Starlink, especially StarLink) essentially solve the core problems now. I did an Arctic transit (Alaska to Norway) in September and October of 2023, and we could make FaceTime video calls from the ship, way above the Arctic Circle, despite cloud cover, being quite far…

Pole doesn't have Starlink. McMurdo does. There are reasons.

Polar coverage from GEO satellites is limited because how close to the horizon GEO satellites are from Pole. Pole uses old GEO satellites which are low on fuel and have relatively large inclinations... then you can talk to them for ~ 6 hours per 24.

Schedule: https://www.usap.gov/technology/1935/

Re: Engineering for Slow Internet

#36

Having a lot of experience commuting on underground public transport (intermittent, congested), and living/working in Australia (remote), I can safely say that most services are terrible for people without "ideal" network conditions. On the London Underground it's particularly noticeable that most apps are terrible at handling network that comes and goes every ~2 minutes (between stops), and which takes ~15s to conne…

> In Australia you're just 200ms from everything most of the time. (...)

> The only app that I am always impressed with is WhatsApp. It's always the first app to start working after a reconnect, the last to get any traffic through before a disconnect, and even with the latency, calls feel pretty fast.

The 200ms is telling.

I bet that WhatsApp is one of the rare services you use which actually deployed servers to Australia. To me, 200ms is a telltale sign of intercontinental traffic.

Most global companies deploy only to at most three regions:

* the US (us-east, us-central, us-east+us-east)

* Europe (west-europe),

* and somewhat rarely far-east (meither us-west or Japan)

This means that places such as south Africa, south America, and of course Australia typically have to pull data from one of these regions, which means latencies of at least 200ms due to physics.

Australia is particularly hit because, even with dedicated deployments in their theoretical catchment area, often these servers are actualy located in an entirely separate continent (west-us or Japan) and thus users do experience the performance impact of having packets cross half a globe.

Re: Engineering for Slow Internet

#37
post #33

As a web developer I actually resisted much faster internet for ages. Until 2022 I had a rock-solid, never-failed 7 megabit/s-ish down, 640k up connection and I found it very easy to build sites that others describe as blazing fast. This was slow really by the standards of much of the UK population even by 2015. So all I had to do was make it fast for me. A change of provider for practical reasons gave me an ADSL2+ c…

As a web developer you can just throttle your connection in developer tools though, no self-limiting required. But nobody does that in big corporations building most of the sites needed by people with slow connections.

Yeah, though it doesn’t quite capture all of the experience of working with slower broadband.

For example if you have a website that is meant to be used alongside a video call or while watching video, it’s difficult to really simulate all of that “feel”.

Using a link that is slow in practice is an invaluable experience.

Re: Engineering for Slow Internet

#38
post #2

I still think engineering for slow internet is really important, and massively under appreciated by most software developers, but ... LEO systems (like Starlink, especially StarLink) essentially solve the core problems now. I did an Arctic transit (Alaska to Norway) in September and October of 2023, and we could make FaceTime video calls from the ship, way above the Arctic Circle, despite cloud cover, being quite far…

> I still think engineering for slow internet is really important, and massively under appreciated by most software developers, but ... LEO systems (like Starlink, especially StarLink) essentially solve the core problems now. I don't think that this is a valid assessment of the underlying problem. Slow internet means many things, and one of them is connection problems. In connection-oriented protocols like TCP this m…

I'd say these days it's more common to deploy in ap-southeast-1 (Singapore) rather than Japan to cover most of APAC.

Re: Engineering for Slow Internet

#40
I don't think any of our apps are built with slow connections in mind at all.

Most of our web libraries and frameworks are indeed quite bloated (with features of convenience), downloading 20 MB of JS and 50 MB of content in total to render a page is insane when you think about it. We'd need to be able to turn off most images or visual elements to focus purely on the elements and their functionality, except for cases where displaying an image is critical for the function (and even then give the choice of showing a low quality version with a smaller file size). Things like web safe fonts that are already present in the browser/OS, most likely no libraries like React or Vue either (maybe Preact or Svelte).

We'd need to allow for really long request (say, fetch) timeout values, maybe even to choose how to set them based on the connection quality (if a user has a really fast connection but a request suddenly hangs and is taking upwards of a minute, something has probably gone wrong and it'd make sense to fail that request, vs a user in a remote area for whom all requests are similarly slow), assuming that the server doesn't mind connections that linger around for a long time at slow speeds.

We'd also need to allow for configuring an arbitrary HTTP cache/proxy for any site visited and file requested (say, store up to 1 TB on some local server based on file hashes and return the same for any user that requests that), but obviously things don't usually work that way over privacy/security concerns (nowadays different sites even download duplicate copies of the same files due to changes in the browsers: https://www.peakhour.io/blog/cache-partitioning-firefox-chro... ). Maybe even for any web request that the OS might want to do, like system updates, basically a full on MitM for the whole system.

Speaking of which, no more Electron or large software packages. Only native software with like Win32/WPF or maybe something like GTK/Qt, but nowadays it seems like even phone apps, not just desktop software, often don't use the system GUI frameworks, but instead ship a bunch of visual fluff, which might look nice and work well, but also takes up a bunch of space.

I don't think there are incentives out there to guide us towards a world like that, which doesn't quite make sense to me. Lightweight websites should lead to better customer/user retention, but in practice that doesn't seem like something that anyone is optimizing for - ads everywhere, numerous tracking scripts, even autoplay videos, for everything from news sites to e-commerce shops.

People who do optimize for that sort of stuff, seem to be a part of a smaller niche enthusiast community (which is still nice to see), like:

https://1mb.club/

https://512kb.club/

Admittedly, even I'm guilty of bloating my homepage size from ~150 KB to ~ 600 KB due to wanting to use a custom set of fonts (that I host myself), even WOFF2 didn't save me there.

Post reply on HN