Lets make wifi fast again!
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: bkil.hu+Aq@gmail.com,
	 Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>,
	Ben Greear <greearb@candelatech.com>
Subject: Re: [Make-wifi-fast] [Bloat] Is 5/10MHz wifi bandwidth legal in 2.4GHz (half/quarter-clocking)?
Date: Mon, 8 Oct 2018 13:32:33 -0700	[thread overview]
Message-ID: <CAA93jw44LX2Qvhfw9PQJiJCv07GwAqt6wvTw0iudB0GpBb4e_A@mail.gmail.com> (raw)
In-Reply-To: <CAPuHQ=G84HWdn6SfYqKswUW_FdUts-2zBXg5NvH8=h7jh38fSQ@mail.gmail.com>

make-wifi-fast is better here.

anyway there was a long debate about making the public access channels
available to folk that needed it in the ath10k patchset, I think in
the end ben greer decided to leave it out lacking getting anyone at
the FCC to pay attention.

the second question, regarding 5Mhz channels in general - I had tried
that a lot (it has worked multiple times in ath9k's lifecycle) and I
*liked it*, but as it was non standard never got around to depending
on it existing on anything.

We definitely need more channels, not less

On Mon, Oct 8, 2018 at 1:18 PM bkil <bkil.hu+Aq@gmail.com> wrote:
>
> If this is not the right forum to discuss, could you please point me
> in the right direction?
>
> After all, channel spacing is indeed 5MHz here. Although using a new
> raster instead of the 20MHz channel center frequencies would allow
> full utilization of the band (16 or 8 channels respectively), using
> the standard set of 11 (13) channels is better than nothing.
>
> Is it a good idea to use HT instead of g for such links?
>
> =
> Some background and links for those who do not know this mode:
>
> "the 2007 version of the IEEE 802.11 standard [1] specifies 5 and 10
> MHz wide channels for use in the 4.9 GHz public safety bands"
>
> Although according to my reading of section 17.1, it applies to the
> 5GHz bands as well:
>
> >> 17. Orthogonal frequency division multiplexing (OFDM) PHY specification
> for the 5 GHz band
> [...]
> The OFDM system also provides a “half-clocked” operation using 10 MHz
> channel spacings with data
> communications capabilities of 3, 4.5, 6, 9, 12, 18, 24, and 27 Mb/s.
> The support of transmitting and
> receiving at data rates of 3, 6, and 12 Mb/s is mandatory when using
> 10 MHz channel spacing. The half-
> clocked operation doubles symbol times and clear channel assessment
> (CCA) times when using 10 MHz
> channel spacing. The regulatory requirements and information regarding
> use of this OFDM system in
> 4.9 GHz and 5 GHz bands is in Annex I and Annex J.<<
>
> They probably did not highlight 2.4GHz usage because of mixed-mode
> (non-OFDM) crowding, although nowadays we could actually move this
> band to OFDM-only as well.
>
> It is unfortunate that this allowance has disappeared in newer
> versions of the standard. Was that intentional?
>
> Reasons why downclocking is advantageous (up to +9dB link budget):
>
> * longer GI = better protection against multipath fading;
> * higher power density allowed (2x here) = better SNR;
> * less chance for (adjacent-channel) interference;
> * reduced TX & RX power consumption for idling and low load.
>
> I know that 802.11ah/af are here, but there exist literally millions
> of devices potentially supporting this old and trusty mode, software
> permit.
>
> Many Atheros chipsets support it, both old and new. OpenWrt has
> debugfs patches applied to enable this, while Linux has some other
> patches as well, although it is not user visible.
>
> If this is a legal and preferred mode, it would be nice if we could
> unify access.
>
> https://openwrt.org/docs/guide-user/network/wifi/basic?s[]=chanbw
> http://ccr.sigcomm.org/online/files/p135-chandra.pdf
> https://kabru.eecs.umich.edu/papers/publications/2011/xyzhang_kgshin_mobicom11.pdf
> https://www.etsi.org/deliver/etsi_en/300300_300399/300328/01.08.01_60/en_300328v010801p.pdf
> https://www.cwnp.com/forums/posts?postNum=305220
> https://forum.archive.openwrt.org/viewtopic.php?id=38590
> https://forum.openwrt.org/t/5-mhz-bandwith-option/3615
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

       reply	other threads:[~2018-10-08 20:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAPuHQ=G84HWdn6SfYqKswUW_FdUts-2zBXg5NvH8=h7jh38fSQ@mail.gmail.com>
2018-10-08 20:32 ` Dave Taht [this message]
2018-10-09  5:52   ` bkil
     [not found] ` <CAN+fvRbQREynDXF=PY=-OQkNLL2a=wXY6ZpqRJVp8k3-0cdDbg@mail.gmail.com>
2018-10-09  5:44   ` bkil
2018-11-15 15:36 Jon Pike

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=CAA93jw44LX2Qvhfw9PQJiJCv07GwAqt6wvTw0iudB0GpBb4e_A@mail.gmail.com \
    --to=dave.taht@gmail.com \
    --cc=bkil.hu+Aq@gmail.com \
    --cc=greearb@candelatech.com \
    --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