ninedd, thank you for your feedback about Force 300-25!
We’re starting to try them and I can confirm they are a good product.
It’s a pity they can’t reach 30dBm output power like Force 180, 190 and 200, but maybe they’ll work on this.
May I ask you what software you use to graph ping times?
Thank you!
@giuseppe4 wrote:
May I ask you what software you use to graph ping times?
Those graphs are with CACTI. There is software that's probably better for Latency graphing (SmokePing?) but CACTI works with our Cambium and non-Cambium products, so we like to use it to have all the graphs for all the gear in one place.
Just to throw in here, it looks like everyone is doing short distance links. We have one setup at 6.25mi (10km) 5220/20mhz at 26dbm the MCS does flucuate from 4-7 on downlink, but we are able to sustain 85-95mbps down and 20-25mbps up. 40mhz at 25dbm we were holding ~140 down and 30 up (do not remember MCS)
We were unable to get 80mhz to link up unfortunately, possibly due to the 18dmb max.
This is on 4.1.1 full release
Wanted to REreply, found out the fools who mounted the 300 didnt align it properly...
Same 6.25mi (10km) 75/25 mode
5220/20 26dbm MCS locked at DS9/9 @54pl
Throughput 120/36 steady down/up
5220/40 25dbm MCS again locked at DS9/9 @55pl
Throughput 215/75 steady down/up
5210/80 18dbm wasnt clean, MCS DS5-7 over 6 @61pl
Throughput 160-275/50 not steady down/up
1 Like
Cool - thanks for the updated info. 
290 mbit aggregate is pretty cool.
@Skullzaflare wrote:
Wanted to REreply, found out the fools who mounted the 300 didnt align it properly...
Same 6.25mi (10km) 75/25 mode
@5220/20 26dbm MCS locked at DS9/9 @54pl
Throughput 120/36 steady down/up
@5220/40 25dbm MCS again locked at DS9/9 @55pl
Throughput 215/75 steady down/up
@5210/80 18dbm wasnt clean, MCS DS5-7 over 6 @61pl
Throughput 160-275/50 not steady down/up
Thanks for sharing. Please note that we are not quite there yet in maximizing 80MHz tput. We are still working on this and plan to address in 4.1.2 (very near future)
We didnt have enough clean spectrum to use the 80 to test anyway, we have a lot of 5g backhauls, until we get those moved to 6g we will not have 80 ever lol.
Would be interested to see what kind of throughput we could get on 10mhz if that is ever added
1 Like
OK - on this Force300 link that we installed in April, we just upgraded to 4.1.2-RC14, which adds a number of things, including a Wireless Throughput Test. We have tested 80 Mhz capacity and I'm pretty impressed.
Channel Width = 80 Mhz
Download = 363 Mbit
Upload = 165 Mbit
Aggregate = 528 Mbit
Channel Width = 40 Mhz
Download = 203 Mbit
Upload = 73 Mbit
Aggregate = 276 Mbit
- Force300_ThoughputTest_80Mhz_Aug01_18.jpg (22.9 KB)
- Force300_ThoughputTest_40Mhz_Aug01_18.jpg (23.5 KB)
Wow!
How is your 80MHz channel? Clean?
Yes, but we also temporarily shut off some other 5Ghz gear for testing. We only need 40 Mhz width performance in this location, so we've changed this link back to 40 Mhz wide anyway. Well, actually - it's be nice to have 50Mhz channel widths probably... we have a 250 Mbit fiber we are backhauling. However, if Flexible Frame is coming, then that'll probably do that nicely in 40 Mhz widths... right now it's configured 75/25. However, I wanted to post the 80MhZ results... which are pretty awesome in this price range.
I imagine we'll actually use ePMP3000 AP's for this backhaul when they are available, assuming that they have the same filtering of the ePMP2000's hopefully - but we'll wait and see. But, for anything in the CPE price range, the Force300 is pretty impressive I think.
Thank you for your feedback!
I tried 40MHz channel on 4.1.2-RC14.
It works good and seems pretty stable (I limited upload on MCS 8 so it's more stable).
UDP Performances (on MikroTik bandwidth test) looks similar to Wireless Link Test (about 210Mbps, stable), but using iperf, MikroTik Bandwidth Test or nperf or speedtest.net on TCP I can see these results:
about 130Mbps on download, not super stable, sometimes you can see 160, sometimes 120, sometimes 150... Rarely more.
65-69Mbps on upload each test, super and perfectly stable.
Why is TCP so different?
ninedd, did you find such a difference?
Small update: tried to lock also downlink to MCS8, and these are the results:
Speedtest on nperf
Performances
As you can see, download is higher and more stable than keeping downlink modulation on MCS9 max.
Why? Anyone with similar results?
Exactly the same strange result - 130 Mbps TCP in 80 MHz ( 50% MCS7 -64QAM256 5/6, higher modulation -few %). 200 Mbps - when max modulation is fiхеd to MCS7. Wrong link adaptation in 80 MHz, that impacts to TCP traffic?
In 20/40 MHz -99% works at MCS9. In 80 MHz (90% below MCS7), RSSI -52 dBm, no interference .
Test is done by BT Mikrotik.
With UDP traffic in 80 MHz- no problem. Also there are no serious problems with TCP/UDP in 20/40 MHz.
Firmware v.4.1.2 RC14.
I have found TCP testing to be heavily reliant on the router CPU, for example, i have only seen the downlink above 145mbps on TCP for mikrotik testing a few times. Check CPU usage at both ends when you run a TCP test
I tested speed on CCR and using iperf and also an Internet speedtest, and results are very very similar, so it’s not the MikroTik the bottleneck
No comment from Cambium?
So a couple things... we've found the Mikrotik bandwidth test to be super unreliable, especially the TCP tests. Here's what we've found works best. Use UDP, and instead of watching the bandwidth test, actually watch the interface's data rate on the router you're testing against (the far router). This will give you the most accurate results in terms of real world performance. Also, pay close attention to the CPU's on both routers to make sure they're not maxed out while running the tests.
AGGREGATE THROUGHPUT RESULTS
40 Mhz = 300 Mbit Throughput!
80 Mhz = 550 Mbit Throughput!!!
OK, so we know that the Force300 and AC technology is a work in progress, and I'm pleased to say that I'm pleased with the performance. (Mounting brackets and SuperDimLEDs aside for the moment). The Force300's, even in their current 'work in progress' state are really quite remarkable for us. :)
Here are my latest results in 40 Mhz and in 80 Mhz widths. We are currently using them in 40 Mhz for our production needs, because that's all the speed we have available to them, and we just love how much data we can get in only 40 Mhz of spectrum. This is outdoors - at 1.25 KM
40 Mhz Wireless Test = 300 Mbit Aggregate Throughput!
40 Mhz Monitor Performance = DSMCS9 @ 99.4% / DSMCS9 @ 100%
80 Mhz Wireless Test = 551 Mbit Aggregate Throughput!!! <-- WOW!
80 Mhz Monitor Performance = DSMCS7 88% / DSMCS9 100%
So, throughput is awesome. The 80 Mhz "Monitor Performance" shows that it's wanting to be on MCS7 or MCS8 and not MCS9... unless this is a display issue somehow? This is a link capable of passing 550 Mbit of aggregate data, so it doesn't feel like it's struggling.
THE OTHER ISSUE that I see and that other's have raised is latency. It isn't horrible, but it's also not as good or as stable as the ePMP2000 links we have. I do wonder if there was a ePTP mode, would that shave a bit off.. or if that would make it a bit more stable? I'm not too terribly bugged by 5ms average over a single hop (although that would obviously be better if that was lower) but it's the variability. If we go several hops with Force300 backhauls, the ping times and the jitter will add up. Again - I absolutely do realize this is still an early product, and that this is RC firmware - but just saying that even a modest improvement in latency and latency stability would be welcome. :)
Here is the results of pinging both sides of a link... 10.0.0.46 is the SM/Slave side nearest to me, and 10.0.0.45 is the AP/Master side on the other end of the 40 Mhz wide wireless link.
Wireless Latency
Minimum = 1ms, Maximum = 15ms, Average = 5ms
- Force300_40Mhz_WirelessThroughput_300Mbps.jpg (17.5 KB)
- Force300_40Mhz_MonitorPerformance.jpg (146 KB)
- Force300_80Mhz_WirelessThroughput_551Mbps.jpg (18.5 KB)
- Force300_80Mhz_MonitorPerformance.jpg (106 KB)
- Force300_40Mhz_PingLatency.jpg (696 KB)
3 Likes
Stephen,
You noted that " One thing I have ran into is the AP side will stop talking on my LAN side every 24 to36 hours do not know how to fix this do you.".... Do you still have this issue or what did you do to resolve??? We have this issue with 4.1.1
Considering trying some of these to replace old Nanobridge links....
Is 30mhz and 50mhz channel size going to be an option down the road?