Expected latency to SM in TDD/Sync Mode

I have been noticing that latency to some SM's is sporadically high   

This particular SM is registered with an RSSI of -62 (MCS 15/MCS 13) and is 2.7mi from the AP.

The AP has 20 clients, and is very lightly loaded at the moment.  It's reporting a 30-40% downlink frame utilization.  

Pinging from the site, latency looks like:

$ ping 10.13.3.51
PING 10.13.3.51 (10.13.3.51) 56(84) bytes of data.
64 bytes from 10.13.3.51: icmp_seq=1 ttl=62 time=36.0 ms
64 bytes from 10.13.3.51: icmp_seq=2 ttl=62 time=76.3 ms
64 bytes from 10.13.3.51: icmp_seq=3 ttl=62 time=36.2 ms
64 bytes from 10.13.3.51: icmp_seq=4 ttl=62 time=33.2 ms
64 bytes from 10.13.3.51: icmp_seq=5 ttl=62 time=70.0 ms
64 bytes from 10.13.3.51: icmp_seq=6 ttl=62 time=152 ms
64 bytes from 10.13.3.51: icmp_seq=7 ttl=62 time=27.3 ms
64 bytes from 10.13.3.51: icmp_seq=8 ttl=62 time=61.3 ms
64 bytes from 10.13.3.51: icmp_seq=9 ttl=62 time=22.1 ms
64 bytes from 10.13.3.51: icmp_seq=10 ttl=62 time=69.1 ms
64 bytes from 10.13.3.51: icmp_seq=11 ttl=62 time=42.9 ms
64 bytes from 10.13.3.51: icmp_seq=12 ttl=62 time=134 ms
64 bytes from 10.13.3.51: icmp_seq=13 ttl=62 time=24.9 ms
64 bytes from 10.13.3.51: icmp_seq=14 ttl=62 time=79.3 ms
64 bytes from 10.13.3.51: icmp_seq=15 ttl=62 time=31.7 ms
64 bytes from 10.13.3.51: icmp_seq=16 ttl=62 time=87.6 ms
64 bytes from 10.13.3.51: icmp_seq=17 ttl=62 time=29.5 ms
64 bytes from 10.13.3.51: icmp_seq=18 ttl=62 time=67.8 ms
^C
--- 10.13.3.51 ping statistics ---
18 packets transmitted, 18 received, 0% packet loss, time 17023ms
rtt min/avg/max/mdev = 22.139/60.166/152.035/35.996 ms

Does this seem high?  Latency to all other clients on this paritulcar AP is similar.  I'm seeing ~15-20ms average latency on other ePMP AP's on my network (even ones with more clients and higher utilization).

Josh, 

Can you post a screen shot of the MCS distribution on this SM (under Monitor->Performance)? I'm wondering if this SM is marginal on a particular MCS and hence there are retransmissions leading to inconsistent latency. For example, if you see that this SM is doing 10% MCS15, 20% MCS14 and 70% MCS13, I would lock the Max Rate on the UL to MCS13 so it doesn't keep trying MCS14 and MCS15. Just a thought. 

Thanks,

Sriram

1 Like

Sure, screenshot is attached:

What should we expect in terms of latency to each SM?

Maybe you can try setting the Max Uplink Rate on this SM (under Configuration->Radio) to MCS13. The expected latency to each SM can be predicted using the ePMP Capacity Planner. Please input the SMs and their parameters specific to this deployment and the ePMP Capacity Planner will provide you a prediction. 

Thanks,
Sriram

1 Like

Thanks - I'll play with the capacity planning tool.

I have noticed that whlie nearly all of the conncted SM's on this AP are MCS13-15 on the downlink, there are lots of uplinks in the MCS1-9 range.  Does this typically mean there is some interference at the SM?  Perhaps we should try a new frequency?  

Could these poor uplink's on several of the SM's be dragging down the entire AP thus causing high/sporadic latency to SM's?

1 Like

Hi Josh, 

If the Uplink MCS is low, then the interference is at the AP. Especially if you see a lot of the SM's showing poor Uplink, you will have to run a spectrum analyser scan at the AP to see how bad the interferer is at the AP. Interference in Uplink or Dowlink or Both can cause lost packets resulting in retransmissions and higher latency. 

If some SMs or specfiic set of SM's have poor MCS on uplink or downlink, it will not affect the rest of the SMs. That is the "Air Fairness" TDD scheduler in ePMP where one SMs poor performance does not penalize other SMs that are in good RF conditions. That said, in your case, it appears that there is interference at the AP, so it may be impacting uplink for most if not all the SMs. It would be important to resolve that first, if possible. 

Thanks,

Sriram

2 Likes

Hi Sriam,

I was able to move the AP to a cleaner frequency, and the uplink MCS's for each SM has gotten much better. During low traffic periods, latency to nearly all of the SM's was in the 22-30ms range.  In the evening, when the AP gets busier, I am still seeing some sporradically high latency:

64 bytes from 10.13.3.51: icmp_seq=163 ttl=62 time=47.0 ms
64 bytes from 10.13.3.51: icmp_seq=164 ttl=62 time=23.6 ms
64 bytes from 10.13.3.51: icmp_seq=165 ttl=62 time=73.8 ms
64 bytes from 10.13.3.51: icmp_seq=166 ttl=62 time=42.1 ms
64 bytes from 10.13.3.51: icmp_seq=167 ttl=62 time=26.0 ms
64 bytes from 10.13.3.51: icmp_seq=168 ttl=62 time=29.7 ms
64 bytes from 10.13.3.51: icmp_seq=169 ttl=62 time=33.9 ms
64 bytes from 10.13.3.51: icmp_seq=170 ttl=62 time=109 ms

This particular SM is reading MCS15/MCS13.  We are experiencing this on nearly every SM connected to this AP. (some worse than others)  My next step is to try setting the Max Uplink on this pariicular radio, but I really don't want to have to do this with every SM on this AP.  

Do you have any other ideas?

1 Like

@JoshB wrote:

Hi Sriam,

I was able to move the AP to a cleaner frequency, and the uplink MCS's for each SM has gotten much better. During low traffic periods, latency to nearly all of the SM's was in the 22-30ms range.  In the evening, when the AP gets busier, I am still seeing some sporradically high latency:

64 bytes from 10.13.3.51: icmp_seq=163 ttl=62 time=47.0 ms
64 bytes from 10.13.3.51: icmp_seq=164 ttl=62 time=23.6 ms
64 bytes from 10.13.3.51: icmp_seq=165 ttl=62 time=73.8 ms
64 bytes from 10.13.3.51: icmp_seq=166 ttl=62 time=42.1 ms
64 bytes from 10.13.3.51: icmp_seq=167 ttl=62 time=26.0 ms
64 bytes from 10.13.3.51: icmp_seq=168 ttl=62 time=29.7 ms
64 bytes from 10.13.3.51: icmp_seq=169 ttl=62 time=33.9 ms
64 bytes from 10.13.3.51: icmp_seq=170 ttl=62 time=109 ms

This particular SM is reading MCS15/MCS13.  We are experiencing this on nearly every SM connected to this AP. (some worse than others)  My next step is to try setting the Max Uplink on this pariicular radio, but I really don't want to have to do this with every SM on this AP.  

Do you have any other ideas?

those few high ping times are most likely retransmissions.   check your performance screen in the AP and SM and look at your retransmission counts, you may find restricting the MCS to 12 from 13 to clear that.    is this service impacting or just something you've noticed?   we've got APs in noisy areas that do that, but its due to higher than average retransmittion for us. retransmitted pings are normally 2 to 3 times your average RTT time. 
If the AP has a high retrasmission count to the CPE, the CPE end is experincing the noise. a more focused CPE may help. 
2 Likes

JoshB wrote: My next step is to try setting the Max Uplink on this pariicular radio, but I really don't want to have to do this with every SM on this AP.  

This might not help you Josh in this particaular situation - but as a feature suggestion...

One of the other brands that we're used in the past has a 'Rate Algorithm Aggressiveness' setting. That way, it was still automatic and would still adjust up and down with varying conditions, but you could tell it +1 or -2 or whatever plus/minus you wanted to set, and then that radio would step up or down the MCS rates by that amount.

So, a -2 setting is similar to capping it at 13 in some ways - but if a client has poor RF conditions, and especially if those conditions change over time - we found that the 'aggressiveness' setting was a great feature.  When the conditions were OK, and where the normal algorithm would normally pick a 15, a radio set at -2 would pick at 13 (similar to capped at 13).  But if the real world conditions dropped for that site so that the radio would normally pick a 14 or 13, the capped at 13 feature will still try it's cap of 13, which may not really work.  But with a -2 aggressiveness, it'll calculate that it probably should use 14 or 13, and it'll instead go -2 to 12 or 11.

Also - there would be places that at times needed to be a much lower rate (let's say an MCS 9) but at other times, it could support a MCS12.  If we manually cap it at 9, and the situation improves (clear, dry day with no leaves) then the radio is capped at 9 and wasting potentila.  However, if we can set it at a -3, then it'll be able to step up to 12 max, and yet it'll still drop back to 9 in a situation where it might normally pick a 12 and then have retransmissions.

So - we found this to be a great feature - we didn't have to be too cautious when manually limiting a radio, and we didn't have to waste potential if the RF situation improved and the radio wanted to step up a bit.

1 Like