hi Richard, In phc2sys code, for default config phc_interval, update_clock is called once in a second based CLOCK_MONOTONIC timer. With sanity_check enabled, clockcheck_sample is also called. In clockcheck_sample function, we should depend on CLOCK_MONOTONIC to decide if its getting called more frequency than a second. But we also check on remote time:
interval = (int64_t)ts - cc->last_ts; if (interval >= 0 && interval < CHECK_MIN_INTERVAL) return ret; This may not be correct as remote phc time could have drifted. Hence when we call clockcheck_sample again mono_interval may be a higher value, resulting in variation of min and max freq_offset calculation. Can you please check this and suggest. regards, Ramesh On Tuesday, January 18, 2022, 11:10:22 PM GMT+5:30, ramesh t via Linuxptp-devel <linuxptp-de...@lists.sourceforge.net> wrote: hi Richard, With Step 1, it seems to be working fine, will try few more variations and check. Thank you for your help. But have few questions: Patches provided doesn't seems to have any relation with error "timed out while polling for tx timestamp" which occurred while transmitting Sync packets on master side. I'm not observing this error, any reason why? After recover/reboot of remote system, phc offset of the interface connected to TestUnit/remote system seems to be struck at improper value. [root@satdd-nec-worker0 ~]# /usr/sbin/phc_ctl enp95s0f1 cmp phc_ctl[645780.131]: offset from CLOCK_REALTIME is 31335266008ns phc2sys: [645792.375] clock jumped backward or running slower than expected! phc2sys: [645792.375] enp95s0f1 phc offset -68335289644 s0 freq -900000000 delay 3779 phc2sys: [645793.375] CLOCK_REALTIME phc offset -11 s2 freq -79884 delay 1143 phc2sys: [645793.375] clock jumped backward or running slower than expected! phc2sys: [645793.375] enp95s0f1 phc offset -68335291579 s0 freq -900000000 delay 3767 phc2sys: [645794.375] CLOCK_REALTIME phc offset 8 s2 freq -79868 delay 1156 phc2sys: [645794.376] clock jumped backward or running slower than expected! phc2sys: [645794.376] enp95s0f1 phc offset -68335293498 s0 freq -900000000 delay 3798 phc2sys: [645795.376] CLOCK_REALTIME phc offset 4 s2 freq -79870 delay 1158 Please suggest. regards, Ramesh On Monday, January 17, 2022, 09:35:54 PM GMT+5:30, Richard Cochran <richardcoch...@gmail.com> wrote: On Mon, Jan 17, 2022 at 08:25:06AM +0000, ramesh t wrote: > Please suggest. 1. Make sure your ptp4l has these five patches: a082bcd clockcheck: Increase minimum interval. 6df8425 port: Don't renew raw transport. e117e37 port: Don't check timestamps from non-slave ports. 262a49b clock: Reset clock check on best clock/port change. 7e8eba5 clock: Reset state when switching port with same best clock. If that doesn't fix the problem, then: 2. Disable clock sanity check. sanity_freq_limit The maximum allowed frequency offset between uncorrected clock and the system monotonic clock in parts per billion (ppb). This is used as a sanity check of the synchronized clock. When a larger offset is measured, a warning message will be printed and the servo will be reset. When set to 0, the sanity check is dis‐ abled. The default is 200000000 (20%). _______________________________________________ Linuxptp-devel mailing list linuxptp-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
