[Cerowrt-devel] wifi over narrow channels

[Cerowrt-devel] wifi over narrow channels

[Dave Taht]

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

Re: [Cerowrt-devel] wifi over narrow channels

[Joel Wirāmu Pauling]

IIRC only some of the ath9k radio's are able to do 5mhz channels -
namely the enterprise chip variants.

-Joel

On 9 October 2014 11:14, Dave Taht <dave.taht@gmail.com> wrote:
> 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

Re: [Cerowrt-devel] wifi over narrow channels

[dpreed]

[-- 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 --]

Re: [Cerowrt-devel] wifi over narrow channels

[David Lang]

[-- Attachment #1: Type: TEXT/Plain, Size: 6218 bytes --]

The problem is that you really have trouble with different transmitters sharing 
one channel over a wide area. By having more channels and smaller areas that 
each one covers you end up with better coverage overall, less interference and 
greater throughput.

If it was really possible to have different transmitters talking at the same 
time on the same channel, this wouldn't be a problem, but we really can't in 
practice [*], so it is a problem.

The key problems show up because you can have two mobile stations on opposite 
sides of the AP that can't hear each other, but can hear the AP just fine. When 
they both transmit, the AP can't listen to both at once (it's technically 
possible if the two signals are very close to the same strength, but if one is 
significantly more powerful than the other, the weaker one gets lost in the 
noise)

So in practice, you are better off with more APs on different channels with the 
APs connected together than you are with fewer, faster channels covering a 
larger area per channel.

Things like a fixed "listen before transmit" wait time just emphisise this 
because they mean that as the bit rate of the channel goes up, you are wasting 
a higher percentage of the capability when you are transmitting the same amount 
of data.

If you wait 4ms and then transmit for 28ms, you are wasting 1/8 of the channel 
bandwidth, but if you can transmit the same data in 12ms, you are wasting 1/4 of 
the channel bandwidth.

Now, shorter transmissions do mean that there is less chance that someone else 
who you can't hear will transmit, but having that other station on a different 
channel talking to an AP that's closer to it will do even better.


[*] In theory, spread spectrum transmission allows you to have different 
stations talking on the same wideband channel without interfering with each 
other.

In practice there are a few problems with this.

1. the different sets of transmissions need to have different transmission 
patterns (keys), and these patterns need to be distributed to all the stations 
using a particular key.

2. not all keys are equally good, especially when combined with other keys in 
use, so coordination of the keys is needed.

3. timing on all the different radios in the network is critical so that they 
all start looking at the same time. This is something that is very hard to get 
in practice without some external timekeeping being provided (some equipment 
would use the broadcast TV sync timing before it went digital for example)

4. You still have the problem of not being able to transmit and receive at the 
same time.

5. The RF signal gets amplified by a variable amount to make the resulting 
signal a constant strength before it's decoded. The RF signal from different 
transmitters is falling off at roughly the cube of the distance, and the 
decoders have 12-14 bits of resolution. If a more distant station is 
transmitting at the same time as a nearby station, this makes the distant staton 
unreadable because it's signal ends up being represented by too few bits in the 
decoder.

David Lang

On Thu, 9 Oct 2014, dpreed@reed.com wrote:

> 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/PLAIN, Size: 164 bytes --]

_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] wifi over narrow channels

[David P. Reed]

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

David -

1) you are right that LBT fails because propagation does not allow a transmitter to hear the stations that might be transmitting on the same channel. But LBT need not be the optimal approach for the general idea of packet  multiplexing. A better decentralized approach is rts/cts. Think about it. Start with that idea and improve it... I'm leaving it there as a learning moment. You'll learn more by improving it than by having me tell you.

2) co channel separation was hard before computing and sampling became good. It is no longer hard unless you handicap your thinking by thinking it is hard.

3) spread spectrum is the first non- narrowband modulation technique. It is far from the best.  Consider very wideband wavelet coding...

4) subdivision of space time is wasteful in the extreme. Why try to create walls when the space around the walls becomes useless? The denser the walls in space time and frequency the more waste...

Radio is not the sin or cos function.  There is nothing in either Maxwell or QED  that invokes Fourier. Nothing.

On Oct 14, 2014, David Lang <david@lang.hm> wrote:
>The problem is that you really have trouble with different transmitters
>sharing
>one channel over a wide area. By having more channels and smaller areas
>that
>each one covers you end up with better coverage overall, less
>interference and
>greater throughput.
>
>If it was really possible to have different transmitters talking at the
>same
>time on the same channel, this wouldn't be a problem, but we really
>can't in
>practice [*], so it is a problem.
>
>The key problems show up because you can have two mobile stations on
>opposite
>sides of the AP that can't hear each other, but can hear the AP just
>fine. When
>they both transmit, the AP can't listen to both at once (it's
>technically
>possible if the two signals are very close to the same strength, but if
>one is
>significantly more powerful than the other, the weaker one gets lost in
>the
>noise)
>
>So in practice, you are better off with more APs on different channels
>with the
>APs connected together than you are with fewer, faster channels
>covering a
>larger area per channel.
>
>Things like a fixed "listen before transmit" wait time just emphisise
>this
>because they mean that as the bit rate of the channel goes up, you are
>wasting
>a higher percentage of the capability when you are transmitting the
>same amount
>of data.
>
>If you wait 4ms and then transmit for 28ms, you are wasting 1/8 of the
>channel
>bandwidth, but if you can transmit the same data in 12ms, you are
>wasting 1/4 of
>the channel bandwidth.
>
>Now, shorter transmissions do mean that there is less chance that
>someone else
>who you can't hear will transmit, but having that other station on a
>different 
>channel talking to an AP that's closer to it will do even better.
>
>
>[*] In theory, spread spectrum transmission allows you to have
>different
>stations talking on the same wideband channel without interfering with
>each
>other.
>
>In practice there are a few problems with this.
>
>1. the different sets of transmissions need to have different
>transmission
>patterns (keys), and these patterns need to be distributed to all the
>stations
>using a particular key.
>
>2. not all keys are equally good, especially when combined with other
>keys in
>use, so coordination of the keys is needed.
>
>3. timing on all the different radios in the network is critical so
>that they
>all start looking at the same time. This is something that is very hard
>to get
>in practice without some external timekeeping being provided (some
>equipment
>would use the broadcast TV sync timing before it went digital for
>example)
>
>4. You still have the problem of not being able to transmit and receive
>at the
>same time.
>
>5. The RF signal gets amplified by a variable amount to make the
>resulting
>signal a constant strength before it's decoded. The RF signal from
>different
>transmitters is falling off at roughly the cube of the distance, and
>the
>decoders have 12-14 bits of resolution. If a more distant station is
>transmitting at the same time as a nearby station, this makes the
>distant staton
>unreadable because it's signal ends up being represented by too few
>bits in the
>decoder.
>
>David Lang
>
>On Thu, 9 Oct 2014, dpreed@reed.com wrote:
>
>> 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
>>>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Cerowrt-devel mailing list
>Cerowrt-devel@lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/cerowrt-devel

-- Sent from my Android device with K-@ Mail. Please excuse my brevity.

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