Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Engineering for Slow Internet

brr.fyi

Post reply on HN
Print view View original

41–50 of 406 posts

Re: Engineering for Slow Internet

#41

Post by drozycki »

radicaldreamer wrote: post #27
drozycki wrote: post #11

Earlier quoted context omitted.

There’s a diner in SF I frequent. I usually sit 15 feet from the door, on a busy retail corridor, with Verizon premium network access. My iPhone XS reports two bars of LTE but there’s never enough throughout for DNS to resolve. Same at my dentist’s office. I hope to live in a post slow internet world one day, but that is still many years away. (The XS does have an Intel modem, known to be inferior to the Qualcomm fla…

I think this is a tough because a lot of bands have been repurposed for 5G and an Xs doesn’t support any of those.

I get 400 Mbps down standing at the door of that same diner. My understanding is that 4G bands are repurposed for 5G in rough proportion to the usage of 4G vs 5G devices at that tower, plus there’s some way to use a band for both. In any case I was having these indoor performance issues back in 2019. I’m pretty sure it’s an Intel issue, and any Qualcomm modem would be fine.

Re: Engineering for Slow Internet

#42

Post by kbr2000 »

chipdart wrote: post #23
0xWTF wrote: 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…

Delay/disruption tolerant networking (DTN) seeks to address these kind of problems, using alternative techniques and protocols: store-and-forward, Bundle protocols and Licklider Transmission Protocol. Interesting stuff, enjoy!

Re: Engineering for Slow Internet

#43

Post by padolsey »

A lot of this resonates. I'm not in Antartica, I'm in Beijing, but still struggle with the internet. Being behind the great firewall means using creative approaches. VPNs only sometimes work, and each leaves a signature that the firewall's hueristics and ML can eventually catch onto. Even state-mandated ones are 'gently' limited at times of political sensitivity. It all ends up meaning that, even if I get a connection, it's not stable, and it's so painful to sink precious packets into pointless web-app-react-crap roundtrips.

I feel like some devs need to time-travel back to 2005 or something and develop for that era in order to learn how to build things nimbly. In deficit of time travel, if people could just learn to open web tools and use its throttling tool: turn it to 3g, and see if their webapp is resilient. Please!

Re: Engineering for Slow Internet

#44

Post by cricketlover »

Great post. I was asked this question in an interview which I completely bombed, where the interviewer wanted me to think of flaky networks while designing an image upload system. I spoke about things like chunking, but didn't cover timeouts, variable chunk size and also just sizing up the network conditions and then adjusting those parameters.

Not to mention having a good UX and explaining to the customer what's going on, helping with session resumption. I regret it. Couldn't make it through :(

Re: Engineering for Slow Internet

#45

Post by throwaway2037 »

Tepix wrote: post #26

I had a similar experience as the author on a boat in the south pacific. Starlink was available but often wasn't used because of its high power usage (60+ watts). So we got local SIM cards instead which provided 4G internet in some locations and EDGE (2G) in others. EDGE by itself isn't too bad on paper - you get a couple dozen kilobits per second. In reality, it was much worse. I ran into apps with short timeouts th…

The South Pacific should be very sunny. I guess that you didn't have enough solar panels to provide 60+ watts. I am genuinely surprised.

And "local SIM cards" implies that you set foot on (is)lands to buy said SIM cards. Where did you only get 2G in the 2020s? I cannot believe any of this is still left in the South Pacific.

Re: Engineering for Slow Internet

#46

Post by saagarjha »

pintxo wrote: post #34
pimeys wrote: post #31

Earlier quoted context omitted.

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.

I was in Berlin earlier this month and the cellular connections underground were quite good now. So maybe this is less of a problem?

Re: Engineering for Slow Internet

#47

Post by auggierose »

padolsey wrote: post #43

A lot of this resonates. I'm not in Antartica, I'm in Beijing, but still struggle with the internet. Being behind the great firewall means using creative approaches. VPNs only sometimes work, and each leaves a signature that the firewall's hueristics and ML can eventually catch onto. Even state-mandated ones are 'gently' limited at times of political sensitivity. It all ends up meaning that, even if I get a connectio…

Or maybe, just get rid of the firewall. I am all for nimble tech, but enabling the Chinese government is not very high on my to-do list.

Re: Engineering for Slow Internet

#48

Post by astro-throw »

future10se wrote: post #19
grishka wrote: post #3

IMO author shouldn't have censored the app names. The world deserves to know.

Those I recognize (from interface, branding, strings, etc.): * Slack -- https://brr.fyi/media/engineering-for-slow-internet/load-err... * Signal (main screen) -- https://brr.fyi/media/engineering-for-slow-internet/in-app-d... * 1Password (config/about page) -- https://brr.fyi/media/engineering-for-slow-internet/in-app-d... * Zoom (updater screen on Mac) -- https://brr.fyi/media/engineering-for-slow-internet/in-app-d.…

My experience is that Slack worked great last winter, when the broadband satellite was up. When it's down, folks use an IRC-style client to cope with the very limited & expensive bandwidth from Iridium.

Re: Engineering for Slow Internet

#49

Post by padolsey »

auggierose wrote: post #47
padolsey wrote: post #43

A lot of this resonates. I'm not in Antartica, I'm in Beijing, but still struggle with the internet. Being behind the great firewall means using creative approaches. VPNs only sometimes work, and each leaves a signature that the firewall's hueristics and ML can eventually catch onto. Even state-mandated ones are 'gently' limited at times of political sensitivity. It all ends up meaning that, even if I get a connectio…

Or maybe, just get rid of the firewall. I am all for nimble tech, but enabling the Chinese government is not very high on my to-do list.

Whether you like it or not, over 15% of the world's population lives in China.

Re: Engineering for Slow Internet

#50

Post by [deleted] »

oefrha wrote: post #13

This is why I find it dreadful that evangelists here are heavily promoting live$whatever technology where every local state change requires at least one server roundtrip, or “browsers support esm now, bundling is a thing of the past!” etc. You don’t need to be at Antarctica to feel the latencies caused by the waterfall of roundtrips, or roundtrip on every click, as long as you’re a mere 200ms from the server, or in a…

[deleted]
Post reply on HN