Hello Linux Wireless hackers,
I've taken up an hacking endeavour in trying to improve multicast on
wifi, specifically to get it off the stupid 1 MBit rate. Before anyone
yells "that's not allowed by the spec" - it actually is, please refer to
section 9.7.5 of 802.11-2012. ("... using one of the rates included in
the BSSBasicRateSet parameter ...") Also, Cisco and Aruba are doing
this in their enterprise APs, and it's rather nice.
So, from some completely unrelated datacenter work, I have hacked up the
bridge to hand back down to the driver detailed info on multicast
receivers. Then I took this and fudged around in the minstrel_ht code
and, well, it gave me 9 MBit/s ;)
Now, I have pretty little no clue about the Linux wireless stack, so I'd
appreciate if someone could tell me how massively wrong I'm doing this
and which places in particular are the wrongest!
You can find the code here:
https://github.com/eqvinox/vpls-linux-kernel/commits/mdb-hack
https://github.com/eqvinox/vpls-iproute2/tree/mdb-hack
Please note that all of this is proof-of-concept level, it probably
leaks tons of memory, has great race conditions and eats your cat for
breakfast. It also contains some debug printks like this:
[ 9006.253504] mac80211_hwsim hwsim0 wlan0: multi-dst TX: 02:00:00:00:02:00 02:00:00:00:01:00
[ 9006.255007] mac80211_hwsim hwsim0 wlan0: rc 02:00:00:00:02:00 => rate #1
[ 9006.256095] mac80211_hwsim hwsim0 wlan0: rc 02:00:00:00:01:00 => rate #12
[ 9006.257186] mac80211_hwsim hwsim0 wlan0: result rate #1
Cheers,
-David
P.S.: yes, I know about unicast conversion. But that's not helpful
when, for example, you want to get a 10 MBit multicast TV livestream to
5 simultaneous wifi clients...
On 08/18/2017 03:29 PM, David Lamparter wrote:
> Hello Linux Wireless hackers,
>
>
> I've taken up an hacking endeavour in trying to improve multicast on
> wifi, specifically to get it off the stupid 1 MBit rate. Before anyone
> yells "that's not allowed by the spec" - it actually is, please refer to
> section 9.7.5 of 802.11-2012. ("... using one of the rates included in
> the BSSBasicRateSet parameter ...") Also, Cisco and Aruba are doing
> this in their enterprise APs, and it's rather nice.
For ath10k, at least, rate-ctrl is controlled in the firmware.
But, the driver can set the multicast rate to a fixed value.
I am pretty sure this works on stock firmware, maybe with some driver
tweaks. It definitely works on my ath10k-ct driver/firmware (tested on
the wave-1 stuff, not sure anyone has tested on the wave-2 stuff yet).
My api is through the ath10k debugfs API, so a kludge at best, but it could
be wired into a better API with some work.
I'll read through your stuff when I get a chance.
Thanks,
Ben
>
> So, from some completely unrelated datacenter work, I have hacked up the
> bridge to hand back down to the driver detailed info on multicast
> receivers. Then I took this and fudged around in the minstrel_ht code
> and, well, it gave me 9 MBit/s ;)
>
> Now, I have pretty little no clue about the Linux wireless stack, so I'd
> appreciate if someone could tell me how massively wrong I'm doing this
> and which places in particular are the wrongest!
>
> You can find the code here:
> https://github.com/eqvinox/vpls-linux-kernel/commits/mdb-hack
> https://github.com/eqvinox/vpls-iproute2/tree/mdb-hack
>
> Please note that all of this is proof-of-concept level, it probably
> leaks tons of memory, has great race conditions and eats your cat for
> breakfast. It also contains some debug printks like this:
> [ 9006.253504] mac80211_hwsim hwsim0 wlan0: multi-dst TX: 02:00:00:00:02:00 02:00:00:00:01:00
> [ 9006.255007] mac80211_hwsim hwsim0 wlan0: rc 02:00:00:00:02:00 => rate #1
> [ 9006.256095] mac80211_hwsim hwsim0 wlan0: rc 02:00:00:00:01:00 => rate #12
> [ 9006.257186] mac80211_hwsim hwsim0 wlan0: result rate #1
>
>
> Cheers,
>
> -David
>
>
> P.S.: yes, I know about unicast conversion. But that's not helpful
> when, for example, you want to get a 10 MBit multicast TV livestream to
> 5 simultaneous wifi clients...
>
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
Il giorno sab, 19/08/2017 alle 00.29 +0200, David Lamparter ha scritto:
> Hello Linux Wireless hackers,
>
>
> I've taken up an hacking endeavour in trying to improve multicast on
> wifi, specifically to get it off the stupid 1 MBit rate. Before
> anyone
> yells "that's not allowed by the spec" - it actually is, please refer
> to
> section 9.7.5 of 802.11-2012. ("... using one of the rates included
> in
> the BSSBasicRateSet parameter ...") Also, Cisco and Aruba are doing
> this in their enterprise APs, and it's rather nice.
>
> So, from some completely unrelated datacenter work, I have hacked up
> the
> bridge to hand back down to the driver detailed info on multicast
> receivers. Then I took this and fudged around in the minstrel_ht
> code
> and, well, it gave me 9 MBit/s ;)
>
> Now, I have pretty little no clue about the Linux wireless stack, so
> I'd
> appreciate if someone could tell me how massively wrong I'm doing
> this
> and which places in particular are the wrongest!
>
> You can find the code here:
> https://github.com/eqvinox/vpls-linux-kernel/commits/mdb-hack
> https://github.com/eqvinox/vpls-iproute2/tree/mdb-hack
>
> Please note that all of this is proof-of-concept level, it probably
> leaks tons of memory, has great race conditions and eats your cat for
> breakfast. It also contains some debug printks like this:
> [ 9006.253504] mac80211_hwsim hwsim0 wlan0: multi-dst TX:
> 02:00:00:00:02:00 02:00:00:00:01:00
> [ 9006.255007] mac80211_hwsim hwsim0 wlan0: rc 02:00:00:00:02:00 =>
> rate #1
> [ 9006.256095] mac80211_hwsim hwsim0 wlan0: rc 02:00:00:00:01:00 =>
> rate #12
> [ 9006.257186] mac80211_hwsim hwsim0 wlan0: result rate #1
>
>
> Cheers,
>
> -David
>
>
> P.S.: yes, I know about unicast conversion. But that's not helpful
> when, for example, you want to get a 10 MBit multicast TV livestream
> to
> 5 simultaneous wifi clients...
So you are scanning the multicast receivers list to select the lowest
rate, comparing the rates by data rate?
I think that this is incorrect, the data rate is a combination of many
parameters (modulation, GI interval, coding rate, streams, etc.) so a
rate with higher data rate could be better than another with lower
speed in some circumstances. Or even worse, some station could not
receive the packet at all (too many streams, unsupported modulations.
etc.).
You could try to select the lowest MCS rate, the longer GI and the
minimum number of stream from all the receivers and use a data rate
compatible with these settings, if any (not all combinations are
allowed unfortunately)
Ciao,
--
Matteo Croce
per aspera ad upstream
On Sat, Aug 19, 2017 at 12:58:11AM +0200, Matteo Croce wrote:
> Il giorno sab, 19/08/2017 alle 00.29 +0200, David Lamparter ha scritto:
> > So, from some completely unrelated datacenter work, I have hacked up
> > the bridge to hand back down to the driver detailed info on
> > multicast receivers. Then I took this and fudged around in the
> > minstrel_ht code and, well, it gave me 9 MBit/s ;)
> >
> > Now, I have pretty little no clue about the Linux wireless stack, so
> > I'd appreciate if someone could tell me how massively wrong I'm
> > doing this and which places in particular are the wrongest!
[cut]
> So you are scanning the multicast receivers list to select the lowest
> rate, comparing the rates by data rate?
Right now it's just using the lowest rate index. I did say I have no
clue, right? :)
> I think that this is incorrect, the data rate is a combination of many
> parameters (modulation, GI interval, coding rate, streams, etc.) so a
> rate with higher data rate could be better than another with lower
> speed in some circumstances. Or even worse, some station could not
> receive the packet at all (too many streams, unsupported modulations.
> etc.).
>
> You could try to select the lowest MCS rate, the longer GI and the
> minimum number of stream from all the receivers and use a data rate
> compatible with these settings, if any (not all combinations are
> allowed unfortunately)
Yes, basically I need to find the best rate in the common subset
supported by all receivers. This is far from trivial and will have
'interesting' interactions (for example, if a station only does
multicast, minstrel has nothing to learn the rate on because multicast
isn't ACKed so you can't probe with it). That said, my goal here is
"simple", not "perfect". There's always room and time for
improvement...
-David
On Fri, Aug 18, 2017 at 03:49:39PM -0700, Ben Greear wrote:
> On 08/18/2017 03:29 PM, David Lamparter wrote:
> > I've taken up an hacking endeavour in trying to improve multicast on
> > wifi, specifically to get it off the stupid 1 MBit rate. Before anyone
> > yells "that's not allowed by the spec" - it actually is, please refer to
> > section 9.7.5 of 802.11-2012. ("... using one of the rates included in
> > the BSSBasicRateSet parameter ...") Also, Cisco and Aruba are doing
> > this in their enterprise APs, and it's rather nice.
>
> For ath10k, at least, rate-ctrl is controlled in the firmware.
> But, the driver can set the multicast rate to a fixed value.
Yeah, I've hacked this straight in minstrel_ht, so it's only gonna work
on mac80211 drivers.
The information about which STAs are joined to a multicast group is
available to all drivers though, so, if a hardmac driver has sufficient
information on STA rates, it could still dynamically pick a multicast
rate on a per-packet level and tell that to the MAC.
> I am pretty sure this works on stock firmware, maybe with some driver
> tweaks. It definitely works on my ath10k-ct driver/firmware (tested on
> the wave-1 stuff, not sure anyone has tested on the wave-2 stuff yet).
>
> My api is through the ath10k debugfs API, so a kludge at best, but it could
> be wired into a better API with some work.
I actually need to try the CT stuff, particularly the TX rate reporting
-- wonder how useful the information is (cf. above). Unfortunately the
only ath10k I have is in my plastic router... a bit annoying to hack
around on.
> I'll read through your stuff when I get a chance.
Thanks in advance, all input appreciated!
-David