incorrectly calculated VARIANCE_GM_LOCKED ?
It is likely that the variance calculated for WR GM is incorrect 0xB900. In particular it indicates variance that is worse than that of Telecom GM. See the problem reported by Benoit below. It seems we would need to re-calculate the variance for WR GM:
Hi Maciej,
As we have talked about I send you both the value of clockAccuracy and logVariance states in PPSI
#define PP_MIN_CLOCK_ACCURACY CLOCK_ACCURACY_MIN_VALUE
#define PP_MAX_CLOCK_ACCURACY CLOCK_ACCURACY_MAX_VALUE
#define PP_ACCURACY_DEFAULT CLOCK_ACCURACY_UNKNOWN
#define PP_PTP_ACCURACY_GM_LOCKED CLOCK_ACCURACY_100_NS
#define PP_PTP_ACCURACY_GM_HOLDOVER CLOCK_ACCURACY_100_NS
#define PP_PTP_ACCURACY_GM_UNLOCKED_A CLOCK_ACCURACY_UNKNOWN
#define PP_PTP_ACCURACY_GM_UNLOCKED_B CLOCK_ACCURACY_UNKNOWN
#define PP_ARB_ACCURACY_GM_LOCKED CLOCK_ACCURACY_25_NS
#define PP_ARB_ACCURACY_GM_HOLDOVER CLOCK_ACCURACY_25_NS
#define PP_ARB_ACCURACY_GM_UNLOCKED_A CLOCK_ACCURACY_25_NS
#define PP_ARB_ACCURACY_GM_UNLOCKED_B CLOCK_ACCURACY_25_NS
#define PP_MIN_CLOCK_VARIANCE 0
#define PP_MAX_CLOCK_VARIANCE 65535
#define PP_VARIANCE_DEFAULT 0xC71D
#define PP_PTP_VARIANCE_GM_LOCKED 0xB900
#define PP_PTP_VARIANCE_GM_HOLDOVER 0xC71D
#define PP_PTP_VARIANCE_GM_UNLOCKED_A 0xC71D
#define PP_PTP_VARIANCE_GM_UNLOCKED_B 0xC71D
#define PP_ARB_VARIANCE_GM_LOCKED 0xB900
#define PP_ARB_VARIANCE_GM_HOLDOVER 0xC71D
#define PP_ARB_VARIANCE_GM_UNLOCKED_A 0xC71D
#define PP_ARB_VARIANCE_GM_UNLOCKED_B 0xC71D
Then from 8275.1 standard we have:
The following values of the clock attribute clockAccuracy apply for the following situations:
- 0x20 for a T-GM connected to an enhanced primary reference time clock (ePRTC) in locked-mode (i.e., ePRTC traceable to global navigation satellite system (GNSS));
- 0x21 for a T-GM connected to a PRTC in locked-mode (i.e., PRTC traceable to GNSS) or a T-GM connected to an ePRTC where the ePRTC is in phase/time holdover within ITU-T G.8272.1 ePRTC-A specification as specified in Table 3 of [ITU-T G.8272.1];
- 0xFE for a T-GM not connected to an ePRTC nor a PRTC in locked-mode, or a T-GM connected to an ePRTC in phase/time holdover but outside the holdover specification in Table 3 of [ITU-T G.8272.1];
- 0xFE for a T-BC, all the time.
20: The time is accurate to within 25 ns
21: The time is accurate to within 100 ns
The following values of the clock attribute offsetScaledLogVariance apply for the following situations:
- 0x4B32 for a T-GM connected to an ePRTC in locked-mode (i.e., ePRTC traceable to GNSS). This corresponds to TDEV of 10 ns, at observation interval of 1 000 000 s. The corresponding value of PTP Variance (PTPVAR) is 1.271 10 -16 s 2 (see Appendix IX);
- 0x4E5D for a T-GM connected to a PRTC in locked-mode (i.e., PRTC traceable to GNSS). This corresponds to TDEV of 30 ns, at observation interval of 10 000 s. The corresponding value of PTP Variance (PTPVAR) is 1.144 10 -15 s 2 (see Appendix IX);
- 0xFFFF for a T-GM not connected to an ePRTC in locked-mode nor to a PRTC in locked-mode;
- 0xFFFF for a T-BC, all the time
At 7S, we consider that ePRTC is an atomic-clock oscillator disciplined by GNSS (time_source=ATOMIC_CLOCK) and that PRTC is only GNSS receiver (time_source=GNSS). Thus you can see that the variance for locked GM is much better in 8275.1 than what you have computed, but then if in HO or FR the variance (of local oscillator) is much better for WRS.