I have an epmp4500L that just resulted in terrible performance for clients. TCP btests back to tower ~30Mbps on a 40MHz channel. UDP tests varying between ~50 → 100Mbps. 800 byte/10s link tests ~180 / 30Mbps. Massive latency spikes too. The AP log file wasn’t showing clients disconnecting either.
I tried different channels etc but no joy. A scheduled revert back to 5.10 on the AP during the wee small hours this morning appears to have resolved the issue. TCP tests from customer router back to SamKnows showing ~150Mbps this morning with the tower loaded up.
Smokeping latency to connected clients looks much healthier.
I’m not seeing similar on any of our ePMP3000 or ePMP4500 radios. Just the epmp4500L
I did download support files from the AP and one of the connected F4525 clients prior to the firmware downgrade. Unfortunately I don’t have any other ePMP4500l radios on my network with connected clients to further test with.
I will really appreciate if you can test it on the latest beta 5.12.0-RC36.
There is a solid improvement for large sectors under load, already confirmed by beta testing community.
We are seeing what looks like the same issue, but on a standard ePMP 4500 (not the 4500L) with ~15x Force 400C clients, all on 5.11.0. We can replicate it on multiple sites.
The pattern on our side is TCP-specific:
UDP bandwidth tests through an SM: ~90 Mbps, completely stable (tested both 1400 and 1500 byte packets)
TCP tests through the same SM at the same time of day: 12-40 Mbps, highly variable
We have also observed that testing over a PPPoE Tunnel degrades the latency and speeds even further, specifically TCP once again.
So the raw airlink capacity is clearly there - it’s TCP that collapses, which matches the latency-spike behaviour scracha described.
Regarding the PPPoE. The issue you guys identified pertaining to the the TCP scheduler, does it makes sense that it’s getting affected by this issue as well, just curious? For further clarification the path is like this: