[Bloat] Fwd: dslreports and inbound rate shaping

[Kevin Darbyshire-Bryant]

On 19/05/2015 23:37, Dave Taht wrote:
>
> 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.
Tried it - fun!  Here are some of the results of that fun, I've no idea if this will help anyone.
>
> 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

Ok so this is my HG612 unshaped VDSL2 modem sat behind Archer C7.  The VDSL2 link
is 40Mbit down, 10Mbit up as reported as its capped 'sync' rate.

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

Up is horrendous and I think you can see classic TCP sawtoothing in the delay as well.
Peak just as 'up test' goes idle is strange though.
> 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).
Behaviour here is different.  In theory same test 16/6 flows, down is capped 38Mbit (5%), up at 9.7Mbit(3%)
These are all 'cake'

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

There's a slight double bump at the beginning of the down latency test, but otherwise my
browsing/upload/download experience is vastly improved.

Tuning the down to 37Mbit helps that bump a little maybe: http://www.dslreports.com/speedtest/513652

It gets really interesting if I increase the down limit to 39Mbit: http://www.dslreports.com/speedtest/513782 where it
starts to look a bit like your test results.

Increasing the up limit showed an interesting step change in upload delay, this is the up cap set to 9.8Mbit
http://www.dslreports.com/speedtest/513863  (I had a really good example of the delay increasing in a linear
fashion as the buffer just couldn't drain fast enough...if I find that test result again I'll post it)

Tuning it back down, by even as little as 50kbits would remove that step, I settled on 9.7Mbit for safety.

The elephant in my personal room is the high latency baseline measurement.  None of the ping response time test
sites I've checked give me anywhere near a baseline ping rtt of 100ms.  Even dslreports say "London UK is ~10ms,
Google Europe is ~17ms, Dublin, Ireland, EU is ~20ms, Frankfurt, DE, EU is ~27ms"   So I clearly don't understand
some thing(s) about this test.

Anyway, that's been an interesting 2 hours of playing!

Kevin

>
>
> 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
>
>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4791 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20150520/aec0d6ea/attachment-0002.bin>