Lets make wifi fast again!
 help / color / mirror / Atom feed
From: Simon Barber <simon@superduper.net>
To: David Lang <david@lang.hm>
Cc: make-wifi-fast@lists.bufferbloat.net
Subject: Re: [Make-wifi-fast] [Cerowrt-devel] [tsvwg] Comments on draft-szigeti-tsvwg-ieee-802-11e
Date: Mon, 10 Aug 2015 07:00:40 -0700	[thread overview]
Message-ID: <55C8AE88.9080202@superduper.net> (raw)
In-Reply-To: <alpine.DEB.2.02.1508091438150.2141@nftneq.ynat.uz>

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

On 8/9/2015 2:43 PM, David Lang wrote:
> On Sun, 9 Aug 2015, Simon Barber wrote:
>
>> 11ac with it's always on RTS/CTS and mandatory A-MPDUs really 
>> performs much better than many 11n implementations. It's finally a 
>> fairly sane MAC. The 64 bit limit in the compressed block ack is a 
>> limiter though. The really wide channels are another complex area for 
>> busy networks.
>>
>> The aggregation overhead for 11ac is about 222uS, counting EDCA 
>> backoff, RTS, CTS, PLCP header and the Block-ACK and all the inter 
>> frame spaces. One full size ethernet frame at 1Gb/s = ~12us. Large 
>> aggregates are critical to good efficiency and performance, and a 
>> certain amount of queuing is required to form them. They have to be 
>> completely formed before transmission starts.
>
> do you know the per-transmission overhead for different modes (n and 
> a/g specifically)? Also, what parts of the overhead get extended when 
> the data rate slows? It's all well and good to talk about a full size 
> packet being 12us at 1GHz, but that requires a good signal an 3x3 
> radios. If instead you are on a 1x1 radio with not as good a signal, 
> you can easily drop your data rate by an order of magnatude or so. At 
> ~100Mb your data packet is now 120us, what is the overhead? if you 
> drop to 10Mb your packet is now 1200us, what is the overhead.

If you're using VHT modulation then the overhead stays the same at lower 
rates (assuming the same no. of antennas). 11n is lower due to no RTS, 
only CTS, and 11a is lower still due to no CTS, and no training symbols 
for MIMO. Not quite half though.

David Reed is wrong about being able to re-use the RTS/CTS sync for the 
data - the RTS/CTS in 802.11 has to be backwards compatible with single 
antenna 11a/g systems, so doesn't have training symbols for different 
MIMO channels. They are pretty short though! With that fan blade in the 
background you're also going to lose sync pretty quickly without 
constant data. Now you might be able to re-use some of the PLCP, but not 
all of it.

Simon

>
> David Lang
>
>> Simon
>>
>> On 8/9/2015 12:31 PM, Jonathan Morton wrote:
>>>
>>> The question of whether to aggregate under congested conditions is 
>>> controversial, probably because it depends on complex conditions.  
>>> There are arguments both for and against.
>>>
>>> It may be worth considering it as a risk/reward tradeoff. Given N 
>>> packets (which for brevity I'll assume are equal MTU sized), the 
>>> reward is obviously proportional to N. Risk however is calculated as 
>>> probability * consequence.
>>>
>>> Assuming all packets in the aggregate are lost on collision, the 
>>> risk of collision scales with L*N, where L is N plus the overhead of 
>>> the TXOP. Under that argument, usually you should not aggregate if 
>>> the probability of collision is high.
>>>
>>> However, if only one packet is lost due to collision with, for 
>>> example, a small RTS probe which is not answered, the risk scales 
>>> with L, which is sublinear compared to the reward relative to the 
>>> amount of aggregation (especially at high data rates where the TXOP 
>>> overhead is substantial). Under this assumption, aggregation is 
>>> usually profitable even with a high collision probability, and 
>>> results in overall higher efficiency whether or not collisions are 
>>> likely.
>>>
>>> This is the difference between the typical 802.11n situation (one 
>>> checksum per aggregate) and the mandatory 802.11ac capability of a 
>>> checksum per packet.  As long as you also employ RTS/CTS when 
>>> appropriate, the possibility of collisions is no longer a reason to 
>>> avoid aggregating.
>>>
>>> - Jonathan Morton
>>>
>>>
>>>
>>> _______________________________________________
>>> Make-wifi-fast mailing list
>>> Make-wifi-fast@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>>
>>
>
>
> _______________________________________________
>
> Make-wifi-fast mailing list
>
> Make-wifi-fast@lists.bufferbloat.net
>
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>


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

  reply	other threads:[~2015-08-10 14:00 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E9C29602-7F1D-43AD-980C-050B58FA0AC6@iii.ca>
2015-07-23  6:48 ` [Make-wifi-fast] Fwd: " Dave Taht
2015-07-23  7:44   ` [Make-wifi-fast] [Cerowrt-devel] " Jonathan Morton
2015-07-23  7:49     ` Alan Jenkins
2015-07-24 10:38       ` Sebastian Moeller
2015-07-30 20:29   ` [Make-wifi-fast] [Cerowrt-devel] " Jonathan Morton
2015-07-30 21:35     ` Sebastian Moeller
2015-07-30 21:56       ` Jonathan Morton
2015-07-31  3:27         ` Sebastian Moeller
2015-07-31 16:47           ` dpreed
2015-07-31 17:04             ` Jonathan Morton
2015-07-31 20:23               ` Michael Richardson
2015-07-31 20:45                 ` Jonathan Morton
2015-08-03 15:44               ` dpreed
2015-08-03 16:14                 ` David Lang
2015-08-03 23:37                   ` dpreed
2015-08-03 23:52                     ` Jonathan Morton
2015-08-04  0:13                     ` David Lang
2015-08-04 16:55                       ` dpreed
2015-08-04  3:20               ` Simon Barber
2015-08-07  8:28             ` Mikael Abrahamsson
2015-08-07 13:22               ` Rich Brown
2015-08-07 13:28                 ` Jonathan Morton
2015-08-07 17:35                   ` Rich Brown
2015-08-08 14:25                     ` Simon Barber
2015-08-07 20:03                   ` David Lang
2015-08-07 21:46                     ` dpreed
2015-08-07 22:31                       ` David Lang
2015-08-08 20:46                         ` dpreed
2015-08-08 23:23                           ` David Lang
2015-08-09 19:31                             ` Jonathan Morton
2015-08-09 20:27                               ` Simon Barber
2015-08-09 21:43                                 ` David Lang
2015-08-10 14:00                                   ` Simon Barber [this message]
2015-08-10 18:44                                     ` David Lang
2015-08-10 19:21                                       ` Jonathan Morton
2015-08-10 21:18                                       ` Simon Barber
2015-08-09 21:50                               ` David Lang
2015-08-10  5:39                                 ` Mikael Abrahamsson
2015-08-13 21:48                               ` David Lang
2015-08-13 22:14                                 ` Jonathan Morton
2015-08-13 22:25                                   ` David Lang
2015-08-13 22:30                                     ` Jonathan Morton
2015-08-09 22:09                           ` David Lang
2015-08-10 13:48                         ` Simon Barber
2015-08-04  3:26       ` Simon Barber
2015-08-04  3:16     ` Simon Barber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/make-wifi-fast.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55C8AE88.9080202@superduper.net \
    --to=simon@superduper.net \
    --cc=david@lang.hm \
    --cc=make-wifi-fast@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox