From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 9561F3B2AB; Mon, 21 Mar 2016 23:14:03 -0400 (EDT) Received: by mail-vk0-x230.google.com with SMTP id e185so238075909vkb.1; Mon, 21 Mar 2016 20:14:03 -0700 (PDT) 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; bh=HqXfjpVOFsQZC8VLZLJCidoFeNzIC+J0c0nKFi/tj/A=; b=EmgvsUG/PhbGmuDIHycmzJj8LJAakW22X6ewHW/6ygYUbMQcEcOhkVFgX20fNzXIep UjJXkZmgWRIbE+8X6JeTZtCwpNzLy2d8n4qxqZGwJCSL2h7X1g+Pna5khxiy32zWKuJI PQ89YmKSpKaHmQbPK6cgEhJYxyv3bEU6FYJjeVb1P02dLycvvLJze4ctTk5IoDHMsSS7 SDfLi/S1I0LAJPuKRW0osdJrGbElytnV6tRVN0d/JQVkEqc17WKREgXr8IDmaya2aEPX Nf0LSNIg7BZGyf64055FfcBgbDSbDoSpc1+GtbBATKELAAQz2N4BS+CJq2b30k9B6VR3 vUsA== 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; bh=HqXfjpVOFsQZC8VLZLJCidoFeNzIC+J0c0nKFi/tj/A=; b=K1l7+A1lPi2uRwry81sqi4ttIIeAUGClnWRNqtmFgiScQ1lFW8bB195ry4SUdo4Fkk iQRvLApuaUSoryPU/eonlT51GNovUMTZTwPE4m5NssVf5sojKmXznq2IOY+Ye+JjsRov g9lucRsDLFVFq3aso6HBh316phIo2zuXM3xNicrYDGfb7px2Kmsvb8W659wnNlCUHlIR rN1X7BCuAA1f1aIUcapOcMVvSCuXDPPaPO4oYamqFRIdK1Qsem7V91ON19sg0RawLQRK QY1gAOszuA+4HlRwo71xyNZHMbqDCZBsbjGyk4oG70uQOXwrdFVYsfWowvjnwHLqDxBo uIjA== X-Gm-Message-State: AD7BkJKCRTSVbyk4sgFo6f5gfqHfM+qR7MBYLMr+gPpBeX4/1TFtc2Ms7ya3ppovzAPAF42IeAAVV5elo6kjgg== MIME-Version: 1.0 X-Received: by 10.159.36.110 with SMTP id 101mr3049611uaq.109.1458616442954; Mon, 21 Mar 2016 20:14:02 -0700 (PDT) Received: by 10.103.100.197 with HTTP; Mon, 21 Mar 2016 20:14:02 -0700 (PDT) In-Reply-To: References: <1456492163-11437-1-git-send-email-michal.kazior@tieto.com> Message-ID: From: Aaron Wood To: David Lang Cc: Michal Kazior , make-wifi-fast@lists.bufferbloat.net, "codel@lists.bufferbloat.net" Content-Type: multipart/alternative; boundary=001a113bbe4af229cc052e9a9a7b X-Mailman-Approved-At: Wed, 06 Apr 2016 13:11:42 -0400 Subject: Re: [Codel] [Make-wifi-fast] [RFC/RFT] mac80211: implement fq_codel for software queuing 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: , Date: Tue, 22 Mar 2016 03:14:03 -0000 X-Original-Date: Mon, 21 Mar 2016 20:14:02 -0700 X-List-Received-Date: Tue, 22 Mar 2016 03:14:03 -0000 --001a113bbe4af229cc052e9a9a7b Content-Type: text/plain; charset=UTF-8 On Mon, Mar 21, 2016 at 6:29 PM, David Lang wrote: > On Mon, 29 Feb 2016, Michal Kazior wrote: > > Our intent is to continue to improve the flent test suite to be able >>> to generate repeatable tests, track relevant wifi behaviors and pull >>> relevant data back, graphed over time (of test) and time (over test >>> runs). A problem with udp flood tests is that tcp traffic is always >>> bidirectional (data vs acks), so a naive thought would be, that yes, >>> you should get half the bandwidth you get with a udp flood test. >>> >> >> I don't see why you'd be doomed to get only half the bandwidth because >> of that? Sure, Wi-Fi is half-duplex but transmit time for ACKs is a >> lot smaller than transmit time for the data. >> > > The difference is actually far less than you think. Each transmission has > a fixed-length header and quiet times that were designed in the days of > 802.11b (1-11Mb) and if you are transmitting a wide 802.11ac signal at a > couple hundred Mb, you can find that the time taken to transmit even full > packets is a surprisingly small percentage of the total transmit time. > > David Lang A 2-dimensional display of data sent vs. time might be useful, for a couple packets, to help explain this (although it may need to be at log-scale). X-axis is time, Y is bandwidth being sent. -Aaron --001a113bbe4af229cc052e9a9a7b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Mar 21, 2016 at 6:2= 9 PM, David Lang <david@lang.hm> wrote:
On Mon, 29 Feb 2016, = Michal Kazior wrote:

Our intent is to continue to improve the flent test suite to be able
to generate repeatable tests, track relevant wifi behaviors and pull
relevant data back, graphed over time (of test) and time (over test
runs). A problem with udp flood tests is that tcp traffic is always
bidirectional (data vs acks), so a naive thought would be, that yes,
you should get half the bandwidth you get with a udp flood test.

I don't see why you'd be doomed to get only half the bandwidth beca= use
of that? Sure, Wi-Fi is half-duplex but transmit time for ACKs is a
lot smaller than transmit time for the data.

 The difference is actually far less than you think. Each transmission has a= fixed-length header and quiet times that were designed in the days of 802.= 11b (1-11Mb) and if you are transmitting a wide 802.11ac signal at a couple= hundred Mb, you can find that the time taken to transmit even full packets= is a surprisingly small percentage of the total transmit time.

David Lang

A 2-dimensional di= splay of data sent vs. time might be useful, for a couple packets, to help = explain this (although it may need to be at log-scale). =C2=A0 X-axis is ti= me, Y is bandwidth being sent.

-Aaron
<= /div>
--001a113bbe4af229cc052e9a9a7b--