RTT-reporting on long links (again!): wr_mon and SNMP on WR-Switch
Reported by Anders Wallin:
I seem to have issues with RTT-reporting on long WR-links again!
Previously it was with a 10.4ms RTT using SPEC as both GM and Slave – that was fixed in the “gui” command for the SPEC.
We now have one link with a WRS as GM and a WRS as Slave. The RTT is around 840 us – and this seems to work fine.
Both wr_mon and SNMP report 840us (in picoseconds, so a 12-digit number)
This number shows variation as expected over hours and days.
However, today on another long link (again WRS at both ends) I see a number “912.316 nsec”.
Simple geography (google-maps) suggest a one-way distance of 185 km, which should give an RTT of roughly 1.85 ms.
The same 912316 value is reported also by SNMP.
Another strange thing with this value is that it seems static. No variation whatsoever over an hour of observation, always that 912316.
PTP seems to be working, I see “Track_Phase”, and there is variation on the picosecond level of “link asymmetry”, “clock offset”, and “phase setpoint”.
Also the PPS-output of the WRS Slave seems roughly right – although not verified rigorously yet.
Wrs_version: PCB 3.30, FPGA: LX240T, version v4.2
Any ideas? Why would 840us work and 1.85ms somehow not (not a 32-bit wrap-around!?). What else could it be?
The static 912316 would suggest to me that we are seeing some kind of wrap-around, and then only the high (MSB) bits of the true number?
Debugging for this one is limited because I don’t have remote access and it is a 2hour drive there and 2hours back…