From: David Lang <david@lang.hm>
To: Jason Abele <jason.abele@gmail.com>
Cc: moeller0 <moeller0@gmx.de>,
make-wifi-fast@lists.bufferbloat.net,
Bob McMahon <bob.mcmahon@broadcom.com>,
"cerowrt-devel@lists.bufferbloat.net"
<cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi
Date: Mon, 27 Jun 2016 12:27:56 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.02.1606271223520.22898@nftneq.ynat.uz> (raw)
In-Reply-To: <CADSPesWuwTNTwSu1BgF1Vy0vGD89wbXCGeN7s8DR44OM48vkYg@mail.gmail.com>
On Mon, 27 Jun 2016, Jason Abele wrote:
> The reason you can not just add bits to the ADC is the thermal noise
> floor: https://en.wikipedia.org/wiki/Johnson%E2%80%93Nyquist_noise#Noise_power_in_decibels
>
> If you assume a maximum transmit power of ~20dBm (100mW) and a 160MHz
> channel bandwidth (with a consequent thermal noise floor of -92 dBm),
> the total possible dynamic range is ~112dB, if you receiver and
> transmitter a coupled with no loss. At ~6dB/bit in the ADC, anything
> beyond 19bits is just quantizing noise and wasting power (which is
> heat, which raises your local thermal noise floor, etc). If your
> channel bandwidth is 1GHz, the effective noise floor rises by another
> ~2bits, so ~17bits of dynamic range max, before accounting for path
> loss and distortion.
>
> Speaking of distortion, look at the intermod (IP3) or harmonic
> distortion figures for those wideband ADC sometime, if the signals of
> interest are of widely varying amplitudes in narrower bandwidths, the
> performance limit will usually be distortion from the strongest
> signal, not the thermal noise floor. This usually limits dynamic
> range to less than 10 effective bits.
>
> Also transmitters are usually only required to suppress their adjacent
> channel noise to around -50dB below the transmit power, so a little
> over 8bits of dynamic range before the ADC is quantizing an interferer
> rather than the signal of interest.
Thanks for the more detailed information.
> I am surprised that 802.11 still uses the same spreading code for all
> stations. I am no expert on cellular CDMA deployments, but I think
> they have been using different spreading codes for each station to
> increase capacity and improve the ability to mathematically remove the
> interference of other physically close stations for decades.
Cellular mostly works because they have hundreds/thousands of channels rather
than tens.
> As complex as the 802.11 MAC is becoming, I do not understand why an approach
> like MU-MIMO was chosen over negotiating a separate spreading code per
> station.
compatibility and the fact that stations with different spreading algorithms
still interfere with each other. Also, coordinating the 'right' spreading
algorithm for each station with each AP (including ones with hidden SSIDs)
> My best guess is that it keeps the complexity (and therefore power) at
> the AP rather than in the (increasingly mobile, power-constrained)
> station. Hopefully the rise of mesh / peer-to-peer networks in mobile
> stations will apply the right engineering pressure to re-think the
> idea of keeping all complexity in the AP.
Almost all the mesh work I see is using a mesh of APs, anything beyond that is
wishful thinking.
Even mu-mimo requires some client support.
David Lang
next prev parent reply other threads:[~2016-06-27 19:28 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-24 21:24 dpreed
2016-06-26 22:54 ` Bob McMahon
2016-06-27 0:00 ` David Lang
2016-06-27 2:23 ` Bob McMahon
2016-06-27 3:01 ` David Lang
2016-06-27 17:55 ` Dave Taht
2016-06-27 18:22 ` Bob McMahon
2016-06-27 19:40 ` David Lang
2016-06-27 20:05 ` Bob McMahon
2016-06-27 20:09 ` David Lang
2016-06-27 20:34 ` Bob McMahon
2016-06-27 21:09 ` David Lang
2016-06-27 22:12 ` Bob McMahon
2016-06-27 22:18 ` David Lang
2016-06-28 1:09 ` Bob McMahon
2016-06-27 6:34 ` Sebastian Moeller
2016-06-27 7:44 ` David Lang
2016-06-27 9:43 ` moeller0
2016-06-27 17:39 ` Jason Abele
2016-06-27 19:27 ` David Lang [this message]
2016-06-27 19:22 ` David Lang
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/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.02.1606271223520.22898@nftneq.ynat.uz \
--to=david@lang.hm \
--cc=bob.mcmahon@broadcom.com \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=jason.abele@gmail.com \
--cc=make-wifi-fast@lists.bufferbloat.net \
--cc=moeller0@gmx.de \
/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