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

251–260 of 406 posts

Re: Engineering for Slow Internet

#251

Post by infinet »

I had similar problem on a ship with many users share a 2M VSAT Internet. Few tricks made Internet less painful:

- block windows update by returning DNS query for microsoft update endpoints as NXDOMAIN.

- use a captive portal to limit user session duration, so that unattended devices won't consume bandwidth.

- with freebsd dummynet, pfSense can share bandwidth equally among users. It can also share bandwidth by weight among groups. It helps.

- inside Arctic circle, the geosynchronous satellites are very low on the horizon and were blocked frequently when ship turns. I was able to read the ship's gyro and available satellites from VSAT controller and generate a plot to show the satellite blockage. It was so popular that everyone is using it to forecast next satellite online.

Re: Engineering for Slow Internet

#252

Post by mattgreenrocks »

finack wrote: post #63
self_awareness wrote: post #25

What are the hopes for "engineering for slow internet" to happen, when people have engineered applications for "fast internet" when all we had was "slow internet". Nice thought in theory but unnecessarily gives false hope. Confluence/Jira sometimes need to download 20 megabytes in order to show a page with only text and some icons. I have a friend that tells me that in their company they had two jiras , one for devel…

[flagged]

The beautiful thing about engineering is that the skill differential is apparent all the way from conception to implementation.

But our industry is allergic to actually calling out actual skill issues that impact end users.

Re: Engineering for Slow Internet

#253

Post by RGamma »

LtWorf wrote: post #224
RGamma wrote: post #139

Earlier quoted context omitted.

Also wonder how many savings are still possible with a more efficient HTML/CSS/JS binary representation. Text is low tech and all but it still hurts to waste so many octets for such a relatively low amount of possible symbols. Applies to all formal languages actually. 2^(8x20x10^6) ~= 2x10^48164799 is such a ridiculously large space...

Surely you're aware of gzip encoding on the wire for http right?

Sure, would be interesting to know how it would fare against purpose-made compression under real world conditions still...

Re: Engineering for Slow Internet

#254

Post by bizzyb »

kortilla wrote: post #8
rlv-dan wrote: post #4

> Please keep in mind that I wrote the majority of this post ~7 months ago, so it’s likely that the IT landscape has shifted since then. Not sure if this is serious or intended as a joke. It made me giggle nonetheless. Which is kind of sad.

It’s serious presumably because Starlink coverage includes the poles now. 7 months ago was around the time they did a demo with the McMurdo base IIRC.

McMurdo has starlink. South Pole doesn't, but not due to technical reasons from starlink's side. From what I understand when they tested at Pole they noticed interference with some of the science experiments, its possible they will engineer around that at some point but for now starlink is a low priority compared to ensuring the science goes on. I forget the exact distance, but its something like 5 miles from pole that they ask groups traversing to turn off their starlink.

Re: Engineering for Slow Internet

#256

Post by gbalduzzi »

I agree with the overall take by OP, but I find this point quite problematic:

> If you have the ability to measure whether bytes are flowing, and they are, leave them alone, no matter how slow. Perhaps show some UI indicating what is happening.

Allowing this means easy DDOS attack. An attacker can simply keep thousand of connections open

Re: Engineering for Slow Internet

#257

Post by luuurker »

jimmaswell wrote: post #212
luuurker wrote: post #208

Those of us working on apps, websites, etc, need to remember that there are lots of people out there that are not connected to the fast Wi-Fi or fibre connections we have. Here in the UK, some networks started shutting down 3G. Some have 2G as a low energy fall back, but we're supposed to use 4G/5G now. The problem is that 4G is not available everywhere yet, some areas until recently only had good 3G signal. So I've…

Shutting down 3G was a mistake. Besides turning so many devices into e-waste, it was a good backup when 4g was congested.

3G devices should still work over 2G. It's much slower, but it works and should do so until well into 2030 in the UK.

The problem with 3G as I understand it is that it uses more power and is less efficient than 4G/5G. They're starting to re-deploy the 3G bands as 4G/5G, so the other Gs will eventually benefit from this shutdown.

Re: Engineering for Slow Internet

#258

Post by jrhey »

Engineering for slow CPUs next. No matter how fast our machines get these days, it's just never enough for the memory/CPU/battery hungry essential apps and operating systems we use nowadays.

Re: Engineering for Slow Internet

#259

Post by bobbob1921 »

nicoburns wrote: post #241
chefandy wrote: post #225

Earlier quoted context omitted.

Yep. In SPAs with good architecture, you only need to load the page once, which is obviously weighed down by the libraries, but largely is as heavy or light as you make it. Everything else should be super minimal API calls. It's especially useful in data-focused apps that require a lot of small interactions. Imagine implementing something like spreadsheet functionality using forms and requests and no JavaScript, as o…

> which is obviously weighed down by the libraries, but largely is as heavy or light as you make it One thing which surprised me at a recent job was that even what I consider to be a large bundle size (2MB) didn't have much of an effect on page load time. I was going to look into bundle splitting (because that included things like a charting library that was only used in a small subsection of the app). But in the end…

My experience agrees with this comment – I’m not sure why web browsers seem to frequently get hung up on only some Http requests at times, unrelated to the actual network conditions. Ie: in the browser the HTTP request is timing out or in a blocked state and hasn’t even reached the network layer when this occurs. (Not sure if I should be pointing the finger here at the browser or the underlying OS). However, when testing slow / stalled loading issues, this (the browser itself) is frequently one of the culprits- however, this issue I am referring to even further reinforces the article/sentiments on this HN thread (cut down on the number of requests / bloat, and this issue too can be avoided.)

Re: Engineering for Slow Internet

#260

Post by klabb3 »

gbalduzzi wrote: post #256

I agree with the overall take by OP, but I find this point quite problematic: > If you have the ability to measure whether bytes are flowing, and they are, leave them alone, no matter how slow. Perhaps show some UI indicating what is happening. Allowing this means easy DDOS attack. An attacker can simply keep thousand of connections open

Close after 10-60s of complete inactivity, don’t use JS bloatware and allow for range/etag requests should go a long way though. The issue is people setting fixed timeouts per request which isn’t meant for large transfers.
Post reply on HN