From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 0307A21F2FC for ; Fri, 22 May 2015 07:07:05 -0700 (PDT) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Yvna3-0000nA-EA for bloat@lists.bufferbloat.net; Fri, 22 May 2015 16:05:43 +0200 Received: from host-92-11-217-12.as43234.net ([92.11.217.12]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 May 2015 16:05:43 +0200 Received: from alan.christopher.jenkins by host-92-11-217-12.as43234.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 May 2015 16:05:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bloat@lists.bufferbloat.net From: Alan Jenkins Date: Fri, 22 May 2015 15:05:35 +0100 Message-ID: <555F37AF.5080406@gmail.com> References: <555C825C.1010607@darbyshire-bryant.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: host-92-11-217-12.as43234.net User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 In-Reply-To: <555C825C.1010607@darbyshire-bryant.me.uk> 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: Fri, 22 May 2015 14:08:15 -0000 X-List-Received-Date: Fri, 22 May 2015 14:08:15 -0000 X-List-Received-Date: Fri, 22 May 2015 14:08:15 -0000 X-List-Received-Date: Fri, 22 May 2015 14:08:15 -0000 X-List-Received-Date: Fri, 22 May 2015 14:08:15 -0000 X-List-Received-Date: Fri, 22 May 2015 14:08:15 -0000 X-List-Received-Date: Fri, 22 May 2015 14:08:15 -0000 X-List-Received-Date: Fri, 22 May 2015 14:08:15 -0000 X-List-Received-Date: Fri, 22 May 2015 14:08:15 -0000 X-List-Received-Date: Fri, 22 May 2015 14:08:15 -0000 X-List-Received-Date: Fri, 22 May 2015 14:08:15 -0000 X-List-Received-Date: Fri, 22 May 2015 14:08:15 -0000 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