* Re: [Bloat] Dual Channel Wi-Fi
2019-09-13 6:13 ` Dave Taht
@ 2019-09-13 7:18 ` Dave Taht
2019-09-13 9:13 ` Sebastian Moeller
2019-09-13 11:58 ` Toke Høiland-Jørgensen
2 siblings, 0 replies; 7+ messages in thread
From: Dave Taht @ 2019-09-13 7:18 UTC (permalink / raw)
To: David Lang; +Cc: Etienne Champetier, bloat
and this: https://www.edgewaterwireless.com/
On Fri, Sep 13, 2019 at 7:13 AM Dave Taht <dave.taht@gmail.com> wrote:
>
> There's more to it than that.
>
> https://www-res.cablelabs.com/wp-content/uploads/2019/06/24150908/Dual-Channel-Wi-Fi-Performance-Test-Report-June-2019.pdf
>
> On Fri, Sep 13, 2019 at 7:03 AM David Lang <david@lang.hm> wrote:
> >
> > it's an optimization that will work well when there is only one person using the
> > network, and utterly collapse when there is a lot of use.
> >
> > it assumes that 'high priority' and bulk things only move in one direction, it
> > uses more channels, which will cause more collisions with other users and other
> > networks.
> >
> > a fairly typical type of idea to someone who doesn't look at what's actually
> > happening at the RF level.
> >
> > David Lang
> >
> > On Fri, 13 Sep 2019, Etienne Champetier wrote:
> >
> > > Date: Fri, 13 Sep 2019 14:47:38 +0900
> > > From: Etienne Champetier <champetier.etienne@gmail.com>
> > > To: bloat <bloat@lists.bufferbloat.net>
> > > Subject: [Bloat] Dual Channel Wi-Fi
> > >
> > > I'm curious what people on this mailing list think about this Wi-Fi
> > > optimisation
> > >
> > > https://www.cablelabs.com/technologies/dual-channel-wi-fi
> > > https://github.com/openwrt/packages/pull/9972
> > >
> > _______________________________________________
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
>
>
>
> --
>
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-205-9740
--
Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bloat] Dual Channel Wi-Fi
2019-09-13 6:13 ` Dave Taht
2019-09-13 7:18 ` Dave Taht
@ 2019-09-13 9:13 ` Sebastian Moeller
2019-09-13 11:58 ` Toke Høiland-Jørgensen
2 siblings, 0 replies; 7+ messages in thread
From: Sebastian Moeller @ 2019-09-13 9:13 UTC (permalink / raw)
To: Dave Täht; +Cc: David Lang, bloat
I am with David, this is going to be fun on densely populated apartment buildings. For people with no RF-competition it is sort of a "nice" trick to more or less go "duplex".
What a I missing?
Best Regards
Sebastian
> On Sep 13, 2019, at 08:13, Dave Taht <dave.taht@gmail.com> wrote:
>
> There's more to it than that.
>
> https://www-res.cablelabs.com/wp-content/uploads/2019/06/24150908/Dual-Channel-Wi-Fi-Performance-Test-Report-June-2019.pdf
>
> On Fri, Sep 13, 2019 at 7:03 AM David Lang <david@lang.hm> wrote:
>>
>> it's an optimization that will work well when there is only one person using the
>> network, and utterly collapse when there is a lot of use.
>>
>> it assumes that 'high priority' and bulk things only move in one direction, it
>> uses more channels, which will cause more collisions with other users and other
>> networks.
>>
>> a fairly typical type of idea to someone who doesn't look at what's actually
>> happening at the RF level.
>>
>> David Lang
>>
>> On Fri, 13 Sep 2019, Etienne Champetier wrote:
>>
>>> Date: Fri, 13 Sep 2019 14:47:38 +0900
>>> From: Etienne Champetier <champetier.etienne@gmail.com>
>>> To: bloat <bloat@lists.bufferbloat.net>
>>> Subject: [Bloat] Dual Channel Wi-Fi
>>>
>>> I'm curious what people on this mailing list think about this Wi-Fi
>>> optimisation
>>>
>>> https://www.cablelabs.com/technologies/dual-channel-wi-fi
>>> https://github.com/openwrt/packages/pull/9972
>>>
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>
>
>
> --
>
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-205-9740
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bloat] Dual Channel Wi-Fi
2019-09-13 6:13 ` Dave Taht
2019-09-13 7:18 ` Dave Taht
2019-09-13 9:13 ` Sebastian Moeller
@ 2019-09-13 11:58 ` Toke Høiland-Jørgensen
2 siblings, 0 replies; 7+ messages in thread
From: Toke Høiland-Jørgensen @ 2019-09-13 11:58 UTC (permalink / raw)
To: Dave Taht, David Lang; +Cc: bloat
Dave Taht <dave.taht@gmail.com> writes:
> There's more to it than that.
>
> https://www-res.cablelabs.com/wp-content/uploads/2019/06/24150908/Dual-Channel-Wi-Fi-Performance-Test-Report-June-2019.pdf
Looking at the code[0], it seems to be a userspace daemon that does
encapsulation of traffic and sends it over a separate, hidden BSS that
is access-controlled to only allow stations that already performed their
handshake.
So, conceptually it turns several WiFi links into a bonded device where
the AP can steer the traffic between underlying devices.
It's an interesting idea, but I doubt it'll see much deployment: Just
the requirement of running a daemon on each client device is bound to
put a damper on that. It's not quite clear to me whether the station
would need to support associating on multiple bands at the same time;
not sure how many clients do that...
Also, I wonder how well the userspace encapsulation stuff works on a
low-powered AP?
-Toke
[0] https://github.com/ewsi/dcstad is the client daemon; the github org
has the rest.
^ permalink raw reply [flat|nested] 7+ messages in thread