Re: [Cerowrt-devel] more mt7621 gear

[Outback Dingo]

my mt7621  AP arrived today, ill be checking it out, also note i found
this

https://mqmaker.com/

On Tue, Apr 26, 2016 at 6:48 AM, Outback Dingo 
wrote:

> https://detail.1688.com/offer/1277654521.html
>
> same specs same device 330 RMB... i just ordered one
>
> On Tue, Apr 26, 2016 at 6:23 AM, Outback Dingo 
> wrote:
>
>> this is the same device
>> http://www.zbtlink.com/products/router/ZBT-WG2926.html
>>
>> On Tue, Apr 26, 2016 at 6:13 AM, Outback Dingo 
>> wrote:
>>
>>> NO my wife says its 340 rmb... like less then 60 USD
>>>
>>> On Tue, Apr 26, 2016 at 6:02 AM, Dave Taht  wrote:
>>>
 340 bucks each, am I reading it right?

 as data sheets go, that's not bad (there are more in that dir), but
 what I wanted was the register sets for the wifi and cpu chips.

 On Mon, Apr 25, 2016 at 8:57 PM, Outback Dingo 
 wrote:
 > router itself
 >
 http://cn.made-in-china.com/showroom/szzbtdz/product-detailUMVJbARKZCkv/ZBT-WG3526%E6%99%BA%E5%8D%9A%E9%80%9A%E9%AB%98%E7%AB%AF%E5%8F%8C%E9%A2%91%E5%A4%A7%E5%8A%9F%E7%8E%87%E6%99%BA%E8%83%BD%E6%97%A0%E7%BA%BF%E8%B7%AF%E7%94%B1%E5%99%A8%E5%AE%9A%E5%88%B6OEM.html
 >
 > chip set http://ftp.mqmaker.com/WiTi/Docs/Hardware/MT7621.pdf
 >
 > On Tue, Apr 26, 2016 at 4:38 AM, Dave Taht 
 wrote:
 >>
 >> detailed documentation on the chipset would be nice... in any
 language
 >>
 >> On Mon, Apr 25, 2016 at 7:16 PM, Outback Dingo <
 outbackdi...@gmail.com>
 >> wrote:
 >> > guys,
 >> >
 >> > I am in china right now, i can probably source this in a day, let
 me
 >> > know if
 >> > you want me to get one for you and ill forward it, im going to try
 to
 >> > order
 >> > one today for myself
 >> >
 >> > On Tue, Apr 26, 2016 at 12:49 AM, Dave Taht 
 wrote:
 >> >>
 >> >> Please send 1 mediatek router (and pcie card when you get 'em) to:
 >> >>
 >> >> Dave Taht & Lorna Reed
 >> >> 225 11th Ave apt 302
 >> >> San Francisco, Ca, 94118-2167
 >> >>
 >> >> I don't think I have time for the usb version.
 >> >>
 >> >> I am standardizing on this for my upcoming work. It's pretty darn
 >> >> libre, perhaps you could become a reseller of this also
 >> >>
 >> >> http://pcengines.ch/apu2c4.htm
 >> >>
 >> >> On Mon, Apr 25, 2016 at 3:43 PM, Christopher Waid
 >> >>  wrote:
 >> >> > On 2016-04-25 06:37 PM, Dave Taht wrote:
 >> >> >>
 >> >> >>
 >> >> >>
 >> >> >>
 >> >> >>
 https://www.linkedin.com/pulse/mt7621-openwrt-dual-band-5-gigabit-port-router-support-anna-lee
 >> >> >>
 >> >> >> chris, you get anything in worth hacking on yet?
 >> >> >
 >> >> >
 >> >> > Yes- I think so. Didn't I send an email about this already? I
 don't
 >> >> > think
 >> >> > anyone responded though. Or maybe I failed to read the
 responses. I
 >> >> > asked if
 >> >> > anybody would like me to send them a mediatek chipset based
 router
 >> >> > board. If
 >> >> > people did email me please let me know again who you are. I
 know we
 >> >> > didn't
 >> >> > send out any of the router boards. I got 5 of them I believe.
 >> >> >
 >> >> > I'm currently flying back from the [GNU]LinuxFest North West
 event...
 >> >> > but if
 >> >> > people provide me addresses I can send out some sample router
 boards
 >> >> > to
 >> >> > start playing with.
 >> >> >
 >> >> > I also got some USB mediatek chipset based wifi dongles in as
 well I
 >> >> > believe. I forget how many of these I got. I also am brining in
 some
 >> >> > PCIE
 >> >> > mediatek cards theoretically although I'm unsure if we're
 actually
 >> >> > getting
 >> >> > our hands on these. I think the orders might have been canceled
 or
 >> >> > something- or maybe I just didn't follow up on checking the
 goods
 >> >> > shipped.
 >> >>
 >> >>
 >> >>
 >> >> --
 >> >> Dave Täht
 >> >> Let's go make home routers and wifi faster! With better software!
 >> >> http://blog.cerowrt.org
 >> >> ___
 >> >> Cerowrt-devel mailing list
 >> >> Cerowrt-devel@lists.bufferbloat.net
 >> >> https://lists.bufferbloat.net/listinfo/cerowrt-devel
 >> >
 >> >
 >>
 >>
 >>
 >> --
 >> Dave Täht
 >> Let's go make home routers and wifi faster! With better software!
 >> http://blog.cerowrt.org
 >
 >



 --
 Dave Täht
 Let's go make home routers and wifi faster! With better software!
 http://blog.cerowrt.org

>>>
>>>
>>
>
___
Cerowrt-devel 

Re: [Cerowrt-devel] LimeSDR: Flexible, Next-generation, Open Source Software Defined Radio

[Outback Dingo]

On Fri, Apr 29, 2016 at 12:54 AM, Eric Johansson  wrote:

>
>
> On 4/28/2016 4:58 PM, David Lang wrote:
>
>> so what are the technical specs, costs, and expected shipping date?
>>
>> a 10 antenna SDR system with a FPGA opens up some very interesting
>> possibilities.
>>
>>
> https://www.crowdsupply.com/lime-micro/limesdr
>
>
>
>
wish i could buy 2 right now they look nice



> ___
> 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

Re: [Cerowrt-devel] LimeSDR: Flexible, Next-generation, Open Source Software Defined Radio

[Eric Johansson]

On 4/28/2016 4:58 PM, David Lang wrote:

so what are the technical specs, costs, and expected shipping date?

a 10 antenna SDR system with a FPGA opens up some very interesting 
possibilities.




https://www.crowdsupply.com/lime-micro/limesdr


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

Re: [Cerowrt-devel] LimeSDR: Flexible, Next-generation, Open Source Software Defined Radio

[David Lang]

found it

https://www.crowdsupply.com/lime-micro/limesdr

early bird price $199 100Khz-3.8GHz, >60MHz bandwidth at 12 bit sample depth

4 transmit and 6 receive antennas, two separate transmitters and two separate 
receivers.


USB 3 interface.

looks intereting

David Lang


On Thu, 28 Apr 2016, David Lang wrote:


Date: Thu, 28 Apr 2016 13:58:47 -0700 (PDT)
From: David Lang 
To: Eric Johansson 
Cc: "cerowrt-devel@lists.bufferbloat.net"

Subject: Re: [Cerowrt-devel] LimeSDR: Flexible, Next-generation,
Open Source Software Defined Radio

so what are the technical specs, costs, and expected shipping date?

a 10 antenna SDR system with a FPGA opens up some very interesting 
possibilities.


David Lang

On Thu, 28 Apr 2016, Eric Johansson wrote:


Date: Thu, 28 Apr 2016 16:39:35 -0400
From: Eric Johansson 
To: "cerowrt-devel@lists.bufferbloat.net"

Subject: [Cerowrt-devel] LimeSDR: Flexible, Next-generation,
Open Source Software Defined Radio

http://qrznow.com/limesdr-flexible-next-generation-open-source-software-defined-radio

from the advertising copy:

A Software Defined Radio for Everyone
LimeSDR is a low cost, open source, apps-enabled (more on that later) 
software defined radio (SDR) platform that can be used to support just 
about any type of wireless communication standard, including UMTS, LTE, 
GSM, LoRa, Bluetooth, Zigbee, RFID, and Digital Broadcasting, to name but a 
few.


While most SDRs have remained the domain of RF and protocol experts, 
LimeSDR is usable by anyone familiar with the idea of an app store – 
LimeSDR is the first SDR to integrate with Snappy Ubuntu Core. This means 
you can easily download new LimeSDR apps from developers around the world. 
If you’re a developer yourself, then you can share and/or sell your LimeSDR 
apps through Snappy Ubuntu Core as well.



___
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
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] LimeSDR: Flexible, Next-generation, Open Source Software Defined Radio

