ePMP Release 4.1.2 is now available for the ePMP Force 300 and PTP 550. The Software can be downloaded at:
2 Likes
When can we expect ePTP? This device is basically useless ATM.
1 Like
Its my understanding that there will be no eptp mode. The latency difference between tdd and “eptp” would be marginal to none. What are you seeing for rtt ?
Hi
rtt min/avg/max/mdev = 4.178/10.419/20.156/5.233 ms
Thanks
Pinging the local end is 0-1ms
Pinging the remote end of a 1.25km link is up to 15ms
Minimum = 1ms, Maximum = 15ms, Average = 5ms
I don't really understand how/why it can be 1ms sometimes, and 15 ms sometimes. It is possible, however, that Flexible Frame will improve this once that's available. Plus we don't really have control over frame size yet (5ms vs 2.5ms) right? So perhaps when the features are completed, it'll be better.
It's implement not-contiguous 80Mhz channel bonding for F300?
@ninedd wrote:Pinging the local end is 0-1ms
Pinging the remote end of a 1.25km link is up to 15ms
Minimum = 1ms, Maximum = 15ms, Average = 5ms
I don't really understand how/why it can be 1ms sometimes, and 15 ms sometimes. It is possible, however, that Flexible Frame will improve this once that's available. Plus we don't really have control over frame size yet (5ms vs 2.5ms) right? So perhaps when the features are completed, it'll be better.
try pinging something through the radio and see what you get, some devices don't really give much attention to a ping, we've got some switches that will ping as high as 100 when you hit them, but a device attached to the far side of them will be .05 ms.
@stefanogranata wrote:It's implement not-contiguous 80Mhz channel bonding for F300?
thats a PTP550 feature, not epmp300. (that would be sweet 300/3000 feature cambium!!!!)
2 Likes
wrote:.
try pinging something through the radio and see what you get, some devices don't really give much attention to a ping, we've got some switches that will ping as high as 100 when you hit them, but a device attached to the far side of them will be .05 ms.
OK, perhaps. Although both my examples are both pinging Force300 units - one on this side, and one on the other side. I would assume (maybe not?) that both units would be equally adept at answering pings.
This link is a backhul to the internet, so there isn't really anything on the far side (the internet/fiber side) that I can ping. However, I can ping Google as a test - these two examples are switching from an AirFiber to a Foce300 link. The AirFiber is 59ms to Google, plus or minus 1ms - with a 59ms average. Switching over to the Force300 backhaul is anywhere from 64ms to 81ms to Google, with an average of 71ms. So, comparing that to the AirFiber's 59ms average, the Force300 link is from 5ms more, to 22ms more - with an average of 12ms more vs the AirFiber.
So, this isn't very scientific I realize... this is just from my Windows desktop to Google. BUT, it's duplicatable with pretty much the same results, no mater how I test it.
As I've said before - I'm not too terribly bugged by the 5ms latency if that's what it needs to be, but the plus of minus 10-15ms jitter is more puzzling. I've asked Cambium if they expect that a Flexible Frame would likely reduce this, or if a 2.5ms frame size setting might fix things up... but no reply so far.
Dont forget RF plays a role as well. At 5.7mi (9.17km) we have a steady 2-3ms, occasional 5 or 7.
Dont forget that usage will affect the ping response. So below the clean table is normal usage, high loss was maxing the uplink, 200ms was maxing the downlink
