Is wireless-fp useful for something besides CAPsMAN?

Are there other features/fixes in wireless-fp that make it worth using if you don’t care about CAPsMAN?
Has anyone fixed a wifi problem by going from ‘wireless’ to ‘wireless-fp’?

Lower latency with NV2. Better throughput in some cases, but not all.
No change in nstreme. Actually I had problems with 1 link where the other side is an old board with v2.9 which i can not upgrade.
For 802.11 I can’t really say, I’d say no change or very little improvement. I have a lot of customer ptmp with 802.11, but this protocol is too unreliable in performance to make a good measure.

To sum it up : If you use nv2 you should definately use wireless-fp.

I, on the other hand, have had intermittent wireless stalling issues with Android devices when using wireless-fp package with no other changes. Problems stopped when going back to legacy wireless package.

I have not realized that. Using wireless fp for months on different devices without negative impact on Android clients.

On the contrary… I’ve seen devices not working with wireless that are now working correctly with wireless-fp :slight_smile:

LOL. Can’t we all just get along? I really wish they could get a few of these wireless incompatibilities and annoyances worked out.

Then you should provide enough details to support so they can repeat and correct the error if any.

I’d love to, but it’s too sporadic and nothing shows in the logs, not even with debug log enabled. So it is what it is, for now.

I have not tried using the wireless-fp , I am using normal wireless setup…

In enabling and using the wireless-fp package, do you guys also change the wireless-default queue on the wlan interface into ‘only-hardware’ queue?

I’ve seen this somewhere on the forum it should (can’t find it anymore though..)

And I presume the wireless-fp package have to be enabled on both station as AP to have any effect?

Yes WirelessRudy, i read this in other topic from “Normis” and i am using this with better performance!

No. I keep the wireless default ques till now without any problems. I switch them and see if it brings some notable difference.

wireless fp; “fp” means “fastpath”, this ONLY works if on both end of the link (ether, wireless) the interface have “only-hardware-queue” enabled.
see http://wiki.mikrotik.com/wiki/Manual:Fast_Path

If any of the conditions is not met, it doesn’t work…

Besides that, some minor changes (improvements???) might have come with the new package. But as wireless links/radio waves are always a bit dynamic (variable due atmospheric or spectrum usage changes) it will be very hard to find link changes if fp is/is not used that are definately a result of the new wireless package.

And fastpath when enabled and in force (all conditions met?) will probably only see improvements when lots of traffic is pushed over the link. But yet again, don’t push your link to the limit because every link has its limit, no matter what technology or settings used. And when the limit is met, some data is not passed and your link performance goes down.
(Example; Try to ‘pump’ 40Mb traffic flow over a link that can only handle 30Mb. You’ll see 25% data is not passed they way you’d want. Would it now make a difference if you use either wireless legacy or wireless fp package? No, in both cases you still loose some 25%. How can you now tell wich of the both package is performing best? Because one test shows 22-27% and the other too? Imposible… :confused: )

To really make a statement about an improvement on your specific link with, or without wireless fp package, you need to create equal circumstances with not too much traffic, also not too little, and do ping tests and ‘lost packages’ test several times to create a more balanced test outcome.

All other results are probably more based upon a ‘feeling’ or wishful thinking of user…
Wireless environments are very dynamic and lots of minor improvements are marginal compared to the absolute link performance. So these improvements basically ‘drown’ in the already present link dynamics… :astonished:

for me wireless-fp and new v6.19 gave every mk wireless device much more stability, better throughoutput…so I recommnend it…

I’m a bit hesitating in upgrading to 6.19. It wouldn’t be the first time that while halfway the upgrading of my entire network some reports surface on this forum still some bugs or issues are around, or worse; created again.

Can you tell me how your device became more stable after the upgrade to 6.19?
What was the situation before and after. What are the actual configs.

I found many time people reporting improvements, or worsening, of links or other network setups which later found actually had nothing to do with the upgrade, just changing circumstances or other changes performed at the same time.

I have been having problems with Android Wi-Fi stalling for minutes at a time with ROS 6.x ever since I can remember. I upgraded to 6.19 a few days ago and so far the problems seem to be completely gone. I did change a few other settings at the same time, so ymmv. I also changed Adaptive Noise Immunity to “Both” and changed the Group Key Interval to 1-hour.