General list for discussing Bufferbloat
 help / color / mirror / Atom feed
* [Bloat] bufferbloat bug 216 could use some eyeballs badly
@ 2011-08-01 12:06 Dave Taht
  2011-08-01 13:30 ` John W. Linville
  0 siblings, 1 reply; 4+ messages in thread
From: Dave Taht @ 2011-08-01 12:06 UTC (permalink / raw)
  To: bloat

[-- Attachment #1: Type: text/plain, Size: 416 bytes --]

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.

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

[-- Attachment #2: Type: text/html, Size: 577 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread
* Re: [Bloat] bufferbloat bug [#216] could use some eyeballs badly
@ 2011-08-01 20:19 Dave Taht
  0 siblings, 0 replies; 4+ messages in thread
From: Dave Taht @ 2011-08-01 20:19 UTC (permalink / raw)
  To: Simon Barber; +Cc: cerowrt, bloat

[-- Attachment #1: Type: text/plain, Size: 2928 bytes --]

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 than
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@superduper.net> 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 one
> 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 things
> like share airtime rather than bandwidth. The wireless root qdisc exposed
> the native hardware queues that exist in 802.11 chip sets and bypassed the
> 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 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
> 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 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<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<https://lists.bufferbloat.net/listinfo/bloat>
>



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

[-- Attachment #2: Type: text/html, Size: 3769 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2011-08-01 19:33 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-01 12:06 [Bloat] bufferbloat bug 216 could use some eyeballs badly Dave Taht
2011-08-01 13:30 ` John W. Linville
2011-08-01 19:44   ` Simon Barber
2011-08-01 20:19 [Bloat] bufferbloat bug [#216] " Dave Taht

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox