Curious what others are seeing for packet loss on the SM and AP side? I took a look at cnMaestro graphs today and was surprised by the packet loss graphs. I am seeing packet loss in the 10's of thousands on some SMs and in the thousands for all of them.
On this particular SM, I have a RSSI of -60 and a SNR of 30. RF environment is pretty good. eDetect does not reveal any bad interference. But, I'm seeing pockets of huge packet loss:
Here is the AP during that same period:
Concerning?
I have an SM with a peak of 404,084 packet loss this week. According to our internal graphs we don't have any problems and there are several customers behind it. I'm very confident these customers would be calling if there was anything like 4% or 40% packet loss.
@Au Wireless wrote:
Curious what others are seeing for packet loss on the SM and AP side? I took a look at cnMaestro graphs today and was surprised by the packet loss graphs. I am seeing packet loss in the 10's of thousands on some SMs and in the thousands for all of them.
On this particular SM, I have a RSSI of -60 and a SNR of 30. RF environment is pretty good. eDetect does not reveal any bad interference. But, I'm seeing pockets of huge packet loss:
Here is the AP during that same period:
Concerning?
Chad,
I am checking out what exactly we are plotting on CnMaestro in terms of packet loss. As Josh said, this wouldn't make any sense. You would have disasterous TCP performance with that hiigh of a packet loss.
Sakid
Thanks for highlighting this. We will look into this issue.
Hello everyone...
Was there any feedback or determination on what this could be?
Mine isn't near that bad but I am seeing some spikes in my packet loss graphs over the past week.
I have a customer that has a VPN connection that keeps dropping and after doing some research it seems to be the backhaul between 2 locations. Connections look good, but the packet loss seems pretty consistent.
Every . is a drop.
Sending 1000, 1024-byte ICMP Echos to x.x.x.x, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!
Success rate is 99 percent (994/1000), round-trip min/avg/max = 16/35/240 ms
My current link is 2 miles, RSSI -67 SNR 28db Uplink/Downlink MCS 14 running at 20mhz utilizing force 110's in TDD mode.
Thoughts?
Thanks,
Ryo
After doing some further checking this link just seems to be dropping packets all the time.
So I started checking some of our other backhauls and found the following.
Everything 2.6.1 also
This is the one that is the current issue.
| Total Traffic | 96603537 Kbits |
| Total Packets | 41944889 |
| Error Drop Packets | 42762 |
| Multicast / Broadcast Traffic | 909136 Kbit |
| Broadcast Packets | 1072159 |
| Multicast Packets | 765697 |
| Total Traffic | 281868307 Kbits |
| Total Packets | 48413200 |
| Error Drop Packets | 3703 |
| Capacity Drop Packets | 31 |
| Retransmission Packets | 1625591 |
| Multicast / Broadcast Traffic | 164789 Kbits |
| Broadcast Packets | 22912 |
| Multicast Packets | 183495 |
| Link Quality (Uplink) | 100 % |
| Link Capacity (Uplink) | 90 % |
This link is pretty solid as well and has dropped alot less over a whole lot more data.
| Total Traffic | 3025185902 Kbits |
| Total Packets | 2107660151 |
| Error Drop Packets | 5 |
| Multicast / Broadcast Traffic | 116536 Kbit |
| Broadcast Packets | 23 |
| Multicast Packets | 176469 |
| Total Traffic | 32765604926 Kbits |
| Total Packets | 3606494212 |
| Error Drop Packets | 4382 |
| Capacity Drop Packets | 1671 |
| Retransmission Packets | 245503990 |
| Multicast / Broadcast Traffic | 114968 Kbits |
| Broadcast Packets | 194 |
| Multicast Packets | 159692 |
| Link Quality (Uplink) | 90 % |
| Link Capacity (Uplink) | 100 % |
go to your performance screen and look at your MCS steps and your %% on those.
if your page looks something like this, with the numbers spread around, limiting your max modulations can stop the errors your getting. its likely that link is getting intermittent noise, and its delayed enough the MAC layer is jumping your modulations up unti it hits again. this graph for example, i would leave the download alone, the success rate is awesome. but the upload isn't as good. i would block that at MCS13. this will cut off some of your top out bandwidth, but will clean out retransmissions, which will reduce the chances of a pause frame hitting yout switches when that link is getting saturated, it will clean up your error rates and likely resolve your customers problem. I try to pick the most commonly success modulation to block it to. in this examples case, its MCS13 at 46%. the chances of a retransmission or drop at 14 and 15 are more likely.
you can take the improve the link budget path as well and use higher gain dishes to narrow your path, and improve your link budgets.
in your case, your downlink has 245 million retransmission packets, of 3.6 billion, almost 7%, which isn't bad, but if your getting saturated, your switches could be pausing and compounding this issue for the VPN user. VPNs are nice and touchy. cleaning out the retransmitted packets can clean that up, and overall link experience will improve.
expanding this link to 40mhz wide channel, and limiting your MCS to achieve under a 1% retransmission rate would likely clean out your issue. and get you more bandwidth.
a few other things to check, your ethernet links in your switch
Good morning, I have a similar retransmission problem. As seen in the image in the download 52% of the time uses BPSK. How can I solve it?
Hi,
Broadcast traffic is running on MCS0/1.
I guess in your case that the reason of the high percentage of packets transmitted/received on MCS0/1.
And Unicast is running on MCS15 mostly in DL and on MCS13 in UL.
Thank you.
You can see this on a link which is mostly idle - with not a lot of active traffic going across it. Is that the case with this link? Usually if you pump some data across it (zero the counters, do a few 20 second link tests) and see what th percentages look like then.
