129 comments

[ 2.6 ms ] story [ 211 ms ] thread
So then it’s like Ookla Speedtest?
Some ISPs might prioritize traffic to Ookla (or its mirrors) which makes the ISP look better than they really are.

With FAST.com you can see if your ISP throttles traffic to Netflix in any way, which is desirable for the ISP but undesirable for you.

Cool. So fast.com can't have traffic prioritised to it's domain? Shouldn't it better be fast.netflix.com or something?
Fast.com doesn't measure the speed to stuff behind fast.com, it measures the speed to Netflix CDN nodes.
If they prioritised traffic to fast.com then real production Netflix video traffic would also be prioritised

Fast.com is just a nice domain to put it on. It could be fast.netflix.com or anything, it just loads the code to kick off the test

fast.com uses video data from ntflxvideo.net
Great. That makes sense then. Thank you!
Except fast.com doesn't as many locations as speedtest.net; so the best I can get with fast.com is ~250 Mbps, while speedtest.net measures 900 Mbps.
Idk if you noticed, but with Speedtest.net often times you’re testing against an ISP-run or sponsored server so it’s hardly an accurate portrait of speeds with a typical service.
But you can select servers yourself. So I usually use the auto-selected server (sitting at my ISP or similar) to check local conditions such as is my cable modem or router/firewall doing fine or not. If I want to test "usable" bandwidth, I'll select a few servers in other, far-away cities like Amsterdam, Miami etc.
But that depends on what you’re trying to test. If you want to test your DSL/cable/fiber connection (and nothing else), it’s actually good if the ISP is hosting the test server.

If you want to measure the speed you’ll realistically experience in the wild, including your ISP’s peerings and whatnot, that’s another question.

Doesn’t it measure from the same locations as Netflix is delivered? I think that was the whole point of the service?
The main problem seems to be it’s HTML/JS based and just can’t keep up with high download speeds. Same goes for speedtest.net. Speedtest has a desktop app which doesn’t suffer from this issue.
I have well over a gigabit download speed on fast.com just now. I think it can keep up just fine.
It craps out at around 500Mbit on Safari/MacOS. Same on Chrome. The stand alone speedtest app goes up to >900 Mbit just fine. It randomly freezes during the test for seconds at a time, presumably the JS GC is triggered.

To be fair, I do have about 150 tabs open.

(comment deleted)
Is there a commandline version of it I can use on a public facing server to test it's network bandwidth/latency from different parts of the world?

Specific case: Our SSH server accessed by users from all around the world. It'd be nice to know the bandwidth & latencies our users get.

I use iperf3 to test the connection speed between nodes I control.
The problem with this is that Fast.com is owned by Netflix, which is such a significant consumer of bandwidth that it inclines ISPs to shape traffic to fudge the numbers. Essentially, this kind of speed test only really tells you what the maximum bandwidth your ISP is able to provide you is, rather than what they're really providing. Even then, the test result with Fast.com could be subject to traffic shaping or slowdown at the remote end, so what is the result really telling you at all?

In fairness, this would be true of any popular speed test, and I'm not sure of an obvious solution. Any kind of tunneling or onion routing would render the test pointless anyway, so I'm not sure of the extent to which you can ever really trust a speed test of this nature. The only really useful data for this kind of analysis is likely to come from a router with sufficiently sophisticated software that it can report on transfer rates over time (which many do), and even then, that doesn't account for scenarios where the remote connection is the bottleneck.

That’s a feature, not a bug. It was originally created in the context of the net neutrality debate. This allows you to see if your ISP is cheating you on Netflix bandwidth, supposedly in order to push their own media-on-demand product.

It was introduced after reports of ISPs doing just that, and it was Netflix’ way of hitting back.

Is Netflix sending the video data from Fast.com, though?

If not then they could very well be fudging the numbers for Fast.com and not Netflix proper.

It may not be common or even legal in the US (I really don't know), but in the UK traffic shaping is commonplace, even in instances where the package has been described as "Unlimited".

Yes, open the debug console and see for yourself ;)

  ...ntflxvideo.net
  ...ntflxvideo.net
  ...ntflxvideo.net
  ...ntflxvideo.net
