From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-f43.google.com (mail-yw0-f43.google.com [209.85.213.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 88E6D201A58; Mon, 1 Aug 2011 12:33:20 -0700 (PDT) Received: by ywt2 with SMTP id 2so1945868ywt.16 for ; Mon, 01 Aug 2011 13:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=2tpZS/ktSs/YcsCDUVgsKwjnWU2TOCTwenDTohQvbMk=; b=b0pIsEcWhFA7w+Jxxi/bWjNHQjYPaJDA/UdQbI18WbKu7/NsxNGm+03gyyOnfAYnpM rzJkpm7jUjVZ9kvJQRpV6vCJ2bzX/sfbIG0am/2fJA2rSD/BUm53uiUMiI3B/AwIm3Du x37AwsC5xe9MKUB3dOb9+OnRKMIDCg4qcCcCE= MIME-Version: 1.0 Received: by 10.42.154.7 with SMTP id o7mr421147icw.229.1312229958728; Mon, 01 Aug 2011 13:19:18 -0700 (PDT) Received: by 10.42.229.4 with HTTP; Mon, 1 Aug 2011 13:19:18 -0700 (PDT) Date: Mon, 1 Aug 2011 14:19:18 -0600 Message-ID: From: Dave Taht To: Simon Barber Content-Type: multipart/alternative; boundary=90e6ba1efd2e8dbb6004a977585b Cc: cerowrt@lists.bufferbloat.net, bloat@lists.bufferbloat.net Subject: Re: [Bloat] bufferbloat bug [#216] could use some eyeballs badly X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 19:33:21 -0000 --90e6ba1efd2e8dbb6004a977585b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What an interesting bit of history behind all this! Did your original code also compensate for the multicast rate on wireless being so much slower tha= n the peak rate? The monstrousness of multicast packets on wireless completely mess up all existing qdisc's estimators... On Mon, Aug 1, 2011 at 1:44 PM, Simon Barber wrote: > I did the original implementation of wireless queuing in mac80211. The > original implementation installed a special wireless root qdisc on the > interface in order to model the hardware queues correctly, and allow leaf > qdiscs to be installed. Ideally the MAC queues would also have been moved > into this qdisc. The wireless root qdisc sat on an interface that > represented the physical radio and had an 802.11 frame type. There were o= ne > or more 802.3 format virtual interfaces that represented wireless client = or > APs. The wireless qdisc on the native 802.11 interface saw frames in 802.= 11 > format, and hence could calculate how much airtime would be taken > transmitting the frame - this would allow development of qdiscs to do thi= ngs > like share airtime rather than bandwidth. The wireless root qdisc exposed > the native hardware queues that exist in 802.11 chip sets and bypassed th= e > normal single queue netdev interface. This allowed the hardware queues to= be > fed independently. > > Unfortunately the native 802.11 interface was deemed confusing to users, > and this code got pulled out of the kernel, thus preventing the qdisc sys= tem > from ever properly working when more than one virtual Ethernet interface = is > used with a wireless card - such as when you run multiple virtual APs on = a > wireless card, or simultaneous AP and client modes. This concept of a > special wireless root qdisc is necessary to model the hardware queues and > the MAC queues in 802.11 correctly - you're not queuing lots of frames in > the driver, rather extending the queuing system to implement parts of the > MAC. > > Simon > > > On 08/01/2011 06:30 AM, John W. Linville wrote: > >> On Mon, Aug 01, 2011 at 06:06:43AM -0600, Dave Taht wrote: >> >>> If anyone can spare some eyeballs for the discussion of wireless-n AMPD= Us >>> and their interaction with bufferbloat, and groks TCP's behavior and/or >>> wireless's behavior, I'd appreciate some comment on: >>> >>> http://www.bufferbloat.net/**issues/216 >>> >>> Losing SOME appropriate packets, somewhere in the wireless stack, is >>> necessary. >>> >> >> It seems appropriate to Cc: linux-wireless@vger.kernel.org for this... >> >> > ______________________________**_________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/**listinfo/bloat > --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com --90e6ba1efd2e8dbb6004a977585b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What an interesting bit of history behind all this! Did your original code = also compensate for the multicast rate on wireless being so much slower tha= n the peak rate?

The monstrousness of multicast packets on wireless = completely mess up all existing qdisc's estimators...

On Mon, Aug 1, 2011 at 1:44 PM, Simon Barber= <simon@superd= uper.net> wrote:
I did the original implementation of wireless queuing in mac80211. The orig= inal implementation installed a special wireless root qdisc on the interfac= e in order to model the hardware queues correctly, and allow leaf qdiscs to= be installed. Ideally the MAC queues would also have been moved into this = qdisc. The wireless root qdisc sat on an interface that represented the phy= sical radio and had an 802.11 frame type. There were one or more 802.3 form= at virtual interfaces that represented wireless client or APs. The wireless= qdisc on the native 802.11 interface saw frames in 802.11 format, and henc= e could calculate how much airtime would be taken transmitting the frame - = this would allow development of qdiscs to do things like share airtime rath= er than bandwidth. The wireless root qdisc exposed the native hardware queu= es that exist in 802.11 chip sets and bypassed the normal single queue netd= ev interface. This allowed the hardware queues to be fed independently.

Unfortunately the native 802.11 interface was deemed confusing to users, an= d this code got pulled out of the kernel, thus preventing the qdisc system = from ever properly working when more than one virtual Ethernet interface is= used with a wireless card - such as when you run multiple virtual APs on a= wireless card, or simultaneous AP and client modes. This concept of a spec= ial wireless root qdisc is necessary to model the hardware queues and the M= AC queues in 802.11 correctly - you're not queuing lots of frames in th= e driver, rather extending the queuing system to implement parts of the MAC= .

Simon


On 08/01/2011 06:30 AM, John W. Linville wrote:
On Mon, Aug 01, 2011 at 06:06:43AM -0600, Dave Taht wrote:
If anyone can spare some eyeballs for the discussion of wireless-n AMPDUs and their interaction with bufferbloat, and groks TCP's behavior and/or=
wireless's behavior, I'd appreciate some comment on:

http://= www.bufferbloat.net/issues/216

Losing SOME appropriate packets, somewhere in the wireless stack, is
necessary.

It seems appropriate to Cc: linux-wireless@vger.kernel.org for this...


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



--
Dave T=E4ht
SKYPE: d= avetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com
--90e6ba1efd2e8dbb6004a977585b--