>Provides the ability for the AP to operate as a WLAN device when in Standard WiFi mode so any 802.11 client can connect to it within a 300 meter radius
What good is WiFi mode if we're limited to such a small restriction? None of our Mikrotik/Ubiquiti/etc PTMP deployments are under a thousand feet.
Josh,
The WLAN mode is something you have to specifically enable. Simply switching the Access Point Mode to Standard WiFi will allow you to connect Mikrotik/Ubiquiti SMs at longer distances.
There was no change in latency for us moving from 5ms-flexible to 2.5ms-75/25.
_______________
What about 2.5 ms Flexible?
This is expected. Flexible and 2.5ms are very close with respect to latency (Flexible is typically lower) but as you know you cannot sync in Flexible mode.
For my testing, v2.5 with 2.5Ms frame had more latency and jitter than what we were getting with 2.4.3 BUT that’s because we are using 2.4 ghz and in town, 10 MHz channel width give us the best results. We can get between the other interference with 10 MHz channels, and with 20 MHz channels we bump into other noise and the performance goes down and latency goes up. So, when we upgrade to v2.5 we lose 10 MHz widths so testing 2.5ms frame time actually gives us worse overall latency compared to 2.4.3 and 10 MHz widths.
I'll be waiting for 10mhz channel sizes in 2.5 frame size but wondered if this 2.5 software version has any benefits for those of us not wanting to sync with PMP 100 and still running 5ms frame size?
I'll be waiting for 10mhz channel sizes in 2.5 frame size but wondered if this 2.5 software version has any benefits for those of us not wanting to sync with PMP 100 and still running 5ms frame size?
I believe Cambium reps have mentioned that they're not going to release a 2.5ms frame size for any other channel widths. The 2.5ms frame size was primarily implimented for PMP100/FSK collocation/migration.
If your not using sync, then you're most likely using 'flexible' downlink/uplink ratio mode... using 2.5ms would give you a slight latency reduction benefit, at the expense of around 10% reduction in overall throughput.
Another major benefit (IMHO) is that firmware rev 2.5 also gives you DFS channel support for ePTP mode. ePTP mode gives you the lowest possible latency and greatest overall throughput of any of the configurations, but at the expense of not being able to do GPS timing, and limited channel width options (only available on 20/40MHz channel widths).
I'll be waiting for 10mhz channel sizes in 2.5 frame size but wondered if this 2.5 software version has any benefits for those of us not wanting to sync with PMP 100 and still running 5ms frame size?
I believe Cambium reps have mentioned that they're not going to release a 2.5ms frame size for any other channel widths. The 2.5ms frame size was primarily implimented for PMP100/FSK collocation/migration.
If your not using sync, then you're most likely using 'flexible' downlink/uplink ratio mode... using 2.5ms would give you a slight latency reduction benefit, at the expense of around 10% reduction in overall throughput.
Another major benefit (IMHO) is that firmware rev 2.5 also gives you DFS channel support for ePTP mode. ePTP mode gives you the lowest possible latency and greatest overall throughput of any of the configurations, but at the expense of not being able to do GPS timing, and limited channel width options (only available on 20/40MHz channel widths).
Yes, we currently don't have a target release to provide 10 MHz with 2.5 ms frame but never say never :) We're flexible with our roadmap and will always consider adding features if the demand is there. But first we need to get smaller channels on AP WiFi mode (and perhaps ePTP) so it can help better with migration from non-Cambium gear using AP WiFi.
One thing I'd like to mention here is that channel bandwidths other than 20 and 40 MHz are not native to the 802.11n Atheros chip/driver. So when we introduce a new mode of operation, its not so much that we lose 5/10 MHz but rather something we have to ADD into the driver. When we add these new channel bandwidths, a lot of work goes into optimizing the scheduler and other complex mechanisms (rate adapt, ARQ etc.) so we get the best performance and efficiency out of these smaller channels. Its easy enough to add smaller channels but it takes a lot more work to optimize them to provide good performance.
How is the P100 and ePmP sync'd together? The P100 uses its sync and the ePmP uses its own sync separately but they are clocked? Needs some explaining. Thanks.