etc.
It's the opposit: they use video data as test data for fast.com, served from CDNs or open cache or whatever is closest.
I think they are doing clever stuff to mimic real netflix traffic.

You can see various request to *.nflxvideo.net

Indeed, and it's a wonderful, useful feature. So useful to consumers, that a french ISP (Free) wasn't very happy with it and sued Netflix for it in june 2017.

I have no idea if this lawsuit is still ongoing, because Free seemed to have had a first peering with Netflix in April, and has been going up in the chart:

https://ispspeedindex.netflix.com/country/france/

Netflix uses fast.com and their speed index as a way to extort ISPs into giving them traffic for free. They refuse to pay any fees to connect directly to ISPs and then they use that website to imply they are being throttled when the meager free routes they use get saturated, which is their own fault.
I know net neutrality is no longer law, but I think if you interviewed a thousand people on this site, you might be the only one miffed that Netflix isn't paying ISPs for faster routes.

Put another way, it is my impression that consumers are already paying for bandwith. Getting Netflix to pay for faster routes would mean ISPs are double-dipping.

ISPs are neutral here, the problem is, once again, that Netflix uses a HUGE amount of traffic, and the normal routes (the ones everybody gets) get saturated.

If they want "premium" routes for their MASSIVE traffic, they will have to pay to the ISPs. I think that's reasonable. Giving them premium routes for free would not be neutral, would it? ;)

Netflix pay for their own uplinks.

That is fair.

They shouldn't pay for our downlinks, that we've already paid for.

That would be double dipping or something by our isps.

I feel like this is a good explanation of the issue.
Either their infrastructure supports what the customer is paying for or it doesn't. If the ISP is running crusty old routes they're slacking and customers should migrate away from them as soon as feasible.

ISPs should provide connection to the internet for their customers in exchange for a monthly bill. How they do that isn't the customer's concern and it shouldn't be Netflix's concern. The only ISP Netflix should be paying is their own link to the internet (AWS last I heard)

Side note, Netflix isn't using any traffic. They're not sending me a UHD video stream unsolicited. I'm using the traffic.

>Side note, Netflix isn't using any traffic. They're not sending me a UHD video stream unsolicited. I'm using the traffic.

Milk companies put their lorries in the highway to deliver their products. You're the one buying milk. Are you the one who's using the highways?

If Netflix wants a premium highway let them pay for it. Otherwise they will have to use the normal highway, the one that's worked fine until Netflix decided to fill it with lorries.

The grocery store bought the milk so that’s why the truck is on the highway. The truck (Netflix) wouldn’t be there if the grocery store (customer) didn’t order the milk.
If we imagine Netflix traffic as milk trucks delivering milk B2C, the “downlink” road to a milk buyer’s house would likely be maintained by neighborhood home owners’ association, thus ultimately paid for by the consumer.

Those highways between the farm and the neighborhood, though… Anyway, either the analogy breaks or it’s onto something!

In a less direct sense, yes. If there was no demand for milk in my area there would be no milk lorries sent to my area

Sidebar: I do wish HN had a rule against these kinds of analogies as they do other reddit-esque puns and the likes. The internet is not like a milk truck, it's not like a series of tubes, it's like 1s and 0s being communicated across a worldwide mesh of cables of varying material under the control of varying entities

We're all at least vaguely techy enough that we're on HN, we can understand at least the basics. Lets talk about what it is, not what it's like.

Let’s break it down:

BOB pays ALICE for a connection at fixed uplink/downlink parameters to the public collective of interconnected autonomous networks commonly referred to as INTERNET.

BOB uses the service as advertised to connect to CAROL’s autonomous network.

ALICE fails to adequately peer with CAROL’s autonomous network and calls it a feature.

BOB can’t switch ISPs because ALICE has monopoly on the service where he lives.

ALICE tries to muddy the waters with nonsensical milk lorry analogies that have nothing to do with fiber optic cables to maintain its monopoly and further leverage it to run protection racket on CAROL.

Sounds about right?

