Ask HN: Internet magically gets faster when opening speedtest?
I want to start by saying this is anecdotal, and I feel paranoid for even thinking it. But often my internet will feel very slow, so I'll open speedtest to check if something's wrong. When I do, all of my stalled tabs suddenly spring into action and finish loading.
The tinfoil hat wearer inside of me speculates that my internet provider is overloaded and throttling my bandwidth, but immediately prioritizes me when it senses that I'm trying to check if I'm getting what I pay for.
Has anyone else noticed this pattern? Is there a way I can test this more scientifically?
355 comments
[ 3.1 ms ] story [ 228 ms ] threadNow reload the page and and run it again but as soon as it starts, open another tab and do some browsing.
The second test gives me higher speeds consistently.
Some background: If you study traffic shaping, you'll discover that TCP behaves poorly if packets are simply dropped when throughput approaches the limit (congestion collapse). So traffic shaping usually _delays_ packets rather than dropping, at least initially. This works in that TCP backs off its send rate gracefully and throughput approaches the provisioned limit. However you've now introduced a large delay into every packet's transit through the shaper box. This isn't a problem for bulk TCP flows -- they work ok in the presence of latency but it is problematic for unrelated latency sensitive traffic (e.g. UDP, SSH). To work around this problem traffic shaping usually introduces some notion of delay per flow. This can be done in a few different ways e.g. RED (random early detection), or per-flow queues.
Ok so back to Spectrum: my experience has been that their shaper box does not do anything good as far as per-flow queues, RED etc. It seems pretty basic and dumb. The result is that latency approaches infinity as throughput approaches the provisioned limit.
I work around this by deploying my own shaping on my edge router. Through experiment, I have configured it to limit at just below the threshold where Spectrum begins severely delaying my traffic. I use RED on my router to give good latency for traffic unrelated to bulk flows. You'll need a router capable of traffic shaping, e.g. Mikrotik, Linux iptraf, Cisco IOS.
Other than that, you're 100% correct on Spectrum's ridiculously high buffer sizes on their end.
[1] https://tcpcc.systemsapproach.org/aqm.html#controlled-delay
[2] https://www.bufferbloat.net/projects/codel/wiki/CakeTechnica...
while : do ping speedcheck.org ; sleep 10 ; done
Fast internet forever!
https://www.speedtest.net/apps/cli
However I have fibre now, and it’s glorious. No crap scripts required (though it still runs!).
You can check here: https://www.dslreports.com/speedtest
The old copper required some ISP work which required a person to go up the pole at least once a month and often once a week. It was absolutely terrible. The guy who came told me there was water in the cable, but the details of what that means are beyond my understanding.
For example you could do something with Image.onload event, but even better are the recent JS web performance APIs, they provide a huge amount of detail - including DNS lookup latency, TCP connect time, TTFB etc.
Actually now I want to build this
edit: I'm probably not going to build this, but you should. For large object sources, there are Flickr full size images, HLS URLs for video on demand systems (each HLS segment is generally around 1-3MB), etc.
I'd want a giant list of these to pick from at random, and probably want to bucket the results along (domain name, destination BGP ASN, destination GeoIP) axes as well as whatever the JS performance API offers. You could maybe present each axis as some kind of confidence interval, then geometric mean to produce an overall score presented graphically somehow
You could then collect up all these scores and publish stats bucketed by Internet provider. And that's the point where I realized I don't have the energy to build all this ;)
It just downloads data from Netflix servers, so the results you get are basically guaranteed to be the speeds you would get with Netflix.
Or maybe the idea was that Netflix would get the speedtest treatment.
If ISPs want to make fast.com fast, then they need to do so for all of Netflix.
I’d say that this needs some sort of regulation, but as long as ISPs are the gatekeepers, they can cheese $Government all day long too. This word gets overused perhaps, but the closest I can come up with is a decentralized monitoring setup with random speed test hosts (especially hosted @home style). Care would have to be taken to avoid how-are-these-still-legal data caps though.
Eg. http://134.209.196.181:8080 This is an instance of https://github.com/e7d/speedtest running on Digital Ocean in Amsterdam.
That's reasonable, actually pretty impressive for talking to Amsterdam
It's hard to really comprehend how amazing it is that I can talk to Europe at 200M/s over WiFi from my personal apartment on my smartphone while lying in bed in Los Angeles, and pay a flat rate that works out to about $2.25/day for the privilege.
It's just absurd. It's pretty easy to forget how much of a future world we live in
https://www.ams-ix.net/ams
You should try if possible connections to other pages in other countries.
Running certain online games in the background (I think it was final fantasy) fixed problems with the art/drawing/just chatting stream dropping frames.
(Sorry I forget who, I also think it wasn't someone I normally watch so it's unlikely I will remember.)
This could be an interesting business model for a VPN service. Host a popular speedtest and VPN endpoints on the same IP's. The challenge is to make the speedtest popular enough so ISP's will optimize for it.
Then added a wire connection to my server and instantly 10x the speed :^]
Dont be like me, have wires set up everywhere where needed.
This holds true in the same room and one room over.
I like this.
802.11ax is much faster than that, my wifi router is good for 1.5G or so while the protocol allows for 3.5G or so and my file transfer speeds are easily more than 125 megabytes per second
I’m not going to run more wires either way
So……. you sure I should care?
Its great fast speeds that scale to the file sizes I want to handle, which are pretty large for prosumer needs.
Speedtest kept reporting 100Mb/s range speeds (the tier he was paying for). Local file transfers however were stuck in the 1MB/s range.
After some questions and troubleshooting he discovered that he had used a 10Mb/s hub instead of a 1Gb/s switch that was sitting right next to it. A simple mixup.
His internet connection was also plugged into that same 10Mb/s hub.
There is NO WAY his PC could have reported 100Mb/s to speedtest.
Do not trust them for accurate results.
I read that speed test reported 100Mb/s and local files were receiving 8Mb/s (1MB/s). Either interpretation doesn’t change the intent much. But now I’m curious if the MB was intentional.
I don’t really care what the normal convention is, but the fact that Mbps and MB/s are sometimes used interchangeably does cause confusion, especially outside this environment.
Was the choice to use Mbps as a standard a marketing idea? Like they have 1 MB/s? Well we have 8 Mb/s.
Does not compute. Compression? I can't explain the lower ping, traffic shaping?
Better routes. Most latency on the internet is not due to c.
tl;dr timeout was sufficiently low and user sufficiently skilled to work out his emails could be delivered only within 500 miles
Ookla speedtest properly transfers data and divides to find throughput-- both with the website, the GUI app, and their CLI program. The open source speedtest-cli that uses their infrastructure is hampered by only one connection and can't seem to ever report higher than 300mbps.
Fast.com is ... a little optimistic about transients getting transfers started and sometimes reports numbers 5-10% too high.
Neither is grossly wrong by an order of magnitude. Maybe there was also wifi around and simultaneously connected, confounding the situation? Easy to end up in a situation where all your internet traffic is going over wifi (because e.g. your dhcp client replaces the default route with one going over the wifi interface), and all your local traffic goes over ethernet.
I routinely get 700-900Mbps reported using speedtest-cli from centurylink fiber. My bottleneck is the CPU on my router running openwrt.
https://news.ycombinator.com/item?id=31063868
From speedtest's official cli program, on my 2.5gbase-t connected machine I get 2200mbps up and down.. but from the open source speedtest-cli I get 300-350mbps.
(Here, I only got ~900mbps because I was running from a raspberry pi with a 1000BaseT link).
I _do_ get limited to around 300mbps if my Mikrotik is in the mix and using CPU for routing.
Yeah, my home network is overkill but it's a cheaper hobby than other ones might be, hah.
You're using their cli client, not the open source one. Below, first their "speedtest" and then the open source "speedtest-cli"
vs. speedtest-cli is a python program, vs. the native speedtest:On the pi, I suspect it's running out of CPU--
But that doesn't explain the systemic problem.I'd assumed it was just something intrinsic.
On the other hand: speedtest's own thing uses multiple parallel connections. So if you have low amounts of loss that prevent one TCP connection from going super fast, it'll do better on speedtest than speedtest-cli.
Thanks for the help/info. Something to spend more time understanding at some point in the future.
edit: Just noticed that the Hetzner server in VA geolocates wrong and chooses servers in Kansas.
This is a common failure mode of geolocation, especially as it pertains to cloud providers. The databases can guess which country the IP address corresponds to, but not anything more (and as such, they default to something in the middle of the country).
https://en.wikipedia.org/wiki/Geographic_center_of_the_Unite...
Geolocation data tends to be worse for cloud providers for whatever reason (I believe it's a combination of differing Internet footprint characteristics, as well as IP aggregation mismatch on behalf of the geolocation database).
(Also see https://en.wikipedia.org/wiki/Null_Island for another common geolocation placeholder)
This is a problem of their own making. They can't have their cake and eat it too. Comcast has a monopoly in my area for high speed internet. Every other option is 25mbps(on a good day) or below. Comcast has shut down all potential competition.
So yea if they want to be a regional monopoly they might have some regulations placed on them they don't like.
My experience from working at fiber ISPs is that the infrastructure is the hard part. Google Fiber got a good deal in its partner cities to run the fiber next to existing power lines (which not every city has, they're all underground here). When they ran out of easy install opportunities, expansion stopped. My experience was the same at a NYC-based ISP. If your building was on a street that already had open access tunnels, then we could serve you. If not, you were out of luck.
If you figure out how to profitably get wires to people's houses, you solve the ISP's problems. I've seen proposal after proposal for trenching, microtrenching, nanotrenching, picotrenching, attotrenching... and none of these worked in the real world. (I might have made some of those up; I think "attotrenching" is what I called just running cables into people's windows and not burying them. Didn't try it, but I imagine it would irritate people with its intrinsic flakiness and ugliness.)
The rest is simple, you can set up a full fledged fiber ISP for under $1000 in equipment! Figure out how to dig up the street profitably and you unlock a ton of wealth. (This, incidentally, is why people keep trying to sell wireless solutions. No streets to dig up. WiFi with pringles can antennas! 5G! A huge constellation of satellites! And honestly, it kind of works. But not so well that people are switching from their fiber connection to Starlink or whatever.)
The same way we got power to the homes which was government assistance and the private companies not expecting them to be totally profitable in a few years.
Same as they did with electricity a century ago. If you want to provide service to the profitable urban area then you must run wires to the non-urban areas too.
Their business model seems to be using sales volume to make up for marginal losses.
I've had mixed experiences with them. The wireless link itself tends to be 100% uptime with no bandwidth contention. The quality of the network between the tower and the internet backbone varies wildly depending on the ISP.
Anyway, last mile of 10's to 100's MBit symmetric over multiple miles is a solved problem these days.
The remaining problems are mostly political. Sadly, that's been true since dial up modems became obsolete.
Behold, MSU dorm LAN in early 2000s. https://medium.com/@pv.safronov/moscow-state-university-netw...
Partial “topology” shot: https://chronicles.igmsu.org/wp-content/uploads/2015/10/topo...
Home LANs and early ISPs were built with the same equipment by the same kind of enthusiasts. Typical commieblocks have enough place for cable shafts inside, though. Then the building roofs would get connected (with any kind of cable having any properties you could find) in the same grassroot manner. All that free libertarian enterprise, and now, after a number of tech upgrades, mergers, and so on, you can get gigabit for ten bucks.
I get it's not that suitable for suburbian installations, but the idea is that it all starts small and ugly. That's why your cable corporations are never ever going to allow even a tiny bit of alternative to happen, heh.
That's the double edged sword in the US of having executive level departments with wide latitude to set regulations with the weight of law behind them but not the same high barrier of changing them as it takes to change a law. Technically this allows agencies to be more nimble, or as much as possible in any lumbering bureaucracy. On the other hand it means that very important pieces of public policy are even further removed from election accountability and subject to the whims of different administrations.
Whether you're for or against it, the Keystone pipeline is a prime example of the insanity that results from this. It was approve & construction begun on one administration, a final portion for it put on hold by another, then opened again by a third, a fourth stopped it again resulting in its backers cancelling it (seemingly) once and for all. Forget about the difficulties of generation-long projects, this makes anything longer than 4 years highly uncertain.
This seems like a feature not a bug.
Popular policies around the issue created by legislative statute instead of agency rules would have been a lot harder to repeal.
You can also look up "name of area / state" and search for electrical tariffs.
The reason I am asking: unless there are such subsidies, it would mean that people pay proportional to their usage, so OP's joke about "electricity neutrality" would not only be wrong, it would be against net neutrality as well.
Such things are complicated to figure out fully, the subsidized power might not be subsidized directly by the power generators / power distributors. In some cases two bills are generated for the duration of the power subsidy so the subsidized part only sees the subsidized rate.
Probably not, as it has nothing to do with where the electricity is coming from or how it's being used. Having different rates for different times of the day which still apply to all users and all services is not generally perceived as a violation of neutrality.
The point of net neutrality is that ISPs should ignore the content, source, and destination of the packets they carry when it comes to prioritization and pricing. QoS is fine as long as it's under the subscriber's control (for example, via DSCP tags), but it can be an issue if it leads to the ISP one subscriber's traffic over another's based on the services being accessed. Tiered services (paying for higher bandwidth, lower latency, etc.) are also fine so long as the tiers assigned to each class of traffic are chosen by the subscriber and not tied to specific protocols or peers.
Consider the USPS as a model of neutrality: they offer various grades of service from bulk package deliveries to Priority Mail but everyone paying for the same service gets (more or less) equal treatment.
I'm honestly surprised at the backlash against net neutrality on here.
They changed the definition of local after crypto miners flooded in to limit exploitatiom and boom/bust speculation.
On mobile most plans are already "limited", but that hasn't given us net neutrality on mobile.
Electricity prices are dominated by supply vs. demand. There are many sources of electricity available, some of them being very cheap (hydro) some of them expensive (currently gas).
When demand for electricity goes up, the cheap power sources are going to be running at capacity, and utilities will need to buy more expensive power. This increases the marginal cost of electricity for everyone.
So just because Bitcoin miners pay for electricity, doesn't mean we aren't subsidising them. We are subsidising them by paying more for imported power even though our needs could easily be covered by cheap, local power sources.
The way to fix this would be to charge progressive prices depending on usage, ie. every person gets to use 1000kWh at the cheap local hydro power price, then the price increases gradually, and any electricity usage beyond 10000kWh/person/year you need to pay the full market price of electricity.
Internet access is typically billed as "unlimited" so those who use it very little pay a high rate per bit transferred, while those who use it a lot pay a low rate. Some of this is due to the base cost of providing service (fixed last-mile connection costs incurred whether the line is used or not) but the rest is a subsidy from low users to high users. How much of each is debatable; the costs of home internet are largely concentrated in the last-mile connection costs rather than bandwidth and data centers, yet the bandwidth still isn't free.
It's really the same thing as in the flat rate case. It's a bit less unfair since the cost rises linearly, but it's not enough to leave small consumers unaffected. People who consume small amounts of a utility still pay more because of people who consume a lot.
No, they really don't. People consuming small amounts and large amounts both pay more due to higher aggregate demand. If it weren't for the many small users the aggregate demand would be lower and the large users would also be paying less—do you consider that a subsidy in the opposite direction? No, of course not—because a price being bid up by competing consumers is not what is meant by the term "subsidy".
Now, if you banned large users from the system, or imposed discriminatory pricing as you previously suggested for the purpose of keeping prices low for the small users, that would be a subsidy: interference in the market to benefit one group at the expense of another.
It also costs more money to support higher bandwidth of network travel. But unlike with electricity, there is no cost (to network providers) to generate the data, since the data is usually paid for by the source. This means the average consumer doesn't get any of the benefit of the increased pricing -- it has not changed how the internet providers charge to consumers at all, only how they charge content makers. And customers who like the content get increased costs on top of that.
Therefore, I don't see any benefit by removing net neutrality -- it can only hurt consumers. If it only benefits network providers, why should I support it?
With internet, where the data comes from and goes to is the whole point.
Anywhere in the world there are local and global popular services that generate high volumes of traffic. Providers naturally care about getting shortest paths to them, plan in advance, join local exchanges, and so on, even if they don't have any direct agreements. For starters, it might lower your traffic costs. In some locations there are mid-tier ISPs offering just good connectivity with all locally popular networks; they offer the solution for low-tier ISPs for some extra coins. However, it is hard to imagine that some ISP would try to make the big source of traffic pay for what has already been paid by customers.
Complete nonsense. "Net neutrality" means that there is no preferential treatment of packets based on origin or destination.
> However, it is hard to imagine that some ISP would try to make the big source of traffic pay for what has already been paid by customers.
I think you need to work on your imagination. ISPs in the USA have already tried this (not sure if it is still happening).
Categorically false. There’s no “net neutrality” legislation enacted or proposed that doesn’t have giant and vague QoS and general network operations carve-outs.
https://www.eff.org/deeplinks/2015/02/huge-win-open-internet...
In 2018 Markey and others proposed simply overturning Pai/Trump's overtuning of Title II.
I don't know precisely what you're referring to ... the closest I could find was the EFF's objections to the FCC proposals from 2011 which had things like "vague QoS and general network operation carve outs":
https://www.eff.org/deeplinks/2011/02/pt-ii-eff-evaluates-fc...
The EFF seemed much happier with the FCC proposals 4 years later.
What am I missing?
Which is utter nonsense for any large service provider that requires traffic engineering to handle elephant flows.
This is the problem with blanket slogans, they constrain the network in ways that impact user experience dramatically, and is why a LOT of internet pioneers oppose net neutrality.
Encouraging open access networks seems more striking at the heart of the matter.
https://blog.cerowrt.org/post/net_neutrality_customers/
https://blog.apnic.net/2020/01/22/bufferbloat-may-be-solved-...
As for the latter, my point was exactly that in “normal country” it's hard to imagine, but giant corporate clashes managed to turn this into some big argument about “freedom”.
Disagree with the premise though, Netflix has fast.com to make it transparent to customers that their NETFLIX volume is being throttled, and hence providers naturally do not throttle Netflix
No, I remember the opposite.
Netflix argues for net neutrality because that forces last-mile internet providers to absorb the bandwidth costs of Netflix's business model.
https://www.theregreview.org/2021/11/10/kim-can-netflix-win-...
' In the original claim, Netflix v. SK Broadband, Netflix invoked a net neutrality argument—based on the idea that internet service providers should treat all content equally—and argued that SK Broadband would discriminate against Netflix by imposing high network usage fees. Netflix also argued that SK Broadband should cover the increased costs of network traffic since it has an obligation to provide internet services to its customers. '
Downside: if you have any kind of home network, running your own recursive DNS probably implies running your own DHCP, which isn't normally a consumer alternative (you could do it using settings on a domestic router, but not if it's crippled or locked-down). Also, DNS caching shouldn't be so effective (but I haven't noticed that effect).
Upside: all kinds of problems resulting from relying on DNS servers controlled by others disappear. You're not relying on them any more.
I happen to trust my ISP, BTW; I really just like running my own because I can observe what it's doing.
Unless you can prove otherwise you should assume they're selling you out.
Though you need a trusted host to act as the other end, or you are just swapping one monitored link with another, and finding that could be a task in its own right depending on your threat model / paranoia level.
Nextdns have their own app for this as well.
For android 9 or higher there should be an option in network settings.
Yes you could do a timer, but that would mean e.g. first 30s of all Netflix streams to be much faster and then slow down just in case they were in fact speed tests. Also would be difficult to differentiate between running a speed test vs a stream that gets its connection closed and reconnects.
All of this is an order of magnitude for ISPs to deal with than unthrottling traffic for specific domains. It doesn’t have to be perfect, but making it prohibitively more expensive helps a lot.
2. ???
3. profit
EDIT: Here's what I was thinking of: https://openconnect.netflix.com/en/appliances/
My ONT only supports gigabit out, so I can’t test faster options. That said, fast.com has told me I’m getting 1.2gbps recently…
that being said, getting a higher burst speed still makes browsing the web a much more pleasant experience, so it's not like they're just gaming the speed tests.
Maybe this could even be a standalone service
It’s unlikely they would do something more complex like lifting all traffic limits once a connection to Speedtest.net opens.
It’d be great if they could be more methodical and track down what’s really going on. I’d also wouldn’t be surprised to see an ISP doing something like this, but at the same time, it’s much more likely to be networking issues on the consumer’s side than a malicious ISP imho.
So, any slow connection would stop the entire household from having decent internet.
Pretty sure many ISPs do something like this - especially on mobile. If you have access to a prioritized phone, the side by side comparisons are pretty interesting.
Also make sure nothing else is consuming your total upstream bandwidth. With asymmetrical bandwidth, TCP acknowledgements that get choked out or buffered will limit your downstream bandwidth too.
For example, Visible will never be faster than 2 Mbps to fast.com.
You’ll get faster on Speedtest.net because it doesn’t throttle non-video related sites.
Cloudflare runs one too. https://speed.cloudflare.com/
Those are all harder to game than speedtest.net
So much of the web is behind cloudflare that most ISPs are unwilling to prioritize traffic to it. It also loads a selection of dummy files of varying sizes which is a more realistic portrayal of normal internet usage than a single stream of data.
Monitoring the NIC rx is the most accurate in my experience.
Perhaps there is a confusion between megabytes, and megabits.
While stumbling around attempting to figure out `tc qdisc` a while back I found that the shaping it was applying was very synthetic, such that asking for low bitrate and high latency would mean the kernel would just wait a second or two then shunt several KB of data through at once. IIRC I was just playing with the default approaches you'd find bandied about on tutorial websites and such. (I'm still looking for a way to synthetically limit a link in ways that are physically accurate.)
Remembering that experience got me thinking - without any idea what I'm talking about, I'm wondering if the PHY layer is doing something vaguely similarly stupid-simple that does technically limit the line rate to 10Mb at full blast, but still allows throughput to very briefly burst higher than that.
I think speedtest websites try to measure both the burst rate and the line rate, so perhaps something's gotten very tangled up on both the PHY and JS sides.
Now I'm curious what model PHY (well, NIC) you're using.
FWIW, Chrome's devtools has a network rate limiter built in (network tab, dropdown that says "No throttling", open that and hit "add"... aaaand remember that it's persistent (for just the tab) until you turn it back off :) lol)
Edit: Just found https://news.ycombinator.com/item?id=31063184 downthread describing seeing 100Mbps through a 10Mbit hub. I think you've either found a technical bug or a, uh, "the speedtest is good so my internet must be fine" "bug" (which would be very interesting).
Using Chrome's limiter, capped at 5,000,000 bits/sec (5Mbps) both direction: Speedtest.net: 5.00Mbps in both directions (nice, are they're including overhead in these calculations?) Cloudflare: 4.80Mbps downlink, 4.81Mbps uplink (well, it's true now) Fast.com: 5.0Mbps downlink, 58Mbps uplink (holy crap, that's not what I've expected)
So I will re-test Cloudflare again at link-limited PHY, but Fast.com's test seems a little weird.
Well it probably was 10M then. The port LED on the switch might've changed color as well. (Smart reminds me of the consumer-lite answer to SDN.)
I just tried fast.com myself using 100kbps and it quite happily measured at line rate (6.8M+800k, yay D:). For some bizarre reason I found I needed to open a new tab, open the devtools, set the network speed, then load fast.com for it to work. My guess is that Chrome applies connection ratelimiting metadata as new connections are created, such that existing sockets still in keepalive aren't affected. I'd say that's at least a documentation bug.
I'm not really able/sure how to reproduce the other comment I linked (using an actual 10M switch and seeing 100M of throughput). That's really interesting.
[0]: http://www.dslreports.com/speedtest
In reference to gaming the system one can also run iperf3 on ports used by https, voip, common bittorrent and other service ports to see if the ISP is blindly traffic shaping on ports by means of different behavior per port.
I gave up with cots routers a while back, and life has been significantly improved. I wrote it up here https://res.rag.pub/2020-11-1-an-home-router.html
But also worthy of recommendation IHMO is the Cloudflare one (speed.cloudflare.com). Main reason I say that is its one of the few that measures jitter (or at least openly exposes the measurement).
It does but it's hidden, you have to hit "Show more info" (once the main test has finished).
A bit stupid, but I'm sure some committee thought it was an awesome idea to do it that way.
Is it after the speed test is over?
Yeah, you have to let it run thorough first, then the button appears.
(At least on desktop, I can't remember what it does on mobile)
[1] https://mirrors.edge.kernel.org/archlinux/iso/2022.04.05/arc...
Or the cabling to the cloudfare server is worse than to other servers
I'm looking at the network tab, it seems like they send a ton of small requests instead of a large one... which might point in the direction of the problem.
[1] https://syd.mirror.rackspace.com/archlinux/iso/2022.04.05/ar...
Example: Rackspace Sydney (AS58683) has (likely paid) peering with AS7474, who has peering with German Deutsche Telekom (AS3320). Peering with DT is significantly more expensive than many others because they have a regional monopoly.
* Cloudflare is present at many regional Internet Exchanges and any good ISP connects to these, too. Some don't, however, like Deutsche Telekom.
Nice to see the tests are breakdown with more info when hovering or expanding them.
How about the following?:
1. Choose a dozen or so public files on hosts known to have high bandwidth (Google or Microsoft perhaps). Maybe choose a couple of public legal torrents too.
2. Write a script to download all the chosen files (either sequentially or concurrently), and emit timing information.
3. Run that script a couple of times a day at random times. Try to cover weekdays and weekends, days and nights.
4. Repeat 3 but running a speed test first each time. See if there is any statistically significant difference.
I help manage a system that does something like this for a large network operator. We have test phones that run TWAMP, RFC 6349 and iperf (and a few other tests) on a routine schedule to special test servers. generating data which you will never ever see.
But you could do something similar if you had the desire. I have yet to see anyone do that yet.
All network providers have various throttling systems set up to limit your throughput, that is pretty universal, and, most of such systems are intentionally bypassed based for speed tests. They know the 5 tuples for all the speed test servers and bypass throttling for those test.
Yes, speed tests are rigged, think, Volkswagen Diesel, an inside joke pretty widely known in the industry.
My ISP does the prioritization whenever you do a DNS lookup for speedtest.net. You don't actually need to run the test.
Another speedtester you can try: https://www.dslreports.com/speedtest
however, due to this, https://www.waveform.com/tools/bufferbloat was born. they mention this along with their specific reasons in the FAQ on the linked page.
so, update your bookmarks and plan to continue spreading the good word with this new provider in place.