From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) (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 BB6A63B29E for ; Mon, 25 Jun 2018 20:52:25 -0400 (EDT) Received: by mail-ed1-f54.google.com with SMTP id w14-v6so6498789eds.6 for ; Mon, 25 Jun 2018 17:52:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+mZDJf2jaYUhKJ7wGie9jcISbNdc4L3iCdGbcQEuqWo=; b=FzywferkilwDiqmlmMFrKtpQEKLJADiWUP+BHtgpk4EhuOmHXXuoFs+c9ObYQWE8VO Gu6G2JacZQOkD4/I+L+b9Gs8/L+TTUKjzr20FTg7bXunwcSLKzwBbeRY/x6sOQ5gGuHH fWZVEyYq7Qo+/jsfLLy4OAHdXv1YWDCuOeshH/iBAdMPuqs7BZKYiMHffLQOubWIoaW2 bjYD2KmzxKLxmHDFlBlb3v0/uJc7jCFwRq9LdaIOVl6OcXXGq8OtVNwqla9GL4itOLP4 hVkJ8EMJIHEvYmmGposTkpcRi0macl3S3gcT0pRfCWz/pnU8H0FyYkiRLSj4DaA4DvTU r2GQ== X-Gm-Message-State: APt69E18hstosKu/CaW11vVtMEEU8eTQdGuRzUANl30aJcL5kLe4phtI DrQozzxYlLsxjVVc8pfa5m37b/GIQKr5ESaS+BM= X-Google-Smtp-Source: ADUXVKLeuHcBtx/4zePRW9vSybL2CGbmhWlZHEwI0YoqG2Z890JEjr1d7tG47fFCOkpusNUvHwWtR/rAwqZ4qGrQblU= X-Received: by 2002:a50:a743:: with SMTP id h61-v6mr13146426edc.261.1529974344815; Mon, 25 Jun 2018 17:52:24 -0700 (PDT) MIME-Version: 1.0 References: <8736xgsdcp.fsf@toke.dk> <838b212e-7a8c-6139-1306-9e60bfda926b@gmail.com> <8f80b36b-ef81-eadc-6218-350132f4d56a@pollere.com> <9dbb8dc8-bec6-8252-c063-ff0ba5fd7c1a@pollere.com> <25305.1529678986@localhost> <47EC21F5-94D2-4982-B0BE-FA1FA30E7C88@gmail.com> <18224.1529704505@localhost> <87muvjnobj.fsf@toke.dk> <68C3BBE1-96DA-41F7-9878-582074C4E769@gmail.com> <642CBFAE-A182-4D6E-968B-411159CBFD9B@superduper.net> <422BFE8C-1AAC-4A55-AF1F-448B3B5C0E28@gmail.com> In-Reply-To: <422BFE8C-1AAC-4A55-AF1F-448B3B5C0E28@gmail.com> From: Jim Gettys Date: Mon, 25 Jun 2018 20:52:08 -0400 Message-ID: To: Jonathan Morton Cc: Simon Barber , bloat Content-Type: multipart/alternative; boundary="0000000000005696c3056f80e96d" Subject: Re: [Bloat] lwn.net's tcp small queues vs wifi aggregation solved X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 00:52:26 -0000 --0000000000005696c3056f80e96d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 25, 2018 at 8:44 PM Jonathan Morton wrote: > > On 26 Jun, 2018, at 3:36 am, Simon Barber wrote: > > > > Most hardware needs the packet finalized before it starts to contend fo= r > the medium (as far as I=E2=80=99m aware - let me know if you know differe= ntly). One > issue is that if RTS/CTS is in use, then the packet duration needs to be > known in advance (or at least mid point of the RTS transmission). > > This is a valid argument. I think we could successfully argue for a dela= y > of 1ms, if there isn't already enough data in the queue to fill an > aggregate, after the oldest packet arrives until a request is issued. > > > If there are no other stations competing for airtime, why does it matte= r > that we use two txops? > > One further argument would be power consumption. Radio transmitters eat > batteries for lunch; the only consistently worse offender I can think of = is > a display backlight, assuming the software is efficient. > =E2=80=8B=E2=80=8B > > =E2=80=8BNo=E2=80=8Bt clear if this is true; we need current data. In OLPC days, we measured the receive/transmit power consumption, and transmit took essentially no more power than receive. The dominant power consumption was due to signal processing the RF, not the transmitter. Just listening sucked power.... Does someone understand what current 802.11 and actual chip sets consume for power? Jim > - Jonathan Morton > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --0000000000005696c3056f80e96d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Jun 25, 2018= at 8:44 PM Jonathan Morton <ch= romatix99@gmail.com> wrote:
= > On 26 Jun, 2018, at 3:36 am, Simon Barber <simon@superduper.net> wrote:
>
> Most hardware needs the packet finalized before it starts to contend f= or the medium (as far as I=E2=80=99m aware - let me know if you know differ= ently). One issue is that if RTS/CTS is in use, then the packet duration ne= eds to be known in advance (or at least mid point of the RTS transmission).=

This is a valid argument.=C2=A0 I think we could successfully argue for a d= elay of 1ms, if there isn't already enough data in the queue to fill an= aggregate, after the oldest packet arrives until a request is issued.

> If there are no other stations competing for airtime, why does it matt= er that we use two txops?

One further argument would be power consumption.=C2=A0 Radio transmitters e= at batteries for lunch; the only consistently worse offender I can think of= is a display backlight, assuming the software is efficient.
=E2=80=8B=E2=80=8B

=E2=80=8BNo=E2=80=8Bt clear if this is true; we need curren= t data.

In OLPC days, we = measured the receive/transmit power consumption, and transmit took essentia= lly no more power than receive.=C2=A0 The dominant power consumption was du= e to signal processing the RF, not the transmitter.=C2=A0 Just listening su= cked power....
=
Does someo= ne understand what current 802.11 and actual chip sets consume for power?

Jim


=C2=A0- Jonathan Morton

_______________________________________________
Bloat mailing list
Bloat@list= s.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
--0000000000005696c3056f80e96d--