Yeah, sorry, completely misunderstood that article - the intent in that article appears to be from getting multicast traffic to get to the wireless interface completely.

Having said that, would IGMP's contribution to latency over and above what latency 802.11 itself introduces be statisticslly significant?

I'm quite curious about what's involved in "fixing" this, but unfortunately still don't have any real way of doing suitable tests in my home lab.

my testing seems to be showing that 802.11n seems to be allowing a rate set at 54Mb/s.. but multicast packets are still going ONLY at 6Mb/s.. even when we've set basic and supported rates at say, 54Mb/s.. Wireshark is showing these broadcast at 6Mb/s 'in the air'..

this same issue exists in ath10k and on Designated Driver as well..

is there a way to set an MCS rate on 802.11ac for all packet transport (or specifically for multicast)?

wifinix - just checking... some wireless adapters do not fully support sniffing wireless traffic.  I know that both my Ralink adapters report *all* traffic to be at 5.5 Mbps.  You're confident that the traffic is actually flowing at 6 Mbps?

I'm also slightly confused: if I understand things correctly, multicast optimisation should be converting your multicast traffic into unicast traffic that's sent to individual stations at the MCS rate that provides the best throughput.  Does your statement mean you were eventually successful in disabling multicast optimisation?

I would also take care not to set the lowest basic_rate too high; doing so might cause more problems than it solves.  The mcast_rate setting should (theoretically) allow you to set a higher multicast rate.

I don't know of a way to adjust supported HT (High Throughput) rates on 802.11ac (or 802.11n for that matter.)  Beacons will always be transmitted at the lowest supported basic rate. I stand to be corrected, but I anticipate that multicast traffic won't sent be with HT rates.  It would default to the lowest basic_rate set at driver level, but it should be possible to override that with mcast_rate at the SSID level.

thx for the thoughts..

1. have been monitoring with WireShark, and confirm that it's going at 6Mbit/s in 802.11n/ac. Am wanting it up at 48 or 54Mbit/s or better.

2. i simply need to be able to control it - if it's too fast than i'll bring it back down - the real issue is that I can't seem to have ANY control over the multicast rate.

3. My theory was that I could trick it into assuming that a higher rate is the 'lowest basic_rate', but my experience is that the beacon (and multicast) do not follow this instruction (adding this in /etc/config/wireless:   option basic_rate '54000'  )

4. yes i can disable multicast-to-unicast.. but as soon as it is disabled, all packets go at lowest rate (6Mbit/s or 1Mbit/s).

I do **NOT** want mc-uc conversion-this is not a viable option for my application.

thoughts?

thx

(Last edited by wifinix on 31 Jan 2017, 23:12)

Pretty sure basic_rate works on ath9k in the 2.4 Ghz band... see the screengrabs of the spectrum analysis I did at the start of this thread.

Note that I've only tested on ath9k; the settings might or might not work on other radios.  ath9k is 802.11n-only, so if you're 802.11ac capable I'm pretty sure at least your 5 Ghz radio is something else.  (Also keep in mind that with 5 Ghz, the default - and lowest possible - basic rate is 6 Mbps.  in 2.4 Ghz, it's 1 Mbps.)

See the following for examples of others' experience with ath10k, where they seemingly encountered problems too:
* https://forum.openwrt.org/viewtopic.php?id=58106
* http://lists.shmoo.com/pipermail/hostap … 32250.html

This article is great to me, as I am not familiar with mac80211 driver, I think I can learn a more little with this article and make use of your test result. Thank you.