Hi. I have a Client SM that's struggling to communicate to the AP, and I can't really log into the web GUI very well. I'm therefor trying to edit a radio setting remotely by downloading his setting (template) and editing that and then pushing that back to his radio.
What we're seeing is LOTS of uplink packet drops and low MCS on the uplink.
I KNOW THAT THE REAL SOLUTION IS A DRIVE TO HIS HOUSE AND TO REALLY FIX THE ISSUE, but I'm wanting to try editing his Uplink Max Rate, or any other settings to helpfully tweak this into working better until we can get there.
SO - in the template, I see both a 'wirelessInterfaceRateMaxMCS: 15' and I also see a ''wirelessRateMaxMCS: 15''. If I wanted to try moving that down to 10, which one would be the equivalent to teh GUI's Radio page ''Uplink Max Rate'' setting?
The MIB appears to say you should go with "wirelessInterfaceRateMaxMCS".
For "wirelessRateMaxMCS", there is a specific comment in the MIB that says "Not allowed for SNMP processing". I will check with the team for clarification on this and get back to you.
Also, have you tried setting the Management Rate to MCS0 on the AP to get a more reliable connection to this SM?
OK, after I posted this question, I thought of a way to test. What I did was this... I adjusted a different SM to Max MCS of 14, saved and rebooted - and then downloaded a 'template' from that one. In that downloaded Template both "wirelessInterfaceRateMaxMCS" and "wirelessRateMaxMCS" were both set to 14.
So (since I was unable to log into the GUI at all on this SM) I was able to download the 'template' and edit both of the MCS's to '10' and then re-upload the template via cnMaestro. The upload failed the first time, but when it succeeded on another try, and after it re-connected to the AP, I was then able to log into the SM no problem after that.
YES, this AP was already set to MCS0 for management, but this SM is likely in a noisy (self interfering) environment. Of course, I can't run a SA from the SM remotely, and eDetect doesn't show WiFi stuff that's interfering with the SM either - so this was my best guess for a way to get it back functional. We will still have to drive there to run a SA and find the interference, but this'll reduce the panic and buy us a couple days.
I should say... considering how well this one setting change seemed to have worked... does that mean that the normal algorithms the SM is using for picking it's MCS rate - are those too aggressive then?
I mean, there are still problems with this SM that need to be addressed, but it went from 'non-functional' to 'working pretty good' just by capping it's uplink rate at MCS10. That feels like it was unable to figure that out on it's own, and that it seems that it was trying too high a rate and failing, rather than falling back to a sustainable/workable MSC.
I should say... considering how well this one setting change seemed to have worked... does that mean that the normal algorithms the SM is using for picking it's MCS rate - are those too aggressive then?
I mean, there are still problems with this SM that need to be addressed, but it went from 'non-functional' to 'working pretty good' just by capping it's uplink rate at MCS10. That feels like it was unable to figure that out on it's own, and that it seems that it was trying too high a rate and failing, rather than falling back to a sustainable/workable MSC.
In ePMP, the rate adapt mechanism reacts to RF conditions by monitoring packet loss rather than predict based on channel conditions. Therefore at any given time, it is trying to always use a higher MCS when there is no or minimal packet loss in the current MCS. In widly varying conditions, it may not be able to settle on an MCS. I am not sure how far back you started using ePMP but during the 1.0 release days, the rate adapt was pretty raw and we receievd numerous complaints on performance. We spent months in tweaking and tuning it and finally came about with an slightly aggressive system which seems to satisfy a lot of deployments around the world. We found that biasing to a slightly aggressive rate adapt coupled with finely tuned retry machnism resulted in over all higher sector throughput than being conservative. This was 2.0 and was a big leap in performance for our customers.
What you have done is put an artificial cap on how far ePMP's rate adapt can "try" to step up in MCS and it has artifically "settled" on a good MCS for this condition. This is exactly the reason why we gave control to customers to cap the MCS. If not throughput or connetivity, some customers prefer to cap MCS for latency as packet loss leads to higher latency. This is expected behavior and rate adapt tweaking and tuning can be an endless exercise when it is reactive. We did have plans to add a mechanism to predict RF conditions based on EVM and other parameters but that does not exist today. Hopefully down the line, we'll get that in there.