From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 164F121F19D; Tue, 19 May 2015 12:17:23 -0700 (PDT) Received: by oign205 with SMTP id n205so19006493oig.2; Tue, 19 May 2015 12:17:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=5XizkL+W3nl5+HwwSIFxJgunH/wp0TYoQXEZ6vL/Zic=; b=mLFor83yTWtbISUFha+dScWHRkspSPRkDrVtfvi3e3/gyG5W8jZuqTWMPMsFtWZ5Oy d1OqJzCloMSfTyfYuoMkD7vT19l6D4QDeNv/FIR48vKXfWg2jw20wtO1TjzIhF2X55Bb caKMREogS8Tz96mX/V59RNw4jQ78I8+xyXWH0gcvUmoTrOpX28vPwn5h/S/BxZ9RtP0H wDAYC8l/PhUP8d1JV+zY9DPEuAuWoUZUjoMVCmdLmcusguHggwh0tX9o2ui94TCxlDKj FcUo/Vz6KrrjB4YfbjYtgjFfY3U24uK28kgbhd7aqbPhTuy+aVf4Qa0wkrfIWx7aLK6P xh9w== MIME-Version: 1.0 X-Received: by 10.60.178.33 with SMTP id cv1mr25454421oec.11.1432063036632; Tue, 19 May 2015 12:17:16 -0700 (PDT) Received: by 10.202.105.146 with HTTP; Tue, 19 May 2015 12:17:16 -0700 (PDT) Date: Tue, 19 May 2015 12:17:16 -0700 Message-ID: From: Dave Taht To: bloat , Justin Beech , cake@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Bloat] 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: Tue, 19 May 2015 19:18:11 -0000 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. 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 I am puzzled as to why the idle portion of the test is so bad. Perhaps it it measuring a new flow syn/synack/data? Or there is a need for the lowat option on the server side so as to end the test more quickly? or have we lost so badly there are still 10 seconds of data in flight?? (will take apart some captures when I have time) 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). http://www.dslreports.com/speedtest/509743 fq_codel: http://www.dslreports.com/speedtest/509763 Pie: http://www.dslreports.com/speedtest/509736 Desperate, I applied the linux policer to the inbound test, and got huge reductions in latency, still with big bursts at a huge cost in bandwidth. http://www.dslreports.com/speedtest/506807 We have done too much testing with the gentler rrul test, and this explains a lot about some bittorrent results I have got elsewhere. So I finished writing up my thoughts on bobbie, http://www.bufferbloat.net/projects/codel/wiki/Bobbie which might work better than anything on the table in the face of huge bursts like these, when the rate differential is so small. 3) I will try to add a few dslreports emulations into the netperf-wrapper s= uite. Sigh. Still so much work left to perform on bufferbloat on conventional dev= ices. I think fixing wifi will be harder than this. Building spacecraft is easier than this. --=20 Dave T=C3=A4ht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67