I have been having some issues with packet loss on a point-to-point link so we replaced the RB532r5 board, replaced the radio cards, replaced power supplies, and numerous other things, then I found the nifty monitor-traffic command handy under 3.0rc13 since we were having the same problems under 2.9.50. After upgrading to 3.0rc13 the link came back up fine and I could ping across the link with no drops (Bridge->StationWDS), but the Ethernet side was still having problems.

So anyway, what does this really mean?

received-packets-per-second: 2052
receive-drops-per-second: 0
received-bits-per-second: 6.5Mbps
sent-packets-per-second: 1934
transmit-drops-per-second: 13
sent-bits-per-second: 8.8Mbps

received-packets-per-second: 1904
receive-drops-per-second: 0
received-bits-per-second: 5.8Mbps
sent-packets-per-second: 2049
transmit-drops-per-second: 8
sent-bits-per-second: 10.5Mbps

received-packets-per-second: 1862
receive-drops-per-second: 0
received-bits-per-second: 6.0Mbps
sent-packets-per-second: 1833
transmit-drops-per-second: 2
sent-bits-per-second: 8.8Mbps

This is after we have already replaced the ethernet cable, tried different ports on the bottom connecting device, and we even have another link to the same router at the bottom of the tower working with no packet loss (albeit with no traffic on it during testing usually -- it's a backup).

One last note, to reduce packet loss we have already disabled all interfaces that haven't been necessary to have active, disabled connection tracking, have no firewall rules, disabled all unused packages, are running with an 18V 1000mA power supply with about 60 feet (19 meters) of cable, and the primary radio card is a Ubiquiti XR5 with WDS enabled and attached to the same bridge as ether1.

I hope I have supplied enough information with this to make some sense out of what is happening. Please help!

One more thing to note is that I just tried turning on IP Packing on the routers on each end of the link and the packet count dropped by about 50%, as well causing total dropped packets on a ping test to drop significantly. The problem with this is that now the routers on both ends of the link (also RB532r5) are running 100% CPU load. So it appears to be a problem with passing more than X packets per second, with the key number being greater than 1000. If we are running less than 1000 packets per second, we don't have any drops, but when that gets into the thousands, especially over 2000 we have a significant number of drops.

We have seen packet loss issues in Beta 3 that have never been resolved. They have been as high as 6-7%. Stick with older versions of 2.9 where you can.

As far as wireless PPS, Mikrotik doesn't perform well at all. We've never seen more than a few thousand PPS.

I don't believe my problem is with wireless PPS. We are running NStreme on the link and that has cleared up the link itself. It's just the handoff on the remote end from the Mikrotik RB532 board with the wireless cards to the Mikrotik RB532 router. We're doing these as separate boards so that each system can focus on their overall task: whether routing or passing traffic.

The problem here I believe is something either with the Ethernet chipset's driver not working correctly, causing dropped packets, or something possibly wrong with the two boards and how they communicate with each other. Since two separate Ethernet cables were tested with the same results, I'm not believing it's the cable itself. Two different PoE injectors were used, and two different ethernet ports on both of the units were tested with the same results.

Hi Mate,

18V 1000mA power supply is too small for the XR cards IMHO

Try 2amp

I'm not here to argue, but it seems that based on XR specs if you are running a maximum of 2A (really 1.6A I believe) at 3.3v, that's only like 400mA @ 18V, with still plenty of power to run the board. It's just hard to find an 18V 2A power supply laying around. Especially when I have 20V 600mA power supplies on similar links with no troubles at all.

It sounds like queue type problem - each interface has default queue type usually PFIFO for 50 packets (even if you don't have any queues) - try to increase that number to 100.

Well this is certainly strange. Upon doing the upgrade to 3.0rc13 and looking at the CPU Usage graphs, the system was running at 100% CPU utilization. I did the downgrade to 2.9.50 and disabled all the unnecessary packages, and now we're running 99.995% throughput end-to-end on the link, greater than 2000 PPS each way with no problems. Also not seeing any packet loss on UDP bandwidth test, 44mbps one way, and CPU usage not exceeding 83%. For the most part the link is running less than 70% CPU utilization with the same settings as before. Also switched interface to turbo mode and while I didn't gain any additional throughput, there's still no more loss on it.

I thought 3.0 was supposed to have some added benefits for the RB100/RB500 boards to get better throughput.

i am having the exact issue over packet loss on the ethernet interface.

Do you happen to get it fixed?