[Bloat] Fwd: dslreports and inbound rate shaping

[jb]

Regarding this part:

> 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 :(.

Below huge speeds, upload testing is done with web socket now,
so there is a websocket address on every server now anyway.

The baseline pinging to dslreports.com doesn't seem broken
but if necessary it can be changed to baseline pinging to the
nearest server, wherever that is.

On Sat, May 23, 2015 at 12:05 AM, Alan Jenkins <
alan.christopher.jenkins at gmail.com> wrote:

> 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
>
>
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20150526/89122214/attachment-0002.html>