From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 AE2C33CB3A for ; Fri, 2 Feb 2018 15:13:37 -0500 (EST) Received: by mail-qt0-x232.google.com with SMTP id m11so4925056qtn.10 for ; Fri, 02 Feb 2018 12:13:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=aDvAeA5K95aOL6kTjYyrl3UOq4rcLbDG72K0pEN63FM=; b=BlEORUGTdeVWMxCvPzHZLFQ1BPdzi00zt2/UV4GhmJXTW90vQwl22pOcmAD90UNmYS axGcgf2fMvdyHJNLGVG4tXpPtc6W/1oHRalTZ3U+LiFf34VRteICRl5wEY+NRDTG/8dM xG6uenpKJle0fcwd4bXcMKhxU9yxkklAucUnI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=aDvAeA5K95aOL6kTjYyrl3UOq4rcLbDG72K0pEN63FM=; b=QFY5KAv0YFrsYv8P3Wxb025kZoBWwFdG6URPcEIT6a1NznkUIwPlp7l+RKcbZOqYad Ve3HYNeyiRo7WL1kmcifduldoJVGvvHpfdYE5SAIm8kk+E3TJXbHlS8DE6pjIzPr2SyR 7O64gFZOv5r5+o57L12T3fQgi732KGPhdTJsmVYbeZlDgYgyhR3D0QcY+JQOTRVA9OaT lUW+lPFT08z9+8/GiMVu7oJ1XUJ3TGkNzyevlmxkJNj8/z4zzRjvq6GShI/ZwdNobI3T 2DMPJohMsoyGfrzzIZFM/4Amz7BJ1KcYTJGJiBTUouEIH5f7SeNjrCWwOKcQ446GPpKv ZBXA== X-Gm-Message-State: AKwxytfbKt4UrpWNr7c5u0O+K1emyrWStUpEwdXeIAJx37RnUWbtgWu0 kZYBntoxoVNJA0EkOqU6Wjhqdg== X-Google-Smtp-Source: AH8x226sDqCpXOpDWp+7VHx6pOoakSulUDVeZr2wk5p8xAu6Wpf/A/tD2dxvv+SWP+OJF/q5uQSWNw== X-Received: by 10.237.59.113 with SMTP id q46mr66034108qte.222.1517602417191; Fri, 02 Feb 2018 12:13:37 -0800 (PST) Received: from [10.177.251.196] ([192.19.248.250]) by smtp.gmail.com with ESMTPSA id q2sm1946609qki.26.2018.02.02.12.13.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Feb 2018 12:13:36 -0800 (PST) To: "dpreed@deepplum.com" , make-wifi-fast@lists.bufferbloat.net, linux-wireless@vger.kernel.org References: <20180202151105.30043-1-toke@toke.dk> <1517590516.742814797@apps.rackspace.com> From: Arend van Spriel Message-ID: <5A74C66D.3050509@broadcom.com> Date: Fri, 2 Feb 2018 21:13:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <1517590516.742814797@apps.rackspace.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Make-wifi-fast] [PATCH] mac80211: Adjust TSQ pacing shift X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 20:13:37 -0000 On 2/2/2018 5:55 PM, dpreed@deepplum.com wrote: > I'm curious about the "WiFi Aware" initiative by the WiFi Alliance. > > Does LEDE and/or Linux support this protocol? I know gSupplicant is potentially the way such things are supposed to work, at least according to its supporters. > > The general NAN (Neighborhood-Aware-Networking) concept makes a lot of sense at one level, but as an Internet guy, it troubles me that they decided to split from the Internet and go a balkanized direction. To me, the neighborhood is interesting only as part of a larger Internet. > > It also troubles me that WiFi Aware is a "certification program" rather than a real standard. It troubles me that you are breaking into an email conversation with a topic that in my opinion is totally unrelated. Although probably not intended as such it seems rude. Just start your own conversation. Regards, Arend > -----Original Message----- > From: "Toke Høiland-Jørgensen" > Sent: Friday, February 2, 2018 10:11am > To: make-wifi-fast@lists.bufferbloat.net, linux-wireless@vger.kernel.org > Cc: "Toke Høiland-Jørgensen" > Subject: [Make-wifi-fast] [PATCH] mac80211: Adjust TSQ pacing shift > > Since we now have the convenient helper to do so, actually adjust the > TSQ pacing shift for packets going out over a WiFi interface. This > significantly improves throughput for locally-originated TCP > connections. The default pacing shift of 10 corresponds to ~1ms of > queued packet data. Adjusting this to a shift of 8 (i.e. ~4ms) improves > 1-hop throughput for ath9k by a factor of 3, whereas increasing it more > has diminishing returns. > > Achieved throughput for different values of sk_pacing_shift (average of > 5 iterations of 10-sec netperf runs to a host on the other side of the > WiFi hop): > > sk_pacing_shift 10: 43.21 Mbps (pre-patch) > sk_pacing_shift 9: 78.17 Mbps > sk_pacing_shift 8: 123.94 Mbps > sk_pacing_shift 7: 128.31 Mbps > > Latency for competing flows increases from ~3 ms to ~10 ms with this > change. This is about the same magnitude of queueing latency induced by > flows that are not originated on the WiFi device itself (and so are not > limited by TSQ). > > Signed-off-by: Toke Høiland-Jørgensen > --- > net/mac80211/tx.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c > index 25904af38839..69722504e3e1 100644 > --- a/net/mac80211/tx.c > +++ b/net/mac80211/tx.c > @@ -3574,6 +3574,14 @@ void __ieee80211_subif_start_xmit(struct sk_buff *skb, > if (!IS_ERR_OR_NULL(sta)) { > struct ieee80211_fast_tx *fast_tx; > > + /* We need a bit of data queued to build aggregates properly, so > + * instruct the TCP stack to allow more than a single ms of data > + * to be queued in the stack. The value is a bit-shift of 1 > + * second, so 8 is ~4ms of queued data. Only affects local TCP > + * sockets. > + */ > + sk_pacing_shift_update(skb->sk, 8); > + > fast_tx = rcu_dereference(sta->fast_tx); > > if (fast_tx && >