This is my guess.

DSL reports uses many streams from different servers to achieve these speeds.

I’m assuming flent is a single stream, so you’re at the mercy of TCP receive windows and latency limiting how fast you can go on that single stream.

From: Bloat [mailto:bloat-bounces@lists.bufferbloat.net] On Behalf Of Aaron Wood
Sent: Tuesday, August 29, 2017 11:16 PM
To: bloat <bloat@lists.bufferbloat.net>
Subject: [Bloat] different speeds on different ports? (benchmarking fun)

I don't have a full writeup yet, but wanted to ask if people on here have run into this.  

I'm seeing a disparity between flent and the dslreports speed tests.  On my connection at home (Comcast 150/12), I figured it was something related to the test implementations, but minor.  But on a connect at a friend with business-class Comcast (300/12), we're seeing a huge difference.  Flent can't seem to achieve more than 120Mbps, often with an early, couple-second hump at a much higher speed.  But dslreports' speed tests gets the full 300Mbps.

In looking closer at my connection, with sqm (cake) turned off, I'm seeing ~180Mbps download with 500ms of bufferbloat when I use the dslreports test (http://www.dslreports.com/speedtest/20805152).

Yet flent can't come close to that, even with the tcp_12down test:

The current hypothesis that we have is that this is due to either traffic class, or the ports that traffic are running on.  I've ruled out the ping streams, as a parallel set of netperf tcp_maerts downloads has the same 120Mbps roof.

It would be interesting if we could run some netperf tests using port 80/443 for the listening socket for the data connection (although if doing deep-packet inspection, we might need to use an actual HTTP transfer).

-Aaron