The friend of mine that I've been working with brought up a cloud node somewhere with ubuntu and netperf on it, and from another location (business internet) able to consistently get better throughput from his cloud node setup than from the flent-fremont node.  We're starting to think that it's something about that node in particular.  It seems to have a 125Mbps cap (so I guess about a 140-150Mbps line-rate cap?).

What kind of node is it running on?

On Thu, Sep 21, 2017 at 8:13 AM, Aaron Wood <woody77@gmail.com> wrote:
I'd wondered about single vs. multiple, but I'm getting pretty consistent speeds from the flent-fremont node irrespective of the number of streams that I use (1, 4, 12, etc).  

On Thu, Sep 21, 2017 at 7:50 AM, Colin Dearborn <Colin.Dearborn@sjrb.ca> wrote:

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