[David Lang]

so what are the technical specs, costs, and expected shipping date?

a 10 antenna SDR system with a FPGA opens up some very interesting 
possibilities.


David Lang

On Thu, 28 Apr 2016, Eric Johansson wrote:


Date: Thu, 28 Apr 2016 16:39:35 -0400
From: Eric Johansson 
To: "cerowrt-devel@lists.bufferbloat.net"

Subject: [Cerowrt-devel] LimeSDR: Flexible, Next-generation,
Open Source Software Defined Radio

http://qrznow.com/limesdr-flexible-next-generation-open-source-software-defined-radio

from the advertising copy:

A Software Defined Radio for Everyone
LimeSDR is a low cost, open source, apps-enabled (more on that later) 
software defined radio (SDR) platform that can be used to support just 
about any type of wireless communication standard, including UMTS, LTE, 
GSM, LoRa, Bluetooth, Zigbee, RFID, and Digital Broadcasting, to name 
but a few.


While most SDRs have remained the domain of RF and protocol experts, 
LimeSDR is usable by anyone familiar with the idea of an app store – 
LimeSDR is the first SDR to integrate with Snappy Ubuntu Core. This 
means you can easily download new LimeSDR apps from developers around 
the world. If you’re a developer yourself, then you can share and/or 
sell your LimeSDR apps through Snappy Ubuntu Core as well.



