From: David Lang <david@lang.hm>
To: Bob McMahon <bob.mcmahon@broadcom.com>
Cc: Dave Taht <dave.taht@gmail.com>,
make-wifi-fast@lists.bufferbloat.net,
"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 13:09:42 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.02.1606271307440.22898@nftneq.ynat.uz> (raw)
In-Reply-To: <CAHb6LvrEkbjC6XZv7ZsT=dNQwK7q43GeCNmHNnd8EyEGUu8v=g@mail.gmail.com>
On Mon, 27 Jun 2016, Bob McMahon wrote:
> The ~10K is coming from empirical measurements where all aggregation
> technologies are disabled, i.e. only one small IP packet per medium
> arbitration/access and where there is only one transmitter and one
> receiver. 900Mb/sec is typically a peak-average throughput measurement
> where max (or near max) aggregation occurs, amortizing the access overhead
> across multiple packets.
so 10K is minimum size packets being transmitted?or around 200 transmissions/sec
(plus 200 ack transmissions/sec)?
> Yes, devices can be hidden from each other but not from the AP (hence the
> use of RTS/CTS per hidden node mitigation.) Isn't it the AP's view of the
> "carrier state" that matters (at least in infrastructure mode?) If that's
> the case, what about a different band (and different radio) such that the
> strong signal carrying the data could be separated from the the BSSID's
> "carrier/energy state" signal?
how do you solve the interference problem on this other band/radio? When you
have other APs in the area operating, you will have the same problem there.
David Lang
> Bob
>
> On Mon, Jun 27, 2016 at 12:40 PM, David Lang <david@lang.hm> wrote:
>
>> On Mon, 27 Jun 2016, Bob McMahon wrote:
>>
>> Hi All,
>>>
>>> This is a very interesting thread - thanks to all for taking the time to
>>> respond. (Personally, I now have better understanding of the
>>> difficulties
>>> associated with a PHY subsystem that supports a wide 1GHz.)
>>>
>>> Not to derail the current discussion, but I am curious to ideas on
>>> addressing the overhead associated with media access per collision
>>> avoidance. This overhead seems to be limiting transmits to about 10K per
>>> second (even when a link has no competition for access.)
>>>
>>
>> I'm not sure where you're getting 10K/second from. We do need to limit the
>> amount of data transmitted in one session to give other stations a chance
>> to talk, but if the AP replies immediatly to ack the traffic, and the
>> airwaves are idle, you can transmit again pretty quickly.
>>
>> people using -ac equipment with a single station are getting 900Mb/sec
>> today.
>>
>> Is there a way,
>>> maybe using another dedicated radio, to achieve near instantaneous
>>> collision detect (where the CD is driven by the receiver state) such that
>>> mobile devices can sample RF energy to get theses states and state changes
>>> much more quickly?
>>>
>>
>> This gets back to the same problems (hidden transmitter , and the
>> simultanious reception of wildly different signal strengths)
>>
>> When you are sending, you will hear yourself as a VERY strong signal,
>> trying to hear if someone else is transmitting at the same time is almost
>> impossible (100 ft to 1 ft is 4 orders of magnatude, 1 ft to 1 inch is
>> another 2 orders of magnatude)
>>
>> And it's very possible that the station that you are colliding with isn't
>> one you can hear at all.
>>
>> Any AP is going to have a better antenna than any phone. (sometimes
>> several orders of magnatude better), so even if you were located at the
>> same place as the AP, the AP is going to hear signals that you don't.
>>
>> Then consider the case where you and the other station are on opposite
>> sides of the AP at max range.
>>
>> and then add cases where there is a wall between you and the other
>> station, but the AP can hear both of you.
>>
>> David Lang
>>
>
next prev parent reply other threads:[~2016-06-27 20:09 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 [this message]
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
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.1606271307440.22898@nftneq.ynat.uz \
--to=david@lang.hm \
--cc=bob.mcmahon@broadcom.com \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=dave.taht@gmail.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