[Bloat] Fwd: dslreports and inbound rate shaping

[Dave Taht]

resending as the mail server seems to be mis-behaving.

---------- Forwarded message ----------
From: Dave Taht <dave.taht at gmail.com>
Date: Tue, May 19, 2015 at 12:17 PM
Subject: dslreports and inbound rate shaping
To: bloat <bloat at lists.bufferbloat.net>, Justin Beech
<justinbeech at gmail.com>, cake at lists.bufferbloat.net


0) dslreports has a hires bufferbloat option now in their settings. It
reveals much detail that I like very much. It may not work well on
some browsers. Give it a shot, please.

1) I like that the graphic .png reports now a ping range, but I think
that is baseline latencies. but I think it would be clearer if it
showed the up and the down, under load, 98th percentile, also.

an unshaped, unmodified cable modem result in all it's horrible glory:

http://www.dslreports.com/speedtest/506793

I am puzzled as to why the idle portion of the test is so bad. Perhaps
it it measuring a new flow syn/synack/data? Or there is a need for the
lowat option on the server side so as to end the test more quickly? or
have we lost so badly there are still 10 seconds of data in flight??

(will take apart some captures when I have time)

2) the "cable" test (which keeps changing the number of flows - these
are all 16/6 flows) thoroughly breaks the sqm system's inbound rate
shaper, using cake or fq_codel (cake here), with my rate set 12% below
the delivered rate (100mbit vs 112Mbit).

http://www.dslreports.com/speedtest/509743

fq_codel:

http://www.dslreports.com/speedtest/509763

Pie:

http://www.dslreports.com/speedtest/509736

Desperate, I applied the linux policer to the inbound test, and got
huge reductions in latency, still with big bursts at a huge cost in
bandwidth.

http://www.dslreports.com/speedtest/506807

We have done too much testing with the gentler rrul test, and this
explains a lot about some bittorrent results I have got elsewhere.

So I finished writing up my thoughts on bobbie,
http://www.bufferbloat.net/projects/codel/wiki/Bobbie

which might work better than anything on the table in the face of huge
bursts like these, when the rate differential is so small.

3) I will try to add a few dslreports emulations into the netperf-wrapper suite.

Sigh. Still so much work left to perform on bufferbloat on conventional devices.

I think fixing wifi will be harder than this. Building spacecraft is
easier than this.

--
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67


-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67