From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 97E9F3B2A0 for ; Fri, 6 May 2016 02:33:08 -0400 (EDT) Received: by mail-wm0-x22c.google.com with SMTP id a17so61157095wme.0 for ; Thu, 05 May 2016 23:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=0tJc1A+SRdw6SnK9K/3d2AIiq17bNvZTw7xeRpps6NE=; b=WeFfI+S1t1iT1DdOMVxzCJ3a/zkNPXae7mhItSR8uQJ1DQexiG7DgESwmWph4mD/jQ BQbyUoz6H1HGlHnV+kKqVXQglcJSXXz53lYaSME1pwX5skD5Z5jTry2VNva9wXm1YfqP MW3BrDNzKoxGwSGs78GrOp2AIHmP63AKhYxyo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=0tJc1A+SRdw6SnK9K/3d2AIiq17bNvZTw7xeRpps6NE=; b=ZhdkK6V32IyNTxboQF2OIlMrAwZg8qh5Ejht/jf6oSGlY6SAFQP8t1ifokULripBK3 2vXc7UWnU5JED/ZADqyUqjEiOGUmBdP5u9a2NUA2olp0KyOJCxqA8AAU267Oyr0aX95a J+K4PyUV0QCp6jctA/W6wPb4eH4qLvKiVO6qEC1diqAXyPjE5z2MXHG8prvoykf/DHJ2 jiGjeg9uYXWs+XSlPKukhuNmZa9PXKgxQ99AVZvD5mHgJm3klEWed8MXMe1cdwoAqVY3 pRkIS0JmWAG/4pb2U4Gwap+Ku95ImVe3oHeoXRQgkK/q4dneJqMQ4MFqph/087cXKCdT H3kg== X-Gm-Message-State: AOPr4FXaZhUMiSBt94pXxvOj0LHEl52KdRLFlcryH73sgmsps+et3nWb8NOV35XpOxCSwOYzsIDfaIfK9BTUhMBvxVX+Wmax9j+FQ+SL5CvJXz0NwseWZQ/e3fYdAysAPF/IfBOIu62YnXQamQoxx6rl4A== MIME-Version: 1.0 X-Received: by 10.28.46.19 with SMTP id u19mr7370600wmu.98.1462516387485; Thu, 05 May 2016 23:33:07 -0700 (PDT) Received: by 10.194.65.6 with HTTP; Thu, 5 May 2016 23:33:07 -0700 (PDT) In-Reply-To: References: <1460636302-31161-1-git-send-email-michal.kazior@tieto.com> <1462446039-1070-1-git-send-email-michal.kazior@tieto.com> <1462446039-1070-6-git-send-email-michal.kazior@tieto.com> Date: Fri, 6 May 2016 08:33:07 +0200 Message-ID: From: Michal Kazior To: Dave Taht Cc: linux-wireless , Johannes Berg , make-wifi-fast@lists.bufferbloat.net, "codel@lists.bufferbloat.net" , Avery Pennarun Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Subject: Re: [Codel] [PATCHv4 5/5] mac80211: add debug knobs for codel X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 06:33:08 -0000 On 6 May 2016 at 07:51, Dave Taht wrote: > On Thu, May 5, 2016 at 10:27 PM, Michal Kazior = wrote: >> On 5 May 2016 at 17:21, Dave Taht wrote: >>> On Thu, May 5, 2016 at 4:00 AM, Michal Kazior = wrote: >>>> This adds a few debugfs entries to make it easier >>>> to test, debug and experiment. >>> >>> I might argue in favor of moving all these (inc the fq ones) into >>> their own dir, maybe "aqm" or "sqm". >>> >>> The mixture of read only stats and configuration vars is a bit confusin= g. >>> >>> Also in my testing of the previous patch, actually seeing the stats >>> get updated seemed to be highly async or inaccurate. For example, it >>> was obvious from the captures themselves that codel_ce_mark-ing was >>> happening, but the actual numbers out of wack with the mark seen or >>> fq_backlog seen. (I can go back to revisit this) >> >> That's kind of expected since all of these bits are exposed as >> separate debugfs entries/files. To avoid that it'd be necessary to >> provide a single debugfs entry/file whose contents are generated on >> open() while holding local->fq.lock. But then you could argue it >> should contain all per-sta-tid info as well (backlog, flows, drops) as >> well instead of having them in netdev*/stations/*/txqs. >> Hmm.. > > I have not had time to write up todays results to any full extent, but > they were pretty spectacular. > > I have a comparison of the baseline ath10k driver vs your 3.5 patchset > here on the second plot: > > http://blog.cerowrt.org/post/predictive_codeling/ > > The raw data is here: > https://github.com/dtaht/blog-cerowrt/tree/master/content/flent/qca-10.2-= fqmac35-codel-5 It's probably good to explicitly mention that you test(ed) ath10k with my RFC DQL patch applied. Without it the fqcodel benefits are a lot less significant. (oh, and the "3.5" is pre-PATCHv4 before fq/codel split work: https://github.com/kazikcz/linux/tree/fqmac-v3.5 ) > > ... > > a note: quantum of the mtu (typically 1514) is a saner default than 300, > > (the older patch I had, set it to 300, dunno what your default is now). I still use 300. > and quantum 1514, codel target 5ms rather than 20ms for this test > series was *just fine* (but more testing of the lower target is > needed) I would keep 20ms for now until we get more test data. I'm mostly concerned about MU performance on ath10k which requires significant amount of buffering. > However: > > quantum "300" only makes sense for very, very low bandwidths (say < > 6mbits), in other scenarios it just eats extra cpu (5 passes through > the loop to send a big packet) and disables > the "new/old" queue feature which helps "push" new flows to flow > balance. I'd default it to the larger value. Perhaps this could be dynamically adjusted to match the slowest station known to rate control in the future? Oh, and there's multicast.. Micha=C5=82