___
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

[Cerowrt-devel] LimeSDR: Flexible, Next-generation, Open Source Software Defined Radio

[Eric Johansson]

http://qrznow.com/limesdr-flexible-next-generation-open-source-software-defined-radio

from the advertising copy:

A Software Defined Radio for Everyone
LimeSDR is a low cost, open source, apps-enabled (more on that later) 
software defined radio (SDR) platform that can be used to support just 
about any type of wireless communication standard, including UMTS, LTE, 
GSM, LoRa, Bluetooth, Zigbee, RFID, and Digital Broadcasting, to name 
but a few.


While most SDRs have remained the domain of RF and protocol experts, 
LimeSDR is usable by anyone familiar with the idea of an app store – 
LimeSDR is the first SDR to integrate with Snappy Ubuntu Core. This 
means you can easily download new LimeSDR apps from developers around 
the world. If you’re a developer yourself, then you can share and/or 
sell your LimeSDR apps through Snappy Ubuntu Core as well.



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

Re: [Cerowrt-devel] [Babel-users] [Make-wifi-fast] perverse powersave bug with sta/ap mode

[Juliusz Chroboczek]

>> What problem are you trying to solve?

> Less useless overhead on slow-speed networks (think VHF/UHF radio).

> DAD works by pretending that the colliding address should be in
> communication range, which is not true for mesh networks.

I understand that DAD is pretty useless in sparse mesh networks, but is it
worth adding a special case just to avoid three packets every time you
reboot?

If you've got links so slow that DAD is a significant overhead, perhaps
you should be looking into some generic form of header compression rather
than trying to special-case DAD.

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

Re: [Cerowrt-devel] [Babel-users] [Make-wifi-fast] perverse powersave bug with sta/ap mode

[Juliusz Chroboczek]

> I must admit I have been thinking about switching off Duplicate
> Address Detection for mesh interfaces automatically...

What problem are you trying to solve?

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

Re: [Cerowrt-devel] [Make-wifi-fast] [Babel-users] perverse powersave bug with sta/ap mode

[Juliusz Chroboczek]

> I believe the openwrt developers are thinking a long similar lines, see e.g. 
> https://lists.openwrt.org/pipermail/openwrt-devel/2015-June/033398.html

If I read this message right, what Luessing is doing are some special-case
hacks to reduce the number of ND multicasts.  He's not attempting a general
solution for multicast.

Which, unfortunately, is quite typical.  (BATMAN, the routing protocol
that Luessing et al develop, has a number of special-case hacks for ARP
and ND, probably also DHCPv4.)

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

[Cerowrt-devel] more integrated wifi functionality in the pipeline for hackerboards

[Dave Taht]

http://timesofindia.indiatimes.com/tech/more-gadgets/Samsungs-Artik-10-to-take-on-Raspberry-Pi/articleshow/52027629.cms

