<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 8/9/2015 2:43 PM, David Lang wrote:<br>
    <blockquote
      cite="mid:alpine.DEB.2.02.1508091438150.2141@nftneq.ynat.uz"
      type="cite">On Sun, 9 Aug 2015, Simon Barber wrote:
      <br>
      <br>
      <blockquote type="cite">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.
        <br>
        <br>
        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.
        <br>
      </blockquote>
      <br>
      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.
      <br>
    </blockquote>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    Simon<br>
    <br>
    <blockquote
      cite="mid:alpine.DEB.2.02.1508091438150.2141@nftneq.ynat.uz"
      type="cite">
      <br>
      David Lang
      <br>
      <br>
      <blockquote type="cite">Simon
        <br>
        <br>
        On 8/9/2015 12:31 PM, Jonathan Morton wrote:
        <br>
        <blockquote type="cite">
          <br>
          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.
          <br>
          <br>
          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.
          <br>
          <br>
          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.
          <br>
          <br>
          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.
          <br>
          <br>
          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.
          <br>
          <br>
          - Jonathan Morton
          <br>
          <br>
          <br>
          <br>
          _______________________________________________
          <br>
          Make-wifi-fast mailing list
          <br>
          <a class="moz-txt-link-abbreviated" href="mailto:Make-wifi-fast@lists.bufferbloat.net">Make-wifi-fast@lists.bufferbloat.net</a>
          <br>
          <a class="moz-txt-link-freetext" href="https://lists.bufferbloat.net/listinfo/make-wifi-fast">https://lists.bufferbloat.net/listinfo/make-wifi-fast</a>
          <br>
        </blockquote>
        <br>
        <br>
      </blockquote>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________

Make-wifi-fast mailing list

<a class="moz-txt-link-abbreviated" href="mailto:Make-wifi-fast@lists.bufferbloat.net">Make-wifi-fast@lists.bufferbloat.net</a>

<a class="moz-txt-link-freetext" href="https://lists.bufferbloat.net/listinfo/make-wifi-fast">https://lists.bufferbloat.net/listinfo/make-wifi-fast</a>

</pre>
    </blockquote>
    <br>
  </body>
</html>