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
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?
Hi jakkwb,
No, 30 and 50 MHz channels aren’t planned for the immediate future.
Sriram
Hello everibody.
Is disponible the firmware of F300 for not-contiguous chanel bonding?
Thanks
stefano, I thinks this feature won't reach F300.
Someone from Cambium can comment about TCP traffic differencies on UDP in the previous pages?
Hello i can connect force 300 to epmp 2000?
I cant connect and use PPoE.
Thanks!
Current firmware has F300 locked to TDD PTP mode, so at the moment it does not support SM mode
FIRMWARE 4.1.3-RC10
AGGREGATE THROUGHPUT RESULTS
20 Mhz = 153 Mbit Throughput!
40 Mhz = 312 Mbit Throughput!!
80 Mhz = 680 Mbit Throughput!!!
The Force300 and AC wave2 technology are still a work in progress, but the latest beta firmware is quite impressive for thoughput. I still have a hate for #SuperDimLEDs - but we'll put that asside for now.
Here are the latest test results in 20 Mhz, 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 need. This is outdoors, in the City - at 1.25 KM
20 Mhz Wireless Test = 153 Mbit Aggregate Throughput!
40 Mhz Wireless Test = 312 Mbit Aggregate Throughput!
80 Mhz Wireless Test = 680 Mbit Aggregate Throughput!!! <-- WOW!
So far, we're pretty impressed by the throughput from these Force300 units, and we look foward to the ePMP3000 AP's! :)
I can confirm throughput is far better starting from 4.1.3-RC8, they're working hard to give the best performance with this Force 300!
This isn't true only for UDP traffic, but also with TCP, and also jitter is better.
Great work Cambium developers!
Any info about TCP vs UDP problem ?
We found same problem on Force300 and PTP550, and Mikrotik are not problem !
1. Info for Mikrotik, from 6.44 btest are changed and finaly:
*) btest - added multithreading support for both UDP and TCP tests;
*) btest - added warning message when CPU load exceeds 90% (CLI only);
!) speedtest - added "/tool speed-test" for ping latency, jitter, loss and TCP and UDP download, upload speed measurements (CLI only)
2. Here are results from our Force300 below:
Mikrotik UDP say same:
Mikrotik TCP half speed:
For comparation we did test from same routerboard TCP speed over our PTP670 link, which are reporting 300 Mbps, and really have TCP and UDP 300+ Mbps, so..Mikrotik are not problem...especially after upgrading on version 6.44 that solves one core usage problem !
Too sad to hear that. I bought two brand new F300-25 yesterday, my colleagues and I tried today all day long with 4.1.4 FW, 1.56km PTP link over town, very bad performance on every channel from 4935 to 5945MHz, eather 20MHz, 40MHz or 80MHz. Clear LOS, signal between -45 and -52. Tried everything, change AP to SM and SM to AP mode on both sides, tried to decrease rf power, to increase rf power, nothing. Link performace show 97% quality and capacity 92%. The best result we got is 142/64Mbps TCP traffic.CCR1009 on both sides.UDP doesn't show anything relevant for serious PTP link in WISP industry. Those devices are not designated to work in highly noisy environment, it is simple as that. We had to get back od PBE 5AC 500-ISO with 60MHz channel width, 463/398Mbps real TCP traffic. Just to say that UBNT also doesn't work great at 20/40 or 80MHz, very bad traffic throughput. But, at 50 or 60MHz channel width, works great. So we need to wait for something to happen with those devices's FW or something else for much better noise improvements.
@mjoksimovic wrote:Too sad to hear that. I bought two brand new F300-25 yesterday, my colleagues and I tried today all day long with 4.1.4 FW
Why are you using such old firmware? Current is 4.3.1, and beta is 4.3.2-RC15.
How many TCP connections were you using in your testing? We've found we need to use 5+ to get proper measurements. Make sure your Mikrotik ROS is up to date with 6.44 or greater.
I'm extremely surprised you're seeing better results with the PBE and 60MHz channel width in a high noise environment. Something isn't right here.
@mjoksimovic wrote: I bought two brand new F300-25... ...with 4.1.4 FW, 1.56km PTP link over town, very bad performance on every channel... ...Tried everything.
Yikes, amongst the 'everything' to try, the newest firmware would have been good to also try. I mean, I don't know for sure how that would fare in your environment - but certainly 4.1.x was pretty early 'right out of the gate' software, and there has been LOTS of performance increases since then. :)
@mjoksimovic wrote: ...1.56km PTP link over town, very bad performance... . ..Link performace show 97% quality and capacity 92%. The best result we got is 142/64Mbps
We do a similar link - Force300's PTP, right over the center of town, with lots of noise, about 1.3km, so pretty similar to your situation. In 40 Mhz channel, we get about 310Mbit aggregate most of the time. Right now, at 7:48 PM (so, about the noisiest, busiest time of the day) we are getting 243 download, and 68 Mbit upload = so 311 Mbit aggregate in a 40 Mhz channel.
I should point out, my results are also with fixed frame 75%/25% - so in the future, if there is a flexible frame mode in any future firmwares, the equivalent numbers would be something more like 300/300 in a flexible frame type of test of course. ALSO, hopefully there will be an ePTP mode (specific Point-to-Point mode for ePMP radios) and at least in the ePMP1000 and 2000 series, that made quite a big improvement for PTP situations as well. Hopefully that sees it's way to the e3000 series.
@mjoksimovic wrote: Just to say that UBNT also doesn't work great at 20/40 or 80MHz, very bad traffic throughput. But, at 50 or 60MHz channel width, works great.
Agreed. We are also eager to see additional channel widths in the future - I hope so. It would be good to see 5 and 10 Mhz channels (for compatibility with the ePMP1000/2000 APs) and it would be great to see 30, 50 and 60 Mhz channel widths as well. Currently we are seeing over 300 Mbit in 40Mhz channels and about 600 Mbit in 80Mhz channels, so it'd be great to have 30 and 50 and 60 as available options too.
@mjoksimovic wrote: So we need to wait for something to happen with those devices's FW or something else for much better noise improvements.
The firmware you should be using is 4.3.1 version. If it was me, I'd try them in the shop before I go hang them outside again, and get an idea of the expected performance there. Then take them to the wild after that. There is also 4.3.2-RC15 BETA, but that's mainly for compatibility between epmp1000 series, 2000 series, and 3000 series... so I wouldn't use a BETA version in this PTP link.
Thank you for replying. Tried everything you wrote but nothing better. FW upgrade doesn't help so much. Agregate throughput is about 210Mbps but UDP. TCP sucks again. We changed channels several times, nothing. I'll put them in storage room for collection. They aren't for serious use for now. I need extremely stable and reliable link with at least 500Mbps real TCP throughput without these random oscilations and drops so these devices are not capable to serve this role. I will migrate to B24 or AF24. Thank you anyway.
Regards,
