Hi, I need help interpreting the results for multicast throughput tests.
I’m using all Halowlink1s and I have an AP and 2 STAs. The AP has IP address 192.168.69.1, and the STAs are on 192.168.69.28 and ….195.
AP iperf command to send multicast traffic is iperf -c 239.1.1.1 -u -B 192.168.69.1 -b 35M -t 20 -i 1 -
T 32
Each STA runs iperf -s -u -B 239.1.1.1 -i .
Noticing the throughput for each STA is 10mbps each instead of 20mbps. I have an o-scope connected to RF detectors which are coupled to the output of each STA. From there I can see that each STA is alternating transmitting ACKS for each frame sent over the medium. I was under the impression that multicast frames should not be ACKed. In addition, I thought that multicast packets are sent at the lowest MCS rate. I’m seeing instead that our packets are sent at MCS7 (verified in wireshark) and I can lower the rate by fixing the MCS.
Enabling mcast_rate_control does nothing to modify the throughput of the frames. (I have followed the fixes for adding mcast_rate_control to the MODBOOL parameter list, and also disabled the whitelist)
I’ve also attached a wireshark capture using another morse configured as a sniffer during these tests. Looks to me that the AP is performing multicast-to-unicast conversion. Is there a way to disable that? (If that is the case here). Please let me know if I’m interpreting anything incorrectly.
When an AP is doing multicast to unicast conversion, the frames are indeed unicast frames and therefore are sent like any other unicast data frame (including expecting an ACK) which includes sending at the current unicast data rate and airtime contention. Only when you are not doing the multicast to unicast conversion are frames sent unacknowledged but also at the lowest basic data rate.
It appears as you’ve discovered that the default behavior in your current firmware version or HL1 config is multicast to unicast conversion. I do not know if it is possible to change this behavior, but I bet it is possible.
If been digging up some of our multicast test reports, and it looks like you’re probably at the most optimal performance at this stage. You’re measuring higher throughput for multicast than we’ve ever tested.
When mcast_rate_control is used the AP will look for the lowest supported MCS by all connected stations and transmit multicast traffic at that rate. Without this modparam, multicast will transmit at MCS0.
The traffic you’ve captured, and those spikes, is all definitely unicast. Out of the box, we don’t do multicast to unicast conversion, and running your setup as you have described my APs + STAs are not functioning in the same way, I am seeing only multicast transmissions from the AP (and substantially less throughput).
The only way I can see that we’ve enabled multicast to unicast is in mesh modes with BATMAN.
