What exactly is broken and can we avoid it in the mean time? Is this affecting throughput overall for the whole AP or just on an SM by SM basis? (Where it's just the max throughput of a single SM) (Eg., this wouldn't matter if the largest package any given SM was configured for was 25mbps?)
Also, is this brand new to 15.1.1?
What would be the ETA on a future release that fixes the issue?
It's still not clear on the exact problem here. Do the Ethernet ports on the "other" SM's need to be set to disabled, just "not linked", or does Ethernet port connection on the SM's not matter at all? Is this just saying that 450 SM's are just limited by a software bug to some maximum bits-per-second or packets-per-second?
More clarity on the problem would be useful for the rest of us please.
This issue happens in the UL only. Bandwidth allocation, in the UL, is optimized when there are 5 or fewer SM registerd to the AP. When 6 or more SMs are registered to the AP, every SM has to randomly wait between 1 to 7 frames, before requesting the bandwidth. This introduces a delay in the UL traffic. In madmax's case, he was seeing DL TCP throughput drop, because TCP Ack's in the UL were delayed. Ethernet port status does not matter, it only matters if the SM is registered to the AP or not.
Am I correct in assuming this severely impacts VOIP traffic?
I'm having complaints from customers using Skype for Business. Outgoing voice specifically. Try as I might, I haven't been able to track it down, but this looks like a huge problem.
Is VOIP part of any of the pre-release tests - Beta or otherwise?
We perform all our link tests with bridging and MIR enabled and don't offer any packages over 20 Mbps, so never noticed the bandwidth restrictions. Looks like this is the answer/problem with the multiple threads of slow/capped bandwidth despite correct results when performing the RF link tests.