Does anyone have real-world test results that would demonstrate a 450i AP running at least 24.2.2 that had been tested with the same set of CPE units with both 20 Mhz, 30 Mhz, and 40 Mhz channel sizes, and was or was not outperformed by a 450v AP also testing the same 20 Mhz, 30 Mhz, and 40 Mhz channel sizes with as close to the same antenna specs? My experience with all tests I have done so far with 450 and 450i APs and larger than 20 Mhz channel sizes has been subpar. Same question with a 450i AP upgraded along with appropriate CPE units all upgraded to the latest 25.x.x firmware release, restated as documented clear improvements with larger than 20 Mhz channel sizes.
From what we’ve experienced using firmware that supports the deep vc queue optimizations added in R24.2, all newer SM’s (450i, b, v) has shown the exact same improvement in performance when using larger 20MHz+ channel widths. Only original 450 AP’s and SM’s don’t see the same improvements due to lack of processing power.
EDITED - I am not seeing those results with 450i APs and have not tested 450v APs. I am not sure it you meant you had tested larger channel sizes both with 450i APs and 450v APs using 5 Ghz or perhaps just 450v APs or something else at this point. I can run some more tests but I continue to observe patterns such as 8x/8x & close to 100% LQ Downlink & Uplink Quality Index and Beacon Map Quality Index with 20 Mhz channels but when I switch to 30 Mhz or 40 Mhz those drop so drastically that the 20 Mhz channel size outperforms or performs the same. This has been with multiple tests often for lack of a better word out in the middle of nowhere but almost exhibiting symptoms of targeted interference in the middle of the 30 Mhz or 40 Mhz channel sizes. I spend a lot of time working directly with Cambium a while back on what I observed and what I tried and working through their suggestions and did not get a good answer other than “we know what it might be” but no information even on what they think it might be. My assumption has been something unique is happening such as targeted interference as everything I have read and looked into suggests it should be working better when I try 30 Mhz and 40 Mhz channels even in the middle of nowhere but that has not been the situation. If I were to do two installs at 20 Mhz using the guard bands I typically use I could get twice the performance it I bond the units myself but as soon as I try to take advantage of what ought to work it does not work. Any ideas for some testing I could try that Cambium might not have already suggested? Also, are there settings on the AP and or CPE that must be checked to turn on the “deep VC queue” such as Configuration-Radio-Large Data Channel data Q or is that a separate issue? - EDITED
We have 450i, 450v (or at least we did for awhile for testing), and 450m AP’s with 450, 450b, and 450i SM’s and all of them perform as expected when moving up/down channel widths. We’re running 25.0.1 on everything. We use 5ms frames and typically a 75/25, or 80/20 duty cycle. We use auto contention on all 450i AP’s, and typically 10+ slots on 450m. Max distance is typically set to be 1-2 miles past the farthest SM. We use sync on all of our PMP450 AP’s. We don’t use guard bands.
Increasing channel width typically results in about 3dBm less signal per step, and while this can result in modulation going down one step if it’s on the edge, it wouldn’t typically result in performance that is less then a smaller channel width. The only way that I think that such a large reduction in throughput could occur is if there was some sort of interference that was being introduce on either edge of the channel.
I’m assuming that you’ve run SA’s on both the AP and SM’s in question?
As to the deep vc queue, as of firmware R25.0.1, it is enabled automatically on both AP and SM.
There are a few small differences such as 85/15 duty cycle and only 6 contention slots without any 450m units but I don’t see how that should be a problem. I have been testing with 5 Mhz guard bands thus far also without Adjacent Channel Support enabled. I have run SA on both the AP and SM’s in question. It seems to exhibit similar patterns I have observed in the past even with 20 Mhz channels where it seems the interference isn’t necessarily detected on either end but perhaps a path is running perpendicular causing interference. This has been something with multiple APs I have been able to work around and also has seemed to go away with less users perhaps trying to use 5 Ghz for back haul. I can look at trying R25.0.1 again but based on my own observations and potential interference on either edge of the channel though SA doesn’t detect that if it could be perpendicular and not necessarily observed or if the timing of when SA reads lines up with time slicing algorithms where interference could be turned on and off quickly such that normal Cambium SA might not detect it as another theory. Right now what I observe just doesn’t seem to fit normal patterns others seem to have. I had tried 2.5 ms frames per Cambium suggestion but found it had the same problem as 5 ms so I am currently back to 5 ms frames also. One of the symptoms I have observed with both unlicensed and licensed radios with perpendicular interference is when a spotting scope or other more exact means indicates where an antenna should be aimed but it doesn’t perform as well but does so slightly skewed on tilt or azimuth or both then close to perpendicular to the path somewhere not easily detected by SA I have used interference seems highly likely.
Also, while I was working with Cambium it was suggested that while the deep VC queue issue would help with these larger channel sizes especially when APs have a lot more users on them then I was working with them on at least at the time it was suggested that I should be getting better performance with 30 Mhz and 40 Mhz channel sizes with the relatively few units I was connecting to APs compared I assume to many others. Since then I have run more tests with deep VC queue support out of beta but still have the same problems with every test I have run thus far.