When BOB is paying ALICE for the service, he is implicitly paying for whatever “highway” connects his house and CAROL’s milk depots. Everything between the two points is ALICE’s responsibility. If ALICE doesn’t like that BOB mostly orders his milk from CAROL’s then she shouldn’t offer the service as supporting fixed amount of lorries per hour.

>ALICE fails to adequately peer with CAROL’s autonomous network and calls it a feature.

It also works the other way around: CAROL does not want to pay ALICE to have premium access.

Also, laughable that you call me a shill. Seems like the most used argument when you don't agree with someone. I'm not even American. So your "BOB can't switch ISPs" does not even apply here.

> It also works the other way around: CAROL does not want to pay ALICE to have premium access.

How does this logically follow? CAROL advertises fixed downlink/uplink connection to any autonomous network. How is it “premium access” to deliver on what you are actually advertising?

It’s like selling SSD drives and then saying oh yeah but if you store video files in this particular video codec they will play at only 15 fps unless the codec vendor pays us extra for a firmware update.

> So your "BOB can't switch ISPs" does not even apply here.

It applies to the particular Netflix/neutrality debate.

(comment deleted)
(comment deleted)
> also works the other way around: CAROL does not want to pay ALICE to have premium access.

As others have mentioned there is no extra "premium" access needed.

Netflix pays for their whole upstream, probably a bit extra for redundant uplinks etc.

Customers pay for the entire downstream.

Everyone in between just have to accept the bits and forward them within reasonable time (Netflix has some caching in the client so it shouldn't be to hard unless someone has oversold their capacity.)

> Also, laughable that you call me a shill.

I looked at your recent comment history and I agree.

That said you really seem to defend an undefendable practice to the point where I understand where people get that idea from.

So I'd rather guess you enjoy annoying people on the internet to see them get mad.

The way I see it is net neutrality is very unfair to the isp. It creates unnecessary burden to the isp. Of course Isp will hate it and will fight for it as much as their can.
Those ISPs can only fight this “burden” by taking advantage of their unfair monopoly. If there was an actual free market competition there would be no need for net neutrality in the first place.

BOB could just switch to using DAVE’s ISP service, who would be happy to connect him with CAROL’s AN without any throttling.

Its not the ISP fault if they are the monopoly.
Wouldn’t you agree those ISPs are very well compensated for this “burden” by not having to compete?
IT is their fault when they block competition in the marketplace and try anything they can to prevent cities to open up the market to competition.
Its in their best interest to block/prevent competition.
Just because an action is in their best interest does not absolve them from the fault of that action. Arguably, one can usually safely assume the opposite.
What extra burden?

They get paid by customer to deliver bits.

The only extra burdens I see is the "burden" of 1) not double dipping and 2) not overselling their offerings.

> What extra burden?

All the work to make sure it comply with net neutrality.

AFAIK in more than one case that has been the burden of:

not taking extra steps to throttle Netflix,

i.e.

the burden of not double dipping.

I think few people are arguing that Netflix should get special treatment, only that:

* ISPs should treat all bits the same (unless I as the receiver has asked for something else).

* ISPs should have enough capacity to serve their customers.

It maybe that case but regardless, net neutrality disadvantage to the isp. Of course they are not happy with it.
I'd argue that

- basic honesty (not pretending they don't get paid)

- and not extorting money from other companies by keeping said customers hostage

shouldn't be considered a disadvantage?

While your statement of "of course they are not happy with it" is true, it's not a defense in my mind. The same could be said about any regulation that controls indefensible practices of companies.

From oil companies, to fishing companies, to waste disposal to whatever, most companies from a purely technical viewpoint would be more than happy to get rid of regulations that control what and how they can do business. Yet, we have those regulations in place for a reason.

In this case we simply ask that ISPs deliver the bits we paid for. I don't want Comcast treating my bits differently anymore than I want my mail carrier to hold my packages ransom because they seem important and I'd probably pay more for them.

My mail carrier doesn't read my mail. Comcast shouldn't either.

Yes of course it always depends on which side are one on. If I'm the customer sure I don't want isp throttle my bits but If I'm the isp, I want the freedom to throttle.
Yea, I wasn't disagreeing with your logic.. I guess I was saying that, it doesn't matter (not trying to be insulting lol).

Ie, in a purely technical sense corporations shouldn't want any laws/regulations. But that's not really a relevant fact to anything, is it?

Net neutrality requires that ISPs actually deliver what they've advertised and collected payment for and claimed to deliver. Of course they're not happy with that. It's much easier to deliver less than promised but still pocket the full payment.
Correction - make it comply with Title 2. Net neutrality isn't what the FCC killed, Title 2 (which is still a massive blob of legislation, even if you discount the stuff in forbearance) is a set of laws that ensure a kind of neutrality.
Milk companies put their lorries in the highway to deliver their products. You're the one buying milk. Are you the one who's using the highways?

Yes, I think that is the right way to think about things here.

As to the rest of your comments - Imagine if Amazon could pay the USDOT for special lane on the highway.

Except that I pay for an highway that should support 100 mb/s and they pay for an highway that should support 100 mb/s, yet it only support 10 mb/s.

The Netflix route is using too much bandwidth? Then upgrade it, that's what your customer pay you for. For sure there will be route that will be unequal, some too big, some too small, but that's part of ISP job to make sure its impact is minimal.

(comment deleted)
The customers of the ISP have paid to connect to the internet. Netflix isn't generating the traffic, the customers are, and if the ISP wants to serve the customers they need to provide bandwidth to the places they want to go.

Shaking down the destination, because the ISP controls the customer is wrong on many levels.

Couple of megabits from time to time, not even every night, is not a HUGE or a MASSIVE traffic, neither it has to be "premium". It's very normal traffic, on the lower end even. It's just some ISPs are monopolies and want to abuse their position and extort money from anyone they can, despite the fact that customers pay them to literally provide access to those services.
ISPs were or are double dipping. They actively started throttling Netflix even when there was no congestion or traffic only so that they could extort money out of Netflix. You could access YouTube, Vimeo or their own video-on-demand without any compromise in quality but Netflix was forced to a crawl.

If Netflix wants to pay extra to deal with saturation they are more than welcome too but if ISPs are denying their subscribers access to a service, even when spare bandwidth was available and sitting unutilized then its time for pitchforks to come out

Netflix rarely consumes Internet traffic as your statement assumes. Netflix has content caching at, pretty much, most legitimately sized ISP and peering points today. That means you're probably watching your content without leaving your ISPs network. The ISP pays pretty much nothing for transport (because Netflix provides them with a way to alleviate that) however the customer gets better service and quality of Netflix because the content is local. While this isn't always true neither is the thought that all traffic is heading back to Netflix HQ and saturating all of the Internet links in between.
Then how is fast.com effective at all? It was created to show that ISPs were throttling Netflix, but if Netflix has boxes at peering points, this seems moot.
They peer with Netflix for free then demand extra money to actually keep peering for free at proper capacity. They want money for connecting an extra cable to their router. It’s a protection racket pure and simple.
I'd guess it indicates capacity if you try to watch something that isn't cached?
What's the problem with routes getting saturated? The consumers are paying for bandwidth and if they're using it all for Netflix, that's their choice.

The only problem is if the ISP can't actually deliver the bandwidth that they promised in exchange for taking the consumers money. That's called a scam.

> ISPs are neutral here, the problem is, once again, that Netflix uses a HUGE amount of traffic, and the normal routes (the ones everybody gets) get saturated.

What I don't get is, both Netflix and I pay for bandwidth. As far as consumer bandwidth (mine) is concerned, why should Comcast care if it's 1TB/month coming from a thousand sites or just one. I paid for the data, I paid for the bandwidth, give me my bandwidth.

Likewise, Netflix paid for their own too, with whoever is their ISP.

Conceptually the bandwidth has to be paid for, and I could see your argument if I only paid a portion of what it costs to transfer the data.. but that is a broken model if that's the way it is. I want to pay for data, and I shouldn't have to get Movies.com to pay Comcast to serve me movies. I paid Comcast for data, it doesn't matter who it's from. My data is my data.

Is this wrong somehow to you? Honestly it's a strange argument from you, I have a hard time understanding. Like, if you run a website and I visit your website, do you think you should have to pay my ISP for data I'm downloading from your site? That's a bizarre system in my mind.

Yes, we need to emphasize this point.

Netflix (and Youtube and Hulu and all the other big content providers) pay big bucks (millions per month) to get the content from their servers to the internet backbone. Their contracts with their ISPs don't specify where the traffic goes. They just buy lots of 10 gpbs links, and send the data off. They're paying their share.

Your contract with your ISP doesn't distinguish between getting traffic from a mom&pop website or Netflix. It just said they would deliver the rated speed (7 mpbs or 10mbps, or 100mbs) of data to you for your fixed monthly fee.

When the ISPs found out that people were actually using that much data (that YOU PAID FOR), they found they had underprovisioned their network, and couldn't support the load. ISPs started saying, "Netflix is using too much", because, really, it's rude to blame your customer for using the service you provide as contracted.

This is called double-dipping.

So - Netflix is paying their fair share. You are paying your fair share. If your ISP can't handle the traffic demands of their customers, they need to suck it up and provide the capacity that you're paying for.

Um, when this whole debacle started, I saw articles which said that Netflix offered to pay for hardware and put more capacity in ISPs datacenters but ISPs refused and instead wanted more money to give access on the last-mile connectivity
The program is called OpenConnect [1], which has been around for a while. If you're an ISP, Netflix will ship you a beefy server for free to cache Netflix content.

[1] https://openconnect.netflix.com/en/

What am I paying for when I pay Comcast?

Edit: I hear arguments like this and I really don't understand them. I would like to hear the reasoning behind it because it just doesn't make sense to me.

ISPs aren't generally inclined to shape traffic to increase bandwidth for Netflix, though. Often they throttle it, so it's a good test to see if you'll get good performance doing something you likely care about bandwidth for (streaming Netflix).
I'd mentioned this in another comment, but I'm not sure that shaping traffic (or not) for the speed-test would mean they're treating streams the same way, especially if it's a different TLD.
I think based on the urls being requested on the site that they hit their production serving services, so it shouldn't be possible for an ISP to treat it differently (at least not without some highly advanced techniques)
(comment deleted)
> Essentially, this kind of speed test , rather than what they're really providing.

I get half the download bandwidth on Fast.com that I get using th FCC Speed Test app, so I don't think the former “only really tells you what the maximum bandwidth your ISP is able to provide you is”.

Fair point, which I only realized after I'd submitted the comment. I've updated the parent to reflect this!
I can't remember where I read this but some ISP's give preferential treatment to url's with the word " /speedtest " in it rendering the test meaningless
that's impossible because fast is served via https
Correct me if I am wrong, but you can still see the URL you navigate to when using https, is that not correct?

Once the connection is established you can't see the traffic between you and the URL.

Is my understanding correct?

Due to SNI, the domain name is sent in cleartext but nothing else. So yes they could key off of "fast.com" but other sites where "/speedtest" is included would be encrypted.
(comment deleted)
Wouldn’t an obvious initial answer to this problem be open source and self hosting. That would for variation of the host name making it harder for ISPs to target this test for either positive or negative reporting. I’m assuming the test downloads and uploads a specific resource...
If you really want to check bandwidth between two devices, LAN or WAN, you should use iperf.

https://iperf.fr/

In Sweden we have ”Bredbandskollem” since around 2007 and with a mobile app since 2008. Not so many details, but it works. It’s supported by IIS (Internetstiftelsen I Sverige) which is responsible for .se among other things.

Fast.com - is 10Mb normal for 4G mobile connection?

This is great!

Fast.com has been my go-to site for speed-tests and sometimes for even rudimentary connectivity check. It dethroned speedtest.net as my primary speed-test service for two reasons:

1) I find typing 'fast.com' much easier and hassle-free than typing speedtest.net (aside from the fact that quick '.com' insertion through CTRL+Enter shortcut in Firefox makes it even snappier).

