From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (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 0573D21F0BC for ; Wed, 11 Mar 2015 19:11:34 -0700 (PDT) Received: by obcwp18 with SMTP id wp18so12891502obc.6 for ; Wed, 11 Mar 2015 19:11:33 -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=BpXu9yRDmUiJL9aeWFgaxfoLlEM6XiKnNG1eGi1KPiE=; b=TjYx/JFsz0dIjeUMB+nLWmzavqS5nN7iw8bAXkfjnRQFlNPxRdh5fKWVtZG/UYn/2c k0xI7bt1HGksq074vjUXWvnkfiSin60Wou5W6cG7qyzxGCBVLMs+C064Q3kTHQuxnrtY aJIomYvac0QMJ1dR+cZQ6T6pmkxJwQycAMtxhEDHBgT2vgju8B8WNxYiT3ULPxOoW04s MpTeQHezCKv+BSB4nY4ytOrtmcmJxuo1+JmURe+nTEh5i+pZ5a3NUgfyoIqGpPkR3sA3 9M1g7dCXNIKxvJ93YvywI7Yrkrh6mxgcwwqpoiul6aDuLiFygHy7gHFvOdnsMow+I9vb qegw== MIME-Version: 1.0 X-Received: by 10.202.3.65 with SMTP id 62mr30382493oid.11.1426126293723; Wed, 11 Mar 2015 19:11:33 -0700 (PDT) Received: by 10.202.51.66 with HTTP; Wed, 11 Mar 2015 19:11:33 -0700 (PDT) Date: Wed, 11 Mar 2015 19:11:33 -0700 Message-ID: From: Dave Taht To: netalyzr , "aqm@ietf.org" , mnot@mnot.net, bloat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Bloat] fixing bufferbloat on bigpond cable... 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: Thu, 12 Mar 2015 02:12:03 -0000 I was very pleased to see this tweet go by today: https://twitter.com/mnot/status/575581792650018816 where Mark Nottingham fixed his bufferbloat on bigpond cable using a very simple htb + fq_codel script. (I note ubnt edgerouters also have a nice gui for that, as does openwrt) But: he does point out a flaw in netanalyzr's current tests[1], in that it does not correctly detect the presence of aqm or FQing on the link, (in part due to not running long enough, and also in not using multiple distinct flows) and like the "ping loss considered harmful" thread last week on the aqm and bloat lists, matching user expectations and perceptions would be good with any public tests that exist. There is some stuff in the aqm evaluation guide's "burst tolerance" tests that sort of applies, but... ideas? [1] I am not aware of any other tests for FQ than mine, which are still kind of hacky. What I have is in my isochronous repo on github. --=20 Dave T=C3=A4ht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb