From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::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 B3226208A7C for ; Tue, 25 Feb 2014 09:10:59 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id e4so1040530wiv.16 for ; Tue, 25 Feb 2014 09:10:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3YIodXRZW+HrKkM/rCl/o2li+08yoYeZT3FgQTjwFRs=; b=yAsMmFZ3f7AeyT8EPwx3oaGbbVIR6oiD+cGhPj/8qJj7oEncjjFTWC40ChIUb+gyCA JQfzkn5+oyq8miJTB7McIj9HN2cScn7UdVvKRAyYwGpGKkmPBSNmqR3SN3ho1QzPepto PN1NevnpZ9GIS53mViSIIVs5tx3n3ztfwdBbahRNTuL4J4eGsvTglUr0fY2DP2fGGqyn vOffQZLp16lJ3UOaEz6W4ImHwpefW8Uuo6zWt9FgMkT/Dn5uC4FAtWTEqOAZvPlTDQIO M+53xoucWE8JDFKdC49jZzvHA9hRUkjyf9QDRF1M3czDbdj8CpQxm9lEuOQQFi7D2jG0 9UYg== MIME-Version: 1.0 X-Received: by 10.194.108.41 with SMTP id hh9mr2659978wjb.89.1393348257437; Tue, 25 Feb 2014 09:10:57 -0800 (PST) Received: by 10.216.8.1 with HTTP; Tue, 25 Feb 2014 09:10:57 -0800 (PST) In-Reply-To: References: <530C7AFA.2070101@gmail.com> Date: Tue, 25 Feb 2014 09:10:57 -0800 Message-ID: From: Dave Taht To: Jim Gettys Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] uplink_buffer_adjustment X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 17:11:01 -0000 On Tue, Feb 25, 2014 at 7:59 AM, Jim Gettys wrote: > > > > On Tue, Feb 25, 2014 at 6:14 AM, Oliver Niesner > wrote: >> >> Hi list, >> >> I use cerowrt (3.10.24-8) direct behind my main dsl Router. >> SQM is set and performance is good. >> When i used Netalyzr from my smartphone i've got good results. >> >> > Network buffer measurements (?): Uplink 96 ms, Downlink is good >> >> But when i use my notebook i get this: >> >> > Network buffer measurements (?): Uplink 1200 ms, Downlink is good >> >> I tried even wired connection and set ring buffer rx/tx with ethtool to >> 64, but >> only minimal change in uplink buffer (1100ms). >> >> Has anyone an idea, what i can try to get better uplink performance? > > > Netalyzr uses a UDP based test for "filling the buffers"; it is not > responsive to drops/marks at all, the way a TCP test would be. > > So if you run it, the flows it generates are unresponsive, and indicate t= he > true size of the buffers at the bottleneck link, even though any normal T= CP > would long since have responded and nothing like that amount of buffering > would have taken place. Furthermore, the flow queuing of fq_codel isolat= es > those flows from other flows, and therefore you do not get the bad latenc= y > you would otherwise get on those flows. > > In short, (particularly since fq_codel is deployed in quantity millions b= y a > few ISP's already; it is no longer a fluke to find it only in hacker's > hands), Nick Weaver needs to improve netalyzr to detect flow queuing > algorithms and make some sense out of the situation. It would be great t= o > monitor the spread of these algorithms around the Internet over the comin= g > years. > > So it is arguably a "bug" in netalyzr. It is certainly extremely > misleading. A lot of evidence has accumulated that SFQ and SQF is widely deployed by more than a few DSL providers, notably several in France have come forward. There is some evidence it is in some firmwares, too. SFQ is the default on free.fr's old boxes, and fq_codel was deployed on their revolution V6 product august 2012 (an upgrade to linux 3.11 with better hashing support for ipv6 and 6rd is on its way). They were kind enough to document their QoS/AQM/Scheduling system for me (and point us at problems in setting the fq_codel target too low on low bandwidth links which we've now fixed in cerowrt's sqm system (but is not yet fixed in openwrt's qos-scripts or dd-wrts, sigh)), which I have begun to encapsulate in this still very drafty internet draft: http://snapon.lab.bufferbloat.net/~d/draft-taht-home-gateway-best-practices= -00.html So the naive single udp flow packet flooding test in netanalyzer in speedtest and in netalyzer (and most other tools) gives misleading results as to the effects of and size of bufferbloat in whole countries, and I REALLY wish we could get good data on the total size of the deployment of these technologies worldwide. Measuring using a high rate flow, simultaneously with a low rate flow on a different 5 tuple, will show more truth. Preferably bidirectionally, at the same time.... > Nick? > > - Jim > >> >> Regards, >> >> Oliver >> >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel > > > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html