2) Netflix's wide self-run server network gives more uniform results, especially when testing from different continents, because 3rd party server providers -- in the case of Speedtest.net -- have sub-par performance, imo.

This feature is a welcome addition.

Interesting point: fast.com prefers my IPv6 connection, which is through a Hurricane Electric tunnel that Netflix won't serve. As a diagnostic for Netflix, that makes this useless.
It measures the speed against actual Netflix CDN servers, so how can it "prefer your IPv6 connection" for the speed measurement?
I have IPv4 from my ISP, and a Hurricane Electric tunnel to provide IPv6, because my ISP is lame. (Hello, Verizon FIOS.)

Netflix prefers IPv6. However, they have blacklisted the Hurricane Electric endpoints, because their paying customers with valid accounts might use those endpoints to view the content that they paid for while sitting in another country.

The blacklist does not take effect until you try to actually get video content from Netflix, at which point an error is returned.

The result of all this is that fast.com measures the speed of my IPv6 tunnel to Netflix CDN servers, which will not serve content. I have to turn off IPv6 routing on boxes in my house that want to watch Netflix, and then it falls back to IPv4... a completely different path than the one fast.com has just measured.

Oh, interesting failure case.
Can someone explain the difference between loaded and unloaded latency ?
Bufferbloat.net talks about this. The problem is that many home routers do a poor job allocating their resources so if I'm streaming video and you're VOIPing, your latency will go up dramatically since my download is pushing you out. In reality there's enough bandwidth for both of us, but it's getting used poorly. On my setup, loaded latency was over one second (to google.com) compared to under 50ms for unloaded! (Fast.com gives more mild numbers for loaded latency than I observed manually.)
Latency is a measure of how long it takes a packet to go from your computer to some other computer and back. People usually measure this by a ping test

Unloaded latency (when there isn't much traffic on your connection through your link to the ISP) generally ranges from 5 msec to 50 msec, depending on what kind of connection you have (fiber, cable, dsl, cellular).

Loaded latency is measured when there is traffic on the link. A good router will minimize the additional latency, but many routers will add a lot - between two and five seconds (2000 to 5000 msec). That's why you lag out in games.

In addition to the new Fast.com test, there are good tools for measuring loaded latency listed on the Bufferbloat page: https://www.bufferbloat.net/projects/bloat/wiki/Tests_for_Bu...

Why is it not a browser feature? Transferred 175MB just to measure the speed. Good it does not do it at 3G speeds.

There are also 156KB of images waiting to be compressed to one third of that [1].

[1] https://i.imgur.com/34SWfzo.png

https://speedof.me remains my favourite, although I still find myself using Speedtest at times because that's what everyone else uses and it's useful to pick a server that others are testing between on any given day.

Also, there are more links and alternatives under this discussion: https://www.reddit.com/r/sysadmin/comments/5mntko/other_alte...

Ultimately in most cases, I just want to know whether my connection is working or not. If it's working, it'll usually be in a certain ballpark. If it's not (or if I've accidentally left a VPN on), it's obvious.

My problem is that speedof.me seems to be on Amazon EC2 in a US West data center.

So for me on the East coast it's not really measuring my internet access, it's measuring my internet access across the whole country.

So using speedof.me I get a result of around 100Mbps.

Using Speedtest.net within my own city it's around 700Mbps.

Using Speakeasy with a Eastern server it's around 400Mbps

speedtest.googlefiber.net to Kansas comes in at around 300Mbps.

So in my opinion the speedtest you should be using is entirely based on who has servers closest to you physically.

Ironically, speedof.me is using a server in my country and gets 90 Mbps, and speedtest.googlefiber.net is using a server in Los Angeles and gets 150 Mbps. Peering is weird.

I'd love a speedtest that tests to whatever node you're using on all biggest CDNs (CloudFront, CloudFlare, Akamai, Google, etc)

The problem with peering is that cross country peering can cost a lot of money. So if netflix does not have any caching server in your country, they will have to pull bandwidth from the closest location and your isp might have limited peering agreement with that provider.

