Is cambium keeping the stance to not do a ptp mode for the PTP 550? For one hop currently it's tolerable, but to be frank 7-15ms is not acceptable for a PTP link.
Hi,
We are working to reduce latency in TDD mode.
Additionally we are looking into possibility to introduce Low Latency mode as well.
Thank you.
3 Likes
It's not only that they latency is so high, but it's also the jitter with the PTP550 & E3K/F300 products. With the E2K/F200 - we can set them in ePTP mode and the latency is just flat flat flat... like a PTP product should be.
ePMP2000 to Force200 in ePTP Mode
PING 10.2.4.76 (10.2.4.76) 32(60) bytes of data. 40 bytes from 10.2.4.76: icmp_seq=1 ttl=64 time=1.42 ms 40 bytes from 10.2.4.76: icmp_seq=2 ttl=64 time=1.61 ms 40 bytes from 10.2.4.76: icmp_seq=3 ttl=64 time=1.61 ms 40 bytes from 10.2.4.76: icmp_seq=4 ttl=64 time=1.31 ms 40 bytes from 10.2.4.76: icmp_seq=5 ttl=64 time=1.28 ms 40 bytes from 10.2.4.76: icmp_seq=6 ttl=64 time=1.34 ms 40 bytes from 10.2.4.76: icmp_seq=7 ttl=64 time=1.37 ms 40 bytes from 10.2.4.76: icmp_seq=8 ttl=64 time=1.46 ms 40 bytes from 10.2.4.76: icmp_seq=9 ttl=64 time=1.73 ms 40 bytes from 10.2.4.76: icmp_seq=10 ttl=64 time=1.25 ms— 10.2.4.76 ping statistics —
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 1.255/1.492/1.734/0.222 ms
Ping times on ePMP2000-Force200 in ePTP mode from 1.2ms to 1.7ms with a 1.5ms average. So basically a flat-flat 1.5ms, plus or minus about 0.2 ms. That’s awesome, a flat 1.5ms with almost no jitter. 
Now here is the same link, with Force300 gear in TDD PTP mode, instead of Force200 in ePTP mode
PING 10.0.0.45 (10.0.0.45) 32(60) bytes of data.
40 bytes from 10.0.0.45: icmp_req=1 ttl=64 time=5.56 ms
40 bytes from 10.0.0.45: icmp_req=2 ttl=64 time=2.25 ms
40 bytes from 10.0.0.45: icmp_req=3 ttl=64 time=4.99 ms
40 bytes from 10.0.0.45: icmp_req=4 ttl=64 time=3.60 ms
40 bytes from 10.0.0.45: icmp_req=5 ttl=64 time=1.16 ms
40 bytes from 10.0.0.45: icmp_req=6 ttl=64 time=6.48 ms
40 bytes from 10.0.0.45: icmp_req=7 ttl=64 time=3.10 ms
40 bytes from 10.0.0.45: icmp_req=8 ttl=64 time=1.97 ms
40 bytes from 10.0.0.45: icmp_req=9 ttl=64 time=5.44 ms
40 bytes from 10.0.0.45: icmp_req=10 ttl=64 time=7.99 ms— 10.0.0.45 ping statistics —
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 1.164/4.298/7.991/2.019 ms
So we go from 1.5ms with Force200’s but now have a 4.3ms average… and pings go anywhere from 1.16 ms (awesome!) to 7.99ms?!? Basically jittler from 1 - 8ms?
On the positive side - with the Force300’s and ePMP3000 and PTP550’s, I do appreciate that the overall ‘regular’ TDD latency is lower, and I can understand that when you got latency down to 5ms, Cambium probably said “wow, that’s pretty good! That’s gone from 15ms to 5ms… we don’t even need an ePTP mode anymore!”. 5ms is is awesome for PMP, but for PTP latency/jitter is key…
With no ePTP mode is frankly a fatal flaw. I just don’t see how we can use them as PTP products, over hop after hop, adding precious ms on every hop. 
1 Like
2 ninedd
Please make ping with 1470 bytes size. In this case comparison ePTP mode Force 200 with TDD Force 300 will be more accurate. Because ePTP , it seems , has frame with variable size ( like standard wifi ), TDD - has fixed size 5 ms frame with fixed UL/DL.
I suppose fixed frame with flexible UL/DL ( with short guard interval) in TDD mode , that Cambium promises to make shortly, will allow to reduce latency in twice.
PTP550 latency jumping ( jitter) under heavy interference is another issue, that, I suppose, is not connected with frame size and TDD UL/DL division and has relationship with ARQ.
Hmm, well thats interesting, what sort of changes are expected and when?
I mean I have to agree, I have feeling a bit letdown by the latency here compared to all the other products, really got some unhappy customers - who also thought they were going to get sub 3ms latency on this hop.
1 Like
@Vyacheslav wrote:I suppose fixed frame with flexible UL/DL ( with short guard interval) in TDD mode, that Cambium promises to make shortly, will allow to reduce latency
Can someone from Cambium comment on this? Is this accurate? Is there an actual low latency (PTP type) mode coming on any ePMP3000 / Force300 / PTP550 product coming? I'm just struggling to figure out... I don't know how we can move forward with these products as they are.
Is there any progress on this? Need low latence on ptp
Hi,
We are pretty close to 4.5 Beta FW release with ePTP mode support.
If you'd like to try Alpha FW, you can reach me at fedor.trutsko(at)cambiumnetworks(dot)com.
Thank you.
@Fedor wrote:Hi,
.... 4.5 Beta FW release with ePMP mode support.
Fedor, did you mean ePTP mode? And if so, the PTP550 -will- be able to utilize ePTP mode? I had worked myself up to not be dissapointed when it would be announced PTP550 would not work in ePTP mode.
Sorry for delay with response.
Yes, I meant ePTP mode.
It will be availble on PTP550, but not for Channel Bonding mode.
Thank you.
1 Like
Plz share ptp 550 firmware version supporting eptp mode as getting high latency in tdd-ptp mode.
You go to Cambium’s support site and download the newest firmware. Remember, ePTP does not work in channel bonding mode.
It’s important to remember that the PTP550’s strongest feature is the channel bonding, and in order to do that, it needs to have synchronized frames on both radios. Meanwhile ePTP mode achieves it’s lower latency by having a flexible frame…
…which means that radio bonding, and ePTP mode are incompatible with each other. There’s simply no way to bond two radioes, unless they are fixed frame and synchronized with each other… which is what happens in TDD mode, not ePTP mode.
SO - we have used ePTP mode and it works fine… but can’t be combined with also bonding the two radios.