-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] Multicast IHUs [was: perverse powersave bug with sta/ap mode]

[Dave Taht]

On Thu, Apr 28, 2016 at 10:10 AM, Juliusz Chroboczek
 wrote:

>> 4) And ya know - it might merely be a (sadly common) bug. Everybody's
>> supposed to wake up for the multicast beacons and get a notification
>> there's more data to come.
>
> Yes, it's obviously a bug.  Just like you, I'm not suprised -- ad-hoc mode
> and power save is the kind of thing that's never tested.


No, this is the kind of thing that normal users of wifi use -
AP/station mode being the most common mode of operation.

adhoc - rarely functional or tested
power save - VERY tested for people that want to save major power,
which is everybody running on battery, pulling out every trick (even
dubious ones) to meet consumption goals (rather than network
connectivity goals).

I do not know to what extent or where the problem I am seeing is
actually happening, I can look at the multicast beacons harder to see
what's going on.

Wifi powersave is not "go to sleep entirely", it is "please wake up on
this schedule (250ms) so I can poke you with more unicast data if I
have any, it also requires (in the spec) that buffering the
accumulated packets be done til that beacon, and multicast packets are
supposed to be sent as CAB ("crap after beacon" in ath9k's
documentation, content after beacon, elsewhere).

The "buffering til you wake up" requirement is hell on trying to roll
a airtime fairness scheduler, or codel, in stack portions

Certainly many devices simply disassociate when they go to sleep nowadays.

-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] Multicast IHUs [was: perverse powersave bug with sta/ap mode]

[Dave Taht]

On Thu, Apr 28, 2016 at 10:10 AM, Juliusz Chroboczek
 wrote:
>> 1) Well, I have suggested that IHU messages actually be unicast rather
>> than bundled with the hello.
>
> Yes, you have suggested that before.  I answered I would implement that if
> somebody volunteered to do an experimental evaluation.  Nobody volunteered.

We do need to build the size of the community.

I am perpetually giving talks about wifi in front of various
audiences. Making the comment:

"how many of you use wifi, hands up"

Always gets a laugh (from those paying attention)

(sometimes I'm sufficiently annoyed at those not paying attention to
ask "those of you that are paying attention, hands up")

"How many of you understand how it works?"

and nearly all the hands go down.

"Why is this not a problem?", and then I launch into the talk

I guess it would be better to collect my(our) rants, problems, and
arguments, tone them down, and get something about - "wifi, the
dominant paradigm" into more widely read publications than these
mailing lists. The recent conference on wifi in DC had some data like
"3 billion wifi devices shipped last year".


>> That would help somewhat in this case.
>
> That's my intuition too, but I've learned to be wary of my intuitions.
> Doing wireless stuff without careful evaluation is not something I'll do
> again.

Yep. Need more people on these problems. I promise to care more after
we cut latencies under load on wifi by 2 orders of magnitude on 3
chipsets.

>> 2) A protocol that needs "always listening" capability could signal
>> the underlying stack to "make sure" these packets hit the air, and one
>> that also wants "please be lossy" capabl
>> I leave the actual implementation of that request to the fantasies of
>> the authors - a new dscp codepoint or three?
>> /me ducks
>
> No need to duck, Dave, it's very similar to what was done with UDP-Lite,
> where the use of a specific value in the protocol field signals the link
> layer not to discard corrupted frames.  I've never seen it in the wild,
> I wonder why.

Hmm.. In babel's case, switching it to udp-lite would be like 1 line
of code. Not that it would help (unless the "don't multicast this"
code is explicitly filtering out normal udp only), and the flag day
would be no fun, but certainly the basic properties of udplite aren't
entirely unaligned... I have done tests of udplite (I have a patch
available for it for netperf if anyone wants it) and over ipv6, at
least, it did seem to be quite routable over multiple hops.
*link-local* udp-lite should "just work".

>
>> 4) And ya know - it might merely be a (sadly common) bug. Everybody's
>> supposed to wake up for the multicast beacons and get a notification
>> there's more data to come.
>
> Yes, it's obviously a bug.  Just like you, I'm not suprised -- ad-hoc mode
> and power save is the kind of thing that's never tested.  I suggest you
> disable power saving on all your nodes and be done with it.

That does not bode well for normal homenet users in the long run.

> -- Juliusz



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] [Make-wifi-fast] [Babel-users] perverse powersave bug with sta/ap mode

