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 14:18:05 -0700 [thread overview]
Message-ID: <14f197a2740.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> (raw)
In-Reply-To: <alpine.DEB.2.02.1508101141430.20380@nftneq.ynat.uz>
Those numbers are approximately correct. If you use VHT modulation the
overhead is fixed apart from a small variation with number of spatial
streams. The actual data duration is rounded by some FEC padding rules and
up to whole symbols, but for the purposes of these discussions those
numbers are accurate enough.
1590 bytes (may not be exact, but close enough for this) x 8 bits /
1,000,000,000 Gb/s
Simon
Sent with AquaMail for Android
http://www.aqua-mail.com
On August 10, 2015 11:45:22 AM David Lang <david@lang.hm> wrote:
> On Mon, 10 Aug 2015, Simon Barber wrote:
>
> > 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.
>
> Just to clarify and make sure I'm understanding this properly
>
> A full size packet takes ~234us (222 + 12) at 1Gb/s bitrate and ~1422us (222
> +1200) at 10Mb bitrate, correct?
>
> I would have expected that some of the overhead/framing would be bitrate
> dependent, while some is wall-clock time of waiting to make sure the channel is
> clear.
>
> David Lang
next prev parent reply other threads:[~2015-08-10 21:18 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
2015-08-10 18:44 ` David Lang
2015-08-10 19:21 ` Jonathan Morton
2015-08-10 21:18 ` Simon Barber [this message]
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=14f197a2740.27f7.e972a4f4d859b00521b2b659602cb2f9@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