From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 54C1A21F1E8 for ; Mon, 25 May 2015 14:39:56 -0700 (PDT) Received: by ieczm2 with SMTP id zm2so79386580iec.1 for ; Mon, 25 May 2015 14:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=rjOdwnKbe1paTj3ROUqqEaD7Br92+mcwnXkaYSINh+U=; b=LFwcliHRLOVA+p9UALWiRAoBq9J/kb7B4OxRRsr4pyt+kfq8proGsAv27p/udg+e4m YPCU3uREKrVD9GBwORkLjoi/6f+jj1rYsLGcKOYEECaWStmdaBNGis0nuoujz0Aj5ATS a3IRLu8zxc8a+/XbzGbjtoZMCatfx5qu7+ycUuxBz3ICd9jP3sfhU40NjtoqUDErqtAA c1fvijcyIYVg0JC6WOpHrVEmdISlDxILN6CgGKX2S4DmsKUOew8iovaGHaSrByeRZbv4 FBlZhudR72mUNVR2VazkQbYVhlhaWBWvCcGALOwcRc7wgJKP02hh4ygmLZLLgKAXR1GB Ya+Q== MIME-Version: 1.0 X-Received: by 10.43.63.76 with SMTP id xd12mr26781155icb.11.1432589989915; Mon, 25 May 2015 14:39:49 -0700 (PDT) Sender: justinbeech@gmail.com Received: by 10.50.107.42 with HTTP; Mon, 25 May 2015 14:39:49 -0700 (PDT) In-Reply-To: <555F37AF.5080406@gmail.com> References: <555C825C.1010607@darbyshire-bryant.me.uk> <555F37AF.5080406@gmail.com> Date: Tue, 26 May 2015 07:39:49 +1000 X-Google-Sender-Auth: Q4U0XYxCS-Jpje8oC9BgvSZVuwg Message-ID: From: jb To: Alan Jenkins , bloat Content-Type: multipart/alternative; boundary=bcaec51a8a967530d50516eed9b7 Subject: Re: [Bloat] Fwd: dslreports and inbound rate shaping X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 21:40:35 -0000 --bcaec51a8a967530d50516eed9b7 Content-Type: text/plain; charset=UTF-8 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@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@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --bcaec51a8a967530d50516eed9b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Regarding this part:

>=C2=A0The baseline latency is because the bloat meas= urement uses a single websocket ping server in America.=C2=A0 Justin said i= n the forums it didn't seem worth the effort to set up more of them.=C2= =A0 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.

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

On Sat, May 23, 2= 015 at 12:05 AM, Alan Jenkins <alan.christopher.jenkins@g= mail.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!=C2=A0 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<= br> >> if it showed the up and the down, under load, 98th percentile,
>> also.
>>
>> an unshaped, unmodified cable modem result in all it's horribl= e
>> 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.=C2=A0 In theory same test 16/6 flows, dow= n 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<= br> > 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=C2=A0 (I had a really goo= d
> 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.=C2=A0 None of the ping response time test sites I've = checked
> give me anywhere near a baseline ping rtt of 100ms.=C2=A0 Even dslrepo= rts
> say "London UK is ~10ms, Google Europe is ~17ms, Dublin, Ireland,= EU
> is ~20ms, Frankfurt, DE, EU is ~27ms"=C2=A0 =C2=A0So I clearly do= n'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 websock= et ping server in America.=C2=A0 Justin said in the forums it didn't se= em worth the effort to set up more of them.=C2=A0 Seems worth an faq item t= hough :(.

Alan


_______________________________________________
Bloat mailing list
Bloat@list= s.bufferbloat.net
= https://lists.bufferbloat.net/listinfo/bloat

--bcaec51a8a967530d50516eed9b7--