Re: [Linuxptp-users] How to use PTP for accurate relative time accuracy (when doing local timestamping) instead of absolute time accuracy?

[C. D. <cd...@ou...>]

> I'm not sure what this is supposed to do. The jbod option belongs to
ptp4l.

Oops, wrong copy paste! Here is what I currently I run on the master:

For the NTP layer, I use chrony with an input of about 10 stratum1 servers that are 5 to 8ms away, as measured by ping and confirmed by chronyc sources, with minpoll 4 maxpoll 4  iburst for each and then:

stratumweight 0
hwtimestamp *
lock_all
sched_priority 1
logdir /var/log/chrony
log tracking measurements statistics
maxupdateskew 100.0
hwclockfile /etc/adjtime
rtcsync
makestep 1 3

Since available_clocksource shows: tsc hpet acpi_pm, the clocksource is set to hpet by the rc.local:
echo hpet > /sys/devices/system/clocksource/clocksource0/current_clocksource

chrony starts fine:
Mar 26 06:42:12 d1 systemd[1]: Starting chrony, an NTP client/server...
Mar 26 06:42:13 d1 chronyd[2634]: chronyd version 3.4 starting (+CMDMON +NTP +R EFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG)
Mar 26 06:42:13 d1 chronyd[2634]: Enabled HW timestamping on eth0
Mar 26 06:42:13 d1 chronyd[2634]: Enabled HW timestamping on eth3
Mar 26 06:42:13 d1 chronyd[2634]: Enabled HW timestamping on eth2
Mar 26 06:42:13 d1 chronyd[2634]: Frequency 10.106 +/- 0.004 ppm read from /var /lib/chrony/chrony.drift
Mar 26 06:42:13 d1 chronyd[2634]: Loaded seccomp filter
Mar 26 06:42:13 d1 systemd[1]: Started chrony, an NTP client/server.

I ponder about correcting each stratum1 server by their average  offset since they seem quite stable on repeated measurements, as you can see on this plot of the column 5 of /var/log/chrony/statistics:

[cid:image003.png@01D4E3AC.49DBF920]

But there are just some correlated discrete jumps that I can’t explain, as it often increases the spread but then remains linear before exploding again sometimes :

[cid:image006.png@01D4E3AC.49DBF920]

I notice the exact same phenomenon on a spare server that’s just monitoring these 10 stratum1 servers, so I suppose this is just some NTP protocol woes, but just to be safe I am also logging this data on this spare with a regular ntp, for later analysis.

I’m not sure how correcting by the offset will help. I have written scripts to compute the average offsets and put them in chrony.conf It seems to slightly improve the situation, but I though chrony already used these average? Anyway, I will keep doing that until I can no longer see lines, and just get noise

[cid:image008.png@01D4E3AC.49DBF920]

Then for the PTP layer,  I use on the master the options you suggested:
# hardware timestamping with no offset
/usr/sbin/ptp4l --clockClass 6 -H -i eth2 -i eth3 --uds_address /var/run/ptp4l.socket -m --boundary_clock_jbod=1 --utc_offset=0
# no -a because can’t mix autoconfiguration and manual conf
/usr/sbin/phc2sys -s CLOCK_REALTIME -c eth3 -r -r -P 1e-4 -I 1e-8 -O0

And on the slaves through /usr/sbin/timemaster -f /etc/linuxptp/timemaster.conf
/usr/sbin/chronyd -n -f /var/run/timemaster/chrony.conf
/usr/sbin/ptp4l -l 5 -f /var/run/timemaster/ptp4l.0.conf -H -I eth1
/usr/sbin/phc2sys -E linreg -a -r -R 1.00 -z /var/run/timemaster/ptp4l.0.socket -t [0:eth1] -n 0 -E ntpshm -M 0

I am not using the direct connection between the slaves at the moment, as explained below:

> There can be only one process synchronizing each clock. A single
phc2sys -a using one or two -r should be enough. When the server 1
goes down, the other servers will synchronize to one of their
interfaces (or system clock with -r -r). When server 1 is back, they
will quickly resynchronize with it. That may or may not be what you
want.

This is what I want if it happens, but not quickly: very slowly instead, as I care more about keeping the internal time consistency of the local cluster, even if it diverges from external sources.

So after a reboot, I want the NTP sync to happen very quickly even if it causes discrete jumps, then I want the whole cluster to remain internally consistent and slowly adjust to the ideal NTP time – but not at the cost of changes bigger than say 100 ns. I think this is why you said to use low PI and no linreg on the PTP master