From: dpreed@reed.com
To: "Dave Taht" <dave.taht@gmail.com>
Cc: "cerowrt-devel@lists.bufferbloat.net"
<cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] wifi over narrow channels
Date: Thu, 9 Oct 2014 10:25:20 -0400 (EDT) [thread overview]
Message-ID: <1412864720.98961528@apps.rackspace.com> (raw)
In-Reply-To: <CAA93jw4OXSXe2zDk12Q0icus6+eKz0VnnaReoppXeGT3WFm3tg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3000 bytes --]
Wideband is far better for scaling than narrowband, though. This may seem counterintuitive, but narrowband systems are extremely inefficient. They appeal to 0/1 thinking intuitively, but in actual fact the wider the bandwidth the more sharing and the more scaling is possible (and not be "balkanization" or "exclusive channel negotiation").
Two Internets are far worse than a single Internet that combines both. That's because you have more degrees of freedom in a single network than you can in two distinct networks, by a combinatorial factor.
The analogy holds that one wide band is far better than two disjoint bands in terms of scaling and adaptation. The situation only gets better because of the physics of "multipath", which creates more problems the more narrowband the signal, and when the signal is a single frequency, multipath is disastrous.
The same is true if you try to divide space into disjoint "channels" (as cellular tries to).
So in the near term, narrowband wifi might be a short-term benefit, but long-term it is 180 degress away from where you want to go.
(the listen-before-talk protocol in WiFi is pragmatic because it is built into hardware today, but terrible for wideband signals, because you can't shorten the 4 usec. pre-transmit delay, and probably need to lengthen it, since 4 usec. is about 1.25 km or 0.8 miles, and holds 40 bits at 10 Mb/s, or 4000 bits at 1 Gb/sec).
Either for distance or for rate, the "Ethernet MAC+PHY" was designed for short "coax" or "hub" domains. Its not good for digital wireless Internet, except for one thing: it is based on distributed control that does not require any advance planning.
If you want to improve open wireless, you have to a) go wide, b) maintain distributed control, c) get rid of listen-before-talk to replace it with a mixture of co-channel decoding and propagation negotiation. Then you can beat cellular trivially.
I wish I could attract investment away from the "short term" WiFi thinking, but in the last 15 years, I've failed. Meanwhile WiFi also attracts those people who want to add bufferbloat into the routers because they don't understand congestion control.
Sad.
On Wednesday, October 8, 2014 6:14pm, "Dave Taht" <dave.taht@gmail.com> said:
> https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final142.pdf
>
> I've had 5mhz channels working in the ath9k at various points in
> cerowrt's lifetime. (using it for meshy stuff) After digesting most of
> the 802.11ac standard I do find myself wishing they'd gone towards
> narrower channels rather than wider.
>
> The netgear x4 defaults to a 160mhz wide channel. :sigh:
>
> The above paper has some nifty ideas in it.
>
> --
> Dave Täht
>
> https://www.bufferbloat.net/projects/make-wifi-fast
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
[-- Attachment #2: Type: text/html, Size: 5345 bytes --]
next prev parent reply other threads:[~2014-10-09 14:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-08 22:14 Dave Taht
2014-10-08 22:22 ` Joel Wirāmu Pauling
2014-10-09 14:25 ` dpreed [this message]
2014-10-14 4:30 ` David Lang
2014-10-14 12:21 ` David P. Reed
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=1412864720.98961528@apps.rackspace.com \
--to=dpreed@reed.com \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
/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