4 ms·

Unlikely your suspicions are correct. Provisioning high QoS to the speedtest site is common practice (see fast.com for countermeasures), but changing the entire

Unlikely your suspicions are correct. Provisioning high QoS to the speedtest site is common practice (see fast.com for countermeasures), but changing the entire subscriber QoS because traffic to one particular destination is detected seems like too much work and doesn't really achieve anything useful. If you are on a wireless network (either your upstream from a WISP, or internally on your own network), then I'd suspect some wireless air access control syndrome is the cause -- e.g. stations are usually randomly fighting for air, but when you pull down your big speed test file that ends up putting the network in a state where your station gets all the air time. Lo and behold all your traffic has better QoS. Basically your speedtest traffic, because it is a constant stream, shoved everyone else off the air and allowed your other traffic to get through at the same time as a result.

bragr 5y ago
This should be easy to test. Find a a big file somewhere served reasonably fast and see if you can replicate the results while pulling it down. Maybe some Linux distro ISO? I really doubt an ISP would optimize that.
semi-extrinsic 5y ago
> and doesn't really achieve anything useful At my previous apartment, I would get a full month rebate off my internet bill if I could document speeds considerably below average on a computer plugged in with ethernet. I could very well see an ISP with such a policy looking for nefarious ways to "fix" that money loss.
- KMag 5y ago
  There's that, and also visiting a speed test site is an indicator that a particular user is more sensitive to speed than the general user base (and perhaps considering jumping to another ISP). It absolutely makes business sense to prioritize traffic to users who pay more attention.
  - kortilla 5y ago
    No, as an isp these are the worst customers. It’s better to piss off an dump people who consume a lot of bandwidth an are obsessed with throughput if you’re “business obsessed”.
    - KMag 5y ago
      I'm assuming "an" is a misspelling of "and". If they're using lots of bandwidth, that's one thing, but I sometimes see 480p YouTube videos laggy and wonder what's going on. Maybe I'm in the minority, but there are at least some customers who aren't using a lot of bandwidth and still check their speed regularly. Dumping bandwidth hogs makes business sense, and bandwidth hogging is probably correlated with checking bandwidth, but the correlation isn't 1.0.
    - throwaway290 5y ago
      In the US most people are reportedly served by a single ISP and cannot really choose. ISP that intentionally pisses off speed-sensitive customers would be sued in no time.
iancarroll 5y ago
> changing the entire subscriber QoS because traffic to one particular destination is detected seems like too much work and doesn't really achieve anything useful Unless something has changed recently, the Speedtest site just acts as an intermediary between you and one of the "volunteer" servers that actually perform the test for the client. Since these are hosted on many networks, it's conceivable that this is the easiest way to QoS the speed tests.
majewsky 5y ago
> but changing the entire subscriber QoS because traffic to one particular destination is detected seems like too much work and doesn't really achieve anything useful. About seven years ago, when unencrypted HTTP was still commonplace, I observed exactly this behavior (subscriber-wide QoS based on speedtest sensing) with my residential cable internet. My connection was nominally 100 Mib/s, but I would often observe downloads e.g. in Steam running at only 10-20 Mib/s. In those cases, I would open up a terminal and run while sleep 1; do curl http://<one-of-my-domains>/speedtest; done Didn't matter that this URL would give 404. Just because the URL contained "speedtest", the ISP machinery would adjust the QoS and the Steam download would immediately shoot up from 10 Mib/s to nearly the full 100 Mib/s. By now, this has not worked in a long time. I'm guessing they tore down the respective machinery once the important speedtest websites moved to HTTPS.
yareth 5y ago
From my experience about 8-10 years ago when the shaping hardware was not that flexible a lot of ISPs analysed the traffic and changed shaping routes dynamically which usually reset the shaping for the local ISP network segment (coaxial networks). This resulted in exactly what OP describes. I was surprised about how a lot of stuff in networking I quickly dismissed at first was actually reality.

bragr 5y ago

This should be easy to test. Find a a big file somewhere served reasonably fast and see if you can replicate the results while pulling it down. Maybe some Linux distro ISO? I really doubt an ISP would optimize that.

semi-extrinsic 5y ago

> and doesn't really achieve anything useful At my previous apartment, I would get a full month rebate off my internet bill if I could document speeds considerably below average on a computer plugged in with ethernet. I could very well see an ISP with such a policy looking for nefarious ways to "fix" that money loss.

KMag 5y ago
There's that, and also visiting a speed test site is an indicator that a particular user is more sensitive to speed than the general user base (and perhaps considering jumping to another ISP). It absolutely makes business sense to prioritize traffic to users who pay more attention.
- kortilla 5y ago
  No, as an isp these are the worst customers. It’s better to piss off an dump people who consume a lot of bandwidth an are obsessed with throughput if you’re “business obsessed”.
  - KMag 5y ago
    I'm assuming "an" is a misspelling of "and". If they're using lots of bandwidth, that's one thing, but I sometimes see 480p YouTube videos laggy and wonder what's going on. Maybe I'm in the minority, but there are at least some customers who aren't using a lot of bandwidth and still check their speed regularly. Dumping bandwidth hogs makes business sense, and bandwidth hogging is probably correlated with checking bandwidth, but the correlation isn't 1.0.
  - throwaway290 5y ago
    In the US most people are reportedly served by a single ISP and cannot really choose. ISP that intentionally pisses off speed-sensitive customers would be sued in no time.

iancarroll 5y ago

> changing the entire subscriber QoS because traffic to one particular destination is detected seems like too much work and doesn't really achieve anything useful Unless something has changed recently, the Speedtest site just acts as an intermediary between you and one of the "volunteer" servers that actually perform the test for the client. Since these are hosted on many networks, it's conceivable that this is the easiest way to QoS the speed tests.

majewsky 5y ago

> but changing the entire subscriber QoS because traffic to one particular destination is detected seems like too much work and doesn't really achieve anything useful. About seven years ago, when unencrypted HTTP was still commonplace, I observed exactly this behavior (subscriber-wide QoS based on speedtest sensing) with my residential cable internet. My connection was nominally 100 Mib/s, but I would often observe downloads e.g. in Steam running at only 10-20 Mib/s. In those cases, I would open up a terminal and run while sleep 1; do curl http://<one-of-my-domains>/speedtest; done Didn't matter that this URL would give 404. Just because the URL contained "speedtest", the ISP machinery would adjust the QoS and the Steam download would immediately shoot up from 10 Mib/s to nearly the full 100 Mib/s. By now, this has not worked in a long time. I'm guessing they tore down the respective machinery once the important speedtest websites moved to HTTPS.

yareth 5y ago

From my experience about 8-10 years ago when the shaping hardware was not that flexible a lot of ISPs analysed the traffic and changed shaping routes dynamically which usually reset the shaping for the local ISP network segment (coaxial networks). This resulted in exactly what OP describes. I was surprised about how a lot of stuff in networking I quickly dismissed at first was actually reality.