4 ms·

I suspect that your line has a configured limit as opposed to physical limit of 250mb/s (perhaps the fibre equipment is capable of 500mb/s or something). I've

I suspect that your line has a configured limit as opposed to physical limit of 250mb/s (perhaps the fibre equipment is capable of 500mb/s or something). I've seen this ever since I moved to fibre about 8 years ago, I've never taken the fastest packages and whenever I test on speedtest.net it always starts off exceeding my limit, then comes down to my limit over a short while. The limiter for you may very well allow you to burst for a limited duration, so your speed on 1MB files are possibly at 440mb/s, but once you have sustained line usage it brings you down to your limit. I wouldn't know if this is an intentional feature or just because of how the limiter solution is implemented that it needs to sample over a certain period of time. It is a slightly useful behaviour if you're browsing the web and only occasionally clicking links which land up being downloaded way faster than your normal limit, but as you're only getting this speed if you do little to nothing for the 10s or 100s of seconds between opening pages, it doesn't have any negative effects over all.

jnsaff2 3y ago
I have seen similar shaping. This gives a quick responsive browsing experience but throttles bigger downloads/streaming. It also can be implemented badly. Azure VNET peering had 200M level and 100M level. Where 200M level was 200M most of the time, whereas 100M level was 200M for 30s and 0M for the next 30s.
bombcar 3y ago
It’s actually quite a hard problem to limit a fast physical connection to a slower speed for a burst - so much so that some tests are much easier with an old 10/100 hub. What’s nice is when you pay for a certain speed and they give you more if nobody’s using the excess. That’s more rare now but still can be encountered, especially on upload.
sorenjan 3y ago
Then why is the 100 kB test the slowest, with a max speed of 115 Mb/s? And no upload test gets above 250 Mb/s. The speed is very clearly throttled by the ISP though, they sell a faster package that I don't need. I'm not complaining, I've just never seen this burst behavior anywhere else.
- tweenagedream 3y ago
  This is because of the way tcp congestion control works. In order to achieve higher speeds, tcp has a "window" that grows, essentially the amount of data in flight, that has not yet been acknowledged by your client. That window doesn't open very wide in the 100kb test because it happens so quickly.

jnsaff2 3y ago

I have seen similar shaping. This gives a quick responsive browsing experience but throttles bigger downloads/streaming. It also can be implemented badly. Azure VNET peering had 200M level and 100M level. Where 200M level was 200M most of the time, whereas 100M level was 200M for 30s and 0M for the next 30s.

bombcar 3y ago

It’s actually quite a hard problem to limit a fast physical connection to a slower speed for a burst - so much so that some tests are much easier with an old 10/100 hub. What’s nice is when you pay for a certain speed and they give you more if nobody’s using the excess. That’s more rare now but still can be encountered, especially on upload.

sorenjan 3y ago

Then why is the 100 kB test the slowest, with a max speed of 115 Mb/s? And no upload test gets above 250 Mb/s. The speed is very clearly throttled by the ISP though, they sell a faster package that I don't need. I'm not complaining, I've just never seen this burst behavior anywhere else.

tweenagedream 3y ago
This is because of the way tcp congestion control works. In order to achieve higher speeds, tcp has a "window" that grows, essentially the amount of data in flight, that has not yet been acknowledged by your client. That window doesn't open very wide in the 100kb test because it happens so quickly.