[Bloat] Fwd: dslreports and inbound rate shaping

Alan Jenkins alan.christopher.jenkins at gmail.com
Fri May 22 10:05:35 EDT 2015


On 20/05/15 13:47, Kevin Darbyshire-Bryant wrote:
 > 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

Good fun :).

The baseline latency is because the bloat measurement uses a single 
websocket ping server in America.  Justin said in the forums it didn't 
seem worth the effort to set up more of them.  Seems worth an faq item 
though :(.

Alan




More information about the Bloat mailing list