Hello,
I’m wondering if anyone who is using the cnWave 5G can tell me what latency they are getting and if there is much jitter?
The data sheet says 6-8ms which seems a little slow for a product using 5G and OFDMA technology.
Whereas PMP450 is closer to 3-4ms on the specifications sheet.
We are looking at an application that’ll have 1-3 subscribers per Basestation and its mission critical for low latency and jitter.
Kind regards
Hi James,
You will see 10 ms average.
This is even under load.
Why are you using this product if you only going to have 1 - 3 subscribers?
That defeats the entire purpose of this unit as it uses MU-MIMO.
It’s a mining company, we were looking at OFDMA specifically to reduce latency.
I feel OFDMA wasn’t specifically created with reducing latency as a primary goal.
James, could you share some details about your intended link such as distance, required throughput, latencies (what exactly are you dealing with ?), what kind of sensitive applications will be running over that link (voice ? technology real-time control and monitoring ?). Maybe you could look at other products - for example Force400 or Force4600.
Force400 is capable of 5ms avg pings at full load : Cambium Force 400 на платформе 802.11ax (Wi-Fi 6) для каналов точка-точка - Cambium Networks - Форумы NAG.RU
it’s in russian but graphs, units and numbers don’t need translation (and google translates the whole page beautifully). For those afraid to open russian pages : 40MHz channel = 450Mbps real throughput upload or download (Force400 is not TDD so there is no mandatory download / upload channel ratio), at 9km distance.
40 bytes from 10.202.18.99: icmp_req=1 ttl=64 time=4.27 ms
40 bytes from 10.202.18.99: icmp_req=2 ttl=64 time=2.69 ms
40 bytes from 10.202.18.99: icmp_req=3 ttl=64 time=8.55 ms
40 bytes from 10.202.18.99: icmp_req=4 ttl=64 time=3.50 ms
40 bytes from 10.202.18.99: icmp_req=5 ttl=64 time=3.73 ms
40 bytes from 10.202.18.99: icmp_req=6 ttl=64 time=4.82 ms
40 bytes from 10.202.18.99: icmp_req=7 ttl=64 time=6.54 ms
40 bytes from 10.202.18.99: icmp_req=8 ttl=64 time=2.44 ms
40 bytes from 10.202.18.99: icmp_req=9 ttl=64 time=2.65 ms
40 bytes from 10.202.18.99: icmp_req=10 ttl=64 time=7.32 ms
40 bytes from 10.202.18.99: icmp_req=11 ttl=64 time=2.48 ms
40 bytes from 10.202.18.99: icmp_req=12 ttl=64 time=8.79 ms
40 bytes from 10.202.18.99: icmp_req=13 ttl=64 time=8.94 ms
40 bytes from 10.202.18.99: icmp_req=14 ttl=64 time=7.61 ms
40 bytes from 10.202.18.99: icmp_req=15 ttl=64 time=8.19 ms
40 bytes from 10.202.18.99: icmp_req=16 ttl=64 time=3.52 ms
40 bytes from 10.202.18.99: icmp_req=17 ttl=64 time=8.59 ms
40 bytes from 10.202.18.99: icmp_req=18 ttl=64 time=2.77 ms
40 bytes from 10.202.18.99: icmp_req=19 ttl=64 time=3.62 ms
40 bytes from 10.202.18.99: icmp_req=20 ttl=64 time=3.18 ms
— 10.202.18.99 ping statistics —
20 packets transmitted, 20 received, 0% packet loss, time 19032ms
rtt min/avg/max/mdev = 2.443/5.214/8.949/2.449 ms
sure that’s just 20 responses but there’s a huuuuuuge text file attached to the topic with 20MHz channel latencies under full load. And they are as brilliant as you can see above.
This is how it looks like if you don’t have full radio (“only 380Mbps” instead of 450Mbps above), 1470 byte pings :
PING 10.202.18.104 (10.202.18.104) 1470(1498) bytes of data.
1478 bytes from 10.202.18.104: icmp_req=1 ttl=64 time=2.79 ms
1478 bytes from 10.202.18.104: icmp_req=2 ttl=64 time=2.85 ms
1478 bytes from 10.202.18.104: icmp_req=3 ttl=64 time=2.36 ms
1478 bytes from 10.202.18.104: icmp_req=4 ttl=64 time=2.94 ms
1478 bytes from 10.202.18.104: icmp_req=5 ttl=64 time=2.11 ms
1478 bytes from 10.202.18.104: icmp_req=6 ttl=64 time=2.30 ms
1478 bytes from 10.202.18.104: icmp_req=7 ttl=64 time=2.28 ms
1478 bytes from 10.202.18.104: icmp_req=8 ttl=64 time=1.93 ms
1478 bytes from 10.202.18.104: icmp_req=9 ttl=64 time=2.67 ms
1478 bytes from 10.202.18.104: icmp_req=10 ttl=64 time=2.69 ms
1478 bytes from 10.202.18.104: icmp_req=11 ttl=64 time=2.46 ms
1478 bytes from 10.202.18.104: icmp_req=12 ttl=64 time=2.49 ms
1478 bytes from 10.202.18.104: icmp_req=13 ttl=64 time=2.45 ms
1478 bytes from 10.202.18.104: icmp_req=14 ttl=64 time=2.42 ms
1478 bytes from 10.202.18.104: icmp_req=15 ttl=64 time=2.73 ms
1478 bytes from 10.202.18.104: icmp_req=16 ttl=64 time=2.83 ms
1478 bytes from 10.202.18.104: icmp_req=17 ttl=64 time=2.91 ms
1478 bytes from 10.202.18.104: icmp_req=18 ttl=64 time=2.61 ms
1478 bytes from 10.202.18.104: icmp_req=19 ttl=64 time=2.91 ms
1478 bytes from 10.202.18.104: icmp_req=20 ttl=64 time=4.12 ms
— 10.202.18.104 ping statistics —
20 packets transmitted, 20 received, 0% packet loss, time 19028ms
rtt min/avg/max/mdev = 1.935/2.646/4.125/0.439 ms
I don’t think we can ask for more from this technology.
That was not 6GHz, not 802.11ax, not Force4600c. Mining company most likely will be placed outside of interference in remote area, which will make the link even better.
Vendor specifications for low-latency/low-jitter appz quite often hugely overstate the true real requirements. Because they simply want to be covered at maximum possible level.
Sure you can’t build your business case on expectation / hope, just saying : I’ve created several emergency radio links for datacenter technology and software which were abused heavily - you know how it goes with non-tech customers - and because of that, failed miserably to fulfill those original requirements.
edit : you can transfer almost 900Mbit/s of real data over 80MHz channel, 12km distance on Force400. No artificial tests, just real traffic. If your customer requires couple of megabits, not hundreds of Mbits, I would seriously consider Force400, Force4600.
Thanks for your reply,
Typical distance is 1-3km; the customer currently has a couple of hundred Cambium PMP450i
The network is connected to a Rajant Mesh system, this product is heavily dependent on a traffic off loading protocol called APT.
Essentially you want to create as little hops on the mesh network as possible, it creates network paths on the mesh and over fixed infrastructure (450i and Fibre etc)
Because 450i is a timing synchronisation system that occasionally causes jitter as Rajant packets will swap between the fixed wireless and sent over the wireless mesh to skip the cambium network all together.
I’m wanting to trial the 450i with a metric ton of contention slots, and see what that does…
you don’t have fixed points there - these deal with moving machines or something like that ?
The PMP450’s are on trailers, with AP’s on towers.
The Rajant devices are on trailers and mobile equipment