From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 7150521FDBE; Fri, 31 Jul 2015 07:16:21 -0700 (PDT) Received: by oibn4 with SMTP id n4so38874752oib.3; Fri, 31 Jul 2015 07:16:20 -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=uBKvw5LH4m3kw2vygAULHvdxadnbdwN0777X1nM593I=; b=cmhdJTqM5N8CEBBkUwlqZJewX0DCJ/uOET6xC/G1IxBKXdNVk2f4ZAs9japP/8KRww bBi5J7WhC5M1IDSXde44QyIxfByrxh9KPIuQZV+WRJrZLOz21x20PFYAk2nQ3kuo5BTn M68n4Q4vpNRoTaTFWBrdbl7GbCOL+2LL+QdNsfXromGLscDUdUztHm101TA2B2N1AHn0 ER6hHsFeOMJ7FuMIuy/bhojcctexLxbQXDcJMJ5gEmG082iAodTN65HIdU6vgUCbDBmN UNZhRNYnFFRZRYX143f1W0ao33l4CxIluRLAI9rVoT4nQJxuQDLvl8hcWcrO7SL1+E2K KgGw== MIME-Version: 1.0 X-Received: by 10.202.214.16 with SMTP id n16mr3178709oig.75.1438352180277; Fri, 31 Jul 2015 07:16:20 -0700 (PDT) Received: by 10.202.73.2 with HTTP; Fri, 31 Jul 2015 07:16:20 -0700 (PDT) Date: Fri, 31 Jul 2015 07:16:20 -0700 Message-ID: From: Dave Taht To: cake@lists.bufferbloat.net, make-wifi-fast@lists.bufferbloat.net, flent-devel@flent.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Cake] fiddling with variable bandwidth (emulating wifi rate control) with cake and flent X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 14:16:49 -0000 After collecting some good traces of the state of the art of wifi under varying conditions, I set about to use cake to model the traces' changes in available bandwidth, and then... after dealing with all the horrific noise... just set about creating repeatable models. In this case, this is running tests for 60 seconds, on a link that has a 16 and 4 mbit variance twice, that is also 1Gbit down. http://snapon.lab.bufferbloat.net/~d/varying_bandwidth.tgz The wifi dataset I think I will have to polish a little to get folk to make sense of it. (I put some of it out already) Any feedback on a better set of standard models for looking at how rate control actually varies in the real world, welcomed! Here is the basic comparison I wanted to see, with cake fq, and cake "flowblind", which is basically cake's version of a pure codel. flent --gui tcp_upload*.gz qdisc-stats-*tcp_upload*.gz using the new (under development) qdisc buffering sampler in flent. There are multiple bugs left to conquer but... 0) It is so nice to see latency stay so reasonably flat when the bandwidth changes - the flowblind results were pretty nice to see. http://snapon.lab.bufferbloat.net/~d/vband/qdisc_tcp_upload_16_4mbit_flowbl= ind.svg http://snapon.lab.bufferbloat.net/~d/vband/tcp_upload_16_4mbit_flowblind.sv= g 1) cake can't possibly be reporting the right number of dropped packets or bytes, or something. the numbers do not add up. Overflow? http://snapon.lab.bufferbloat.net/~d/vband/prettysureidonttrustthesestats.p= ng Speaking of overflow and requeues, what do those terms mean, exactly, in cake, codels, fq_codel, etc, mental context? 2) sqm-scripts has changed dramatically since I last used it. What I used to use on debian was: IFACE=3Deth0 QDISC=3Dcodel UPLINK=3Dx DOWNLINK=3Dy ./simplest.qos what do I now? 3) at least on the box I was debugging on, the tc filter part on ingress (3.16) was failing.... which is why I tested 1gbit down. :( 4) flent needs to be able to sample at faster rates than it does. (theres a bug filed on this). I'd like to be able to see in detail the roughly 3 second period where the latency goes up when the bandwidth goes down. 5) the qdisc stats code needs to work on openwrt (can't, no fractional slee= p) (I keep threatening to rewrite this in c) 6) bugs in the qdisc_stats plots, from sampling, to code output, to the last 2 plots, make all this data unworthy of trust - but it is very pleasant feeling... when the experiment lines up with your expectations... ...even if the experiment is possibly wrong. I hope the dumb script is pretty grokkable. --=20 Dave T=C3=A4ht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast