Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Bob McMahon <bob.mcmahon@broadcom.com>
To: Dave Taht <dave.taht@gmail.com>
Cc: David Lang <david@lang.hm>,
	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 18:22:41 -0000	[thread overview]
Message-ID: <CAHb6Lvpzz4t5LunABg5+RYHb+8NmgsjKk7A_Y4ybkZqYRpBs6w@mail.gmail.com> (raw)
In-Reply-To: <CAA93jw5KLgoFQeDE8EcufzHrhxEM53=M=EyLSu5VxYzM9fa2tA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3092 bytes --]

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.)   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?

Thanks,
Bob





On Mon, Jun 27, 2016 at 10:55 AM, Dave Taht <dave.taht@gmail.com> wrote:

> In terms of wifi history... since I go back to the 70s...
>
> was that we did not know how to do it - 73 we had aloha, which begat
> ethernet... and for years progress was slow. Even as late as 91 or so
> a "good" microwave link cost something like 40k an end, and required
> special cooling and permits on so on. Wifi was started as an ipx/spx
> bridge tech that didn't start to get anywhere until the mid 90s.
>
> It was far from obvious at any point that the cost reductions would
> take place that did, there was so much work in the analog domain that
> looked (at the time) resistant to moores law. As for spectrum, finding
> ways to leverage 2.4ghz cost metricom's backers in particular more
> money than I care to think about, and I'm always pointing at how the
> discovery that a more centralized clock and a retransmit at the mac
> layer is what eventually made 802.11b viable. Many other wireless
> ideas have been tried and died - wimax, for example, UWB, for another.
> Bluetooth has evolved into adding "discovery prototol", which was kind
> of unexpected... (there is even 6lopan over bluetooth now). The 5ghz
> spectrum users have tended to adopt their own mac, as has some other
> less popular bands.
>
> While I'm pretty happy that we've got much of the queuing theory for
> fixing 802.11n and 802.1ac nailed now, outstanding problems include
> the hidden station problem, the rise in the background noise levels,
> insufficient channels, and increasingly proprietary standards and
> chipsets, as well as transport, switching and routing protocols
> layered on top originally designed for isochronus transports.
>
> I like to think (or possibly delude myself), that the solutions to
> airtime fairness scheduling now emerging may one day lead to saner
> scheduling around the hidden station problem in particular. Otherwise,
> and elsewhere, there remain a lot of rocks to bang together, and a
> long list of other issues we've captured elsewhere.
>
> I am still periodically reviewing and updating this as we go along, as
> it remains the best central document we have on all that's wrong in
> wifi with some hints as to how to go about fixing them.
>
>
> https://docs.google.com/document/d/1Se36svYE1Uzpppe1HWnEyat_sAGghB3kE285LElJBW4/edit
>

[-- Attachment #2: Type: text/html, Size: 3811 bytes --]

  reply	other threads:[~2016-06-27 18:22 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 [this message]
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
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=CAHb6Lvpzz4t5LunABg5+RYHb+8NmgsjKk7A_Y4ybkZqYRpBs6w@mail.gmail.com \
    --to=bob.mcmahon@broadcom.com \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=dave.taht@gmail.com \
    --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