[Dave Taht]

On Thu, Apr 28, 2016 at 8:44 AM, Dave Taht  wrote:
> On Thu, Apr 28, 2016 at 7:59 AM, Juliusz Chroboczek
>  wrote:
>>> Discovery is a special case, that is not quite multicast. [...]  So you
>>> don't need any facility to "reach all" in one message.
>>
>> Are we speaking of the IP Internet, or of some other network?
>
> Heh.  Wifi is "some other network", at this point. Perhaps it always
> was. It was originally targetted at IPX/SPX.
>
> As wifi has evolved all sorts of packets below the conventional link
> layer that are invisible to IP (management frames in general), perhaps
> finding saner ways of exposing these packet types and their properties
> to the conventional IP stack - and the IP stack to the properties of
> the wifi frames - would be of help.
>
> For example, I just "ate" the entire 802.11-2012 and 802.11ac
> specifications, notably section 9 (Aggregation stuff mostly) and annex
> G - for those of you into a digestif, they are publicly available via:
> http://standards.ieee.org/about/get/802/802.11.html
>
> In my case I was mostly looking for properties of ampdus that could be
> better leveraged for congestion control. It turns out that you *can*
> mark certain MPDUs as QosNOACK, which means that they will not be
> block acknowledged. Nobody does this... and, while you could form some
> IP packets with this property there's no way to do it on the ath10k
> (except in raw mode), and no hook for it on the ath9k, and no way of
> the IP layer saying to the 802.11 layer, "it's totally ok you can lose
> this".
>
> Elsewhere in the stack I am seeing retries of 10 (ath9k) and 15
> (Ath10k), and in the initial fq_codel implementation on ath10k, *ZERO*
> loss coming from the wifi layer on a string of traces. (I was
> leveraging codel's ecn marking abilities to "see" this ) The mac802.11
> portion also has sw retries as a global config, not as something that
> is per-station.
>
> I am certain, out there, there is some wifi EE dancing at how perfect
> they've made the wireless layer appear and "transparent" to IP, but I
> look at the aircap packet traces I just got with something akin to
> horror, 10s of ms of retries on stuff, eating other people's air, that
> I'd just as soon throw away, which also shows up on the xplot.org
> tcptraces on a wire downstream as spikes in rtt.
>
> (there is also the needed cts random backoff in there, also, which
> makes it hard to distinguish between retries at various rates and
> needed backoff. I am sick of manually tearing apart aircaps)
>
> Now, dpreed's position on how we do wireless wrong is a great starting
> point... I wish hd'd publish his 11 layer stack document somewhere...
>
>> A number of fundamental Internet protocols, such as ARP and ND, use
>> multicast for discovery (I see broadcast as a special case of multicast).
>> So if you want to implement the TCP/IP suite, your link layer needs to
>> support multicast.  Some people have tried to work around that (see
>> RFC 2022, for example), with IMHO little success.
>
> Sure wish more wifi folk drank with more ietf folk, more often.
> Starting 2 decades back.
>
>>
>> What you seem to be arguing is that it would be possible to design
>> a protocol suite that uses anycast for discovery.  While an interesting
>> research project, your suite would no longer be TCP/IP, good luck getting
>> it deployed.
>>
>> (So what's the solution?  As Toke suggested, push the multicast
>> implementation to the link layer -- have the link layer convert multicast
>> to multiple unicasts in a way that's invisible to the network layer.
>> After all, that's what the link layer is for -- hiding the idiosyncrasies
>> of a given physical layer from the network layer.)
>
> 1) Well, I have suggested that IHU messages actually be unicast rather
> than bundled with the hello. That would help somewhat in this case.
> (and also fix cases where multicast works and unicast doesn't).
> multicast hello would become more of a discovery protocol and you
> could actually signal you can "take" a unicast hello (via a new tlv)
> and establish an ongoing multicast-free association that way.
>
> Given the currently "perfect" characteristics of the underlying
> unicast wireless link layer that would tend to eliminate packet loss
> as a viable metric of quality. :(
>
> 2) A protocol that needs "always listening" capability could signal
> the underlying stack to "make sure" these packets hit the air, and one
> that also wants "please be lossy" capabl
>
> I leave the actual implementation of that request to the fantasies of
> the authors - a new dscp codepoint or three?
> /me ducks
>
> 3) There are other stats from minstrel, station association, crypto
> state, etc, that could be leveraged.
>
> 4) And ya know - it might merely be a (sadly common) bug. Everybody's
> supposed to wake up for the multicast beacons and get a notification
> there's more data to come.

5) be powersave aware.

turn powersave off 

Re: [Cerowrt-devel] [Make-wifi-fast] [Babel-users] perverse powersave bug with sta/ap mode

[moeller0]

> On Apr 28, 2016, at 15:43 , Toke Høiland-Jørgensen  wrote:
> 
> Juliusz Chroboczek  writes:
> 
>> For discovery, multicast is unavoidable -- there's simply no way you're
>> going to send a unicast to a node that you haven't discovered yet.
> 
> Presumably the access point could transparently turn IP-level multicast
> into a unicast frame to each associated station? Not sure how that would
> work in an IBSS network, though... Does the driver (or mac80211 stack)
> maintain a list of neighbours at the mac/phy level?

I believe the openwrt developers are thinking a long similar lines, see e.g. 
https://lists.openwrt.org/pipermail/openwrt-devel/2015-June/033398.html

Best Regards
Sebastian

> 
> -Toke
> ___
> 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

Re: [Cerowrt-devel] [Make-wifi-fast] [Babel-users] perverse powersave bug with sta/ap mode

[Juliusz Chroboczek]

> Discovery is a special case, that is not quite multicast. [...]  So you
> don't need any facility to "reach all" in one message.

Are we speaking of the IP Internet, or of some other network?

A number of fundamental Internet protocols, such as ARP and ND, use
multicast for discovery (I see broadcast as a special case of multicast).
So if you want to implement the TCP/IP suite, your link layer needs to
support multicast.  Some people have tried to work around that (see
RFC 2022, for example), with IMHO little success.

What you seem to be arguing is that it would be possible to design
a protocol suite that uses anycast for discovery.  While an interesting
research project, your suite would no longer be TCP/IP, good luck getting
it deployed.

(So what's the solution?  As Toke suggested, push the multicast
implementation to the link layer -- have the link layer convert multicast
to multiple unicasts in a way that's invisible to the network layer.
After all, that's what the link layer is for -- hiding the idiosyncrasies
of a given physical layer from the network layer.)

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

Re: [Cerowrt-devel] [Make-wifi-fast] [Babel-users] perverse powersave bug with sta/ap mode

[dpreed]

Discovery is a special case, that is not quite multicast. Discovery is 
"noticing".  A node wishing to be discovered must be noticed by one (or maybe 
more) already existent stations in a group (groups are noticed by any member 
being noticed by a member of another group).

So you don't need any facility to "reach all" in one message.  It's sufficient 
to "reach any". From that point on, it's a higher level problem of "association 
management" (tracking members and their reachability).  I use these general 
terms in quotes to step outside the frame limited to 802.11 and its rigid 
culture.

So the key to discovery is *anycast* not multicast.

So for example, a station that is not yet associated could follow some 
predictable sequence of transmissions, using a variety of MI transmissions 
(multiple input, i.e. multiple antennas transmitting simultaneously) with a 
variety of waveforms, where that sequence was determined to have a high 
probability of being noticed by at least one member of the group to be joined. 
A station noticing such a signal could then use the signal's form itself to 
respond and begin to bring that station into the group of stations that can 
hear each other, discovering further information (like mutual propagation 
characteristics (multipath/MIMO coefficients, attenuation (for equalization), 
noise)).

By conflating discovery with multicast, one loses design options for discovery 
and cooperative transmission. So yes, the "normative" centralized access point 
discovery now practiced in 802.11 nets assumes a sort of "multicast", but that 
is because we have "centralized" architectures, not mesh at the phy level.

On Thursday, April 28, 2016 9:43am, "Toke Høiland-Jørgensen"  
said:

> Juliusz Chroboczek  writes:
> 
>> For discovery, multicast is unavoidable -- there's simply no way you're
>> going to send a unicast to a node that you haven't discovered yet.
> 
> Presumably the access point could transparently turn IP-level multicast
> into a unicast frame to each associated station? Not sure how that would
> work in an IBSS network, though... Does the driver (or mac80211 stack)
> maintain a list of neighbours at the mac/phy level?
> 
> -Toke
> 


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

Re: [Cerowrt-devel] [Make-wifi-fast] [Babel-users] perverse powersave bug with sta/ap mode

[Toke Høiland-Jørgensen]

Juliusz Chroboczek  writes:

> For discovery, multicast is unavoidable -- there's simply no way you're
> going to send a unicast to a node that you haven't discovered yet.

Presumably the access point could transparently turn IP-level multicast
into a unicast frame to each associated station? Not sure how that would
work in an IBSS network, though... Does the driver (or mac80211 stack)
maintain a list of neighbours at the mac/phy level?

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

Re: [Cerowrt-devel] [Babel-users] [Make-wifi-fast] perverse powersave bug with sta/ap mode

[Juliusz Chroboczek]

> Multicast is seductive to designers who ignore the realities of
> propagation and channel coding issues, because they think it works one
> way, but the reality is quite different.

Hold on.

Mulsticast is used for two distinct purposes: for broadcast-style
applications (streaming), and for discovery (ARP, ND, mDNS, and of course
the Hello beaconing of routing protocols).

For broadcast-style applications, multicast can be replaced with multiple
unicast streams, as Netflix shows, although this is best done at the
routers rather than at the senders, since this allows building a single
distribution tree without the need for application-layer proxies ("CDNs").

For discovery, multicast is unavoidable -- there's simply no way you're
going to send a unicast to a node that you haven't discovered yet.

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

Re: [Cerowrt-devel] [Babel-users] [Make-wifi-fast] perverse powersave bug with sta/ap mode

[Juliusz Chroboczek]

> Has anyone modeled what the multicast to multiple-unicast efficiency
> threshold is?

An interesting experiment to perform, without doubt.  (Experiment would be
more interesting than modelling.)

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

Re: [Cerowrt-devel] [Babel-users] perverse powersave bug with sta/ap mode

[Juliusz Chroboczek]

> Well, at least one ( probably several) of the devices I have in the
> new lab has *very aggressive* power save, to where babel ipv6
> multicast traffic either doesn't sync up to the AP's request for
> multicast (or the sta's), or it is merely completely suppressed by the
> stack. (or lost due to a bug!)...

Ok, that would explain why babeld is not falling over correctly -- since
Hellos are being lost by the power management algorithm, the link quality
of the redundant link is very low, so we only fall over when the currently
used link has timed out rather than when its link quality has fallen below
a given level.

I'm still thinking it over, but right now I'm thinking that I'm not going
to work around this kind of damange at the babeld level.

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

Re: [Cerowrt-devel] [Make-wifi-fast] perverse powersave bug with sta/ap mode

[dpreed]

Interesting stuff.  A deeper problem with WiFi-type protocols is that the very 
idea of "multicast" on the PHY level (air interface) is flawed, based on a 
model of propagation that assumes that every station can be easily addressed 
simultaneously, at the same bitrate, etc. Multicast is seductive to designers 
who ignore the realities of propagation and channel coding issues, because they 
think it works one way, but the reality is quite different.

So just as years were wasted in the RTP and media streaming world on 
router/switch layer multicast (thought to be easy and more efficient), my 
personal opinion is that any wireless protocol that tries to solve problems 
with multicast at the PHY layer is a fragile, brittle design that will waste 
years of effort trying to make the horse dance on its forelegs.

THe list of issues is enormous, but the most obvious ones are a) equalization, 
b) inability to use MIMO, and c) PHY layer acknowledgment complexity.

The usual argument is that in some special case circumstance, using multicast 
is "optimal".  But how much better is that "optimal" than the non-multicast 
general solution, and how does that "optimization" make the normal operation 
worse, in common conditions?

Whenever someone says that a "cross layer optimization" or a complicated 
special case added into a robust design is "optimal", I check that my wallet is 
still in my pocket.  Because "optimal" is a magic word often used to distract 
one's attention from what really matters.

So "multicast" considered harmful is my view.


On Tuesday, April 26, 2016 7:27pm, "Aaron Wood"  said:

> ___
> Make-wifi-fast mailing list
> make-wifi-f...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
> Has anyone modeled what the multicast to multiple-unicast efficiency
> threshold is?  The point where you go from it being more efficient to send
> multicast traffic to individual STAs instead of sending a monstrous (in
> time) multicast-rate packet?
> 
> 2, 5, 10 STAs?
> 
> The per-STA-queue work should make that relatively easy, by allowing the
> packet to be dumped into each STA's queue...
> 
> -Aaron
> 


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