Which many ISP understansibly will refuse to icrease peering capacity and you end up with poor bw speed from netflix or other similar providers. The solution is to do what google does with GGC nodes. Netflix also has similar service but the are very stringent and picky with which ISP they give the servers to. Google basically gives them away to almost whoever asks for it. Not to mention with all streaming and cdn and cloud providers wanting to have their own ggc like hardware at ISP premise it puts cost strains to isp in terms of power usage, rack space and high-output switch and routers at the distribution end. Not to mention all of these hardware will pull bandwidth from source (about 20%) which will come through ISPs expense.

People often like to blame ISPs. While big ISPs have legitimate problems. It also makes it extremely difficult for smaller isps bear this cost and provide service parity compare to ISP giants. Which is why you don't see a lot of isp business popping up. There is a reason google fibre is so limited in scope.

It always facinates me how most ISPs makes money at all. Then i realize the one who do has been doing it for a long time ans were already big companies when started out and probably had to take substantial loans and help from government and even then it probably took them a long time to be profitable.

The difficulty in creating an ISP is all in the last mile, not in peering.

Where I live there are 100+ ISPs since there's a national fiber network anyone can plug into, so to start an ISP all you need is a router and some peering.

I was talking about international peering. If you are in USA/Europe, it's not much of an issue. Outside of that, the situation gets murky. Local ISPs don't do international peering, they piggyback on other, whose peering capacity is almost always oversold.

Yes, the last mile is the biggest expense, but other costs are not small either. An ISP with a couple of 1000 users are just reselling BW from someone else. They are at the mercy of their upstream's peering. I wasn't referring to them.

I own an ISP outside the developed nation.

Awesome! But they should add PWA support so you can add it to iOS home screen.
You already can in the share sheet. I have had it on my home screen for a couple years. It has the right kind of icon, too.
Thank you so very much for providing latency-under-load statistics; this is excellent.
Well, I'm getting 10-14mbps down from Fast.com and 50mbps down (as advertised) on speedtest.

Looks like Netflix is indeed being throttled here. What's interesting is that we haven't noticed any issues with speed while watching netflix.

What are your speeds on unrelated downloads? Without any other data points, one could also make the assumption that Speedtest speeds are being fudged by your ISP, while fast.com is showing your real bandwidth.
Which I believe is the whole point of fast.com - to give you a more realistic measure of your actual bandwidth.
Interesting. When I check the "Measure loaded latency during upload" option my Loaded Latency value goes up by about two orders of magnitude.

Is there a way to fix this? Seems like there ought to be some sort of traffic shaping measures I could apply at my firewall (I've got a dedicated box running pfSense) to ensure low-latency applications get sufficient bandwidth during upload.

This issue is generally called "buffer bloat". That keyword should help you find solutions. I think it's generally QoS to limit aggregate upload bandwidth to less than your available so the buffers don't get (over-)filled in the first place.
How come there isn't a speed test site that test closest and furthest away servers and averages them?
As a couple of other folks have noted, lots of ISPs prioritize traffic to (some) known speed test sites, so differing results from different speed tests -- and results that differ from real world experience -- are pretty common.

Even weirder, sometimes this traffic prioritization happens partly in the firmware of the modem the ISP provides.

On one of our test network connections, we can reliably trigger a firmware issue in the router that causes very high packet loss. Then we can "fix" the issue by visiting www.speedtest.net from any computer on the LAN behind the modem.

(My company makes in-browser video calling stuff, so we spend a lot of time worrying about network connectivity.)

And speaking of packet loss, I'd love to see Netflix add a measurement for UDP packet loss at several throughput levels. There's no easy way for non-technical users to do a really good packet loss test.

We often get customer support queries that say something like, "My video calls are terrible but it's not a network issue because I did a speed test and I'm getting 100Mbs." Which is a totally reasonable thing to say. But when we look at call data, the person is experiencing regular spikes of, say, 15% packet loss. That's not something that will effect web browsing noticeably, or even Netflix video very much, but it makes for really frustrating video calls.

I still say the greatest trick the ISPs ever performed was getting customers and content providers to both pay. I don't mean simply the content providers internet bill I mean backbone providers and large orgs like Google and Netflix paying to connect with an ISP. They double dip already and with net neutrality gone they can now make even more by charging both for "premium" services on top of regular charges.