phc2sys offset issue

[Maku-chan]

Hi,

I synchronized the ptp clock with the below mentioned command and it seems that it is synchronized sudo /usr/sbin/ptp4l -m -f /etc/linuxptp/ptp4l.conf_as_final ptp4l[7344.881]: selected /dev/ptp0 as PTP clock ptp4l[7344.920]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[7344.952]: port 2: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[7344.992]: port 3: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[7345.024]: port 4: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[7345.024]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[7351.106]: port 2: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES ptp4l[7351.106]: selected local clock 70f8e7.fffe.d008a9 as best master ptp4l[7351.106]: assuming the grand master role ptp4l[7351.569]: port 3: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES ptp4l[7351.569]: selected local clock 70f8e7.fffe.d008a9 as best master ptp4l[7351.569]: assuming the grand master role ptp4l[7351.569]: assuming the grand master role ptp4l[7352.621]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES ptp4l[7352.621]: selected local clock 70f8e7.fffe.d008a9 as best master ptp4l[7352.621]: assuming the grand master role ptp4l[7352.621]: assuming the grand master role ptp4l[7352.621]: assuming the grand master role ptp4l[7352.666]: port 4: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES ptp4l[7352.667]: selected local clock 70f8e7.fffe.d008a9 as best master ptp4l[7352.667]: assuming the grand master role ptp4l[7352.667]: assuming the grand master role ptp4l[7352.667]: assuming the grand master role ptp4l[7352.667]: assuming the grand master role ptp4l[7359.108]: port 2: new foreign master 70f8e7.fffe.d008ae-2 ptp4l[7363.108]: selected best master clock 00304a.fffe.5f00e1 ptp4l[7363.108]: running in a temporal vortex ptp4l[7363.108]: port 2: MASTER to UNCALIBRATED on RS_SLAVE ptp4l[7364.234]: port 2: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[7364.859]: rms 12469 max 24941 freq -96161 +/- 461 delay -1 +/- 0 ptp4l[7365.859]: rms 103 max 180 freq -95925 +/- 145 delay -1 +/- 0 ptp4l[7366.859]: rms 158 max 182 freq -95606 +/- 51 delay -3 +/- 0 ptp4l[7367.860]: rms 112 max 137 freq -95525 +/- 12 delay -3 +/- 0 ptp4l[7368.860]: rms 43 max 74 freq -95547 +/- 18 delay -3 +/- 0 ptp4l[7369.860]: rms 13 max 25 freq -95601 +/- 14 delay -3 +/- 0 ptp4l[7370.861]: rms 23 max 34 freq -95634 +/- 12 delay -3 +/- 0 ptp4l[7371.861]: rms 12 max 25 freq -95631 +/- 14 delay -3 +/- 0 ptp4l[7372.861]: rms 11 max 25 freq -95627 +/- 15 delay -3 +/- 0 ptp4l[7373.861]: rms 8 max 11 freq -95620 +/- 10 delay -3 +/- 0 ptp4l[7374.861]: rms 12 max 20 freq -95608 +/- 13 delay -3 +/- 0 ptp4l[7375.862]: rms 13 max 20 freq -95590 +/- 6 delay -3 +/- 0 ptp4l[7376.862]: rms 9 max 20 freq -95596 +/- 12 delay -3 +/- 0 ptp4l[7377.862]: rms 12 max 16 freq -95613 +/- 14 delay -3 +/- 0 ptp4l[7378.862]: rms 9 max 18 freq -95610 +/- 12 delay -1 +/- 0 ptp4l[7379.863]: rms 11 max 18 freq -95598 +/- 13 delay -1 +/- 0 ptp4l[7380.863]: rms 12 max 28 freq -95616 +/- 14 delay 0 +/- 0 ptp4l[7381.863]: rms 11 max 19 freq -95625 +/- 11 delay 0 +/- 0 ptp4l[7382.863]: rms 10 max 20 freq -95630 +/- 11 delay 1 +/- 0 ptp4l[7383.863]: rms 7 max 17 freq -95622 +/- 9 delay 0 +/- 0 ptp4l[7384.864]: rms 14 max 26 freq -95609 +/- 17 delay 0 +/- 0 ptp4l[7385.864]: rms 13 max 17 freq -95596 +/- 12 delay 0 +/- 0 ptp4l[7386.864]: rms 11 max 19 freq -95613 +/- 15 delay 0 +/- 0 ptp4l[7387.864]: rms 23 max 37 freq -95650 +/- 11 delay 0 +/- 0 ptp4l[7388.865]: rms 9 max 19 freq -95637 +/- 12 delay 0 +/- 0 ptp4l[7389.865]: rms 6 max 10 freq -95642 +/- 6 delay 0 +/- 0 ptp4l[7390.865]: rms 6 max 10 freq -95635 +/- 8 delay 0 +/- 0 ptp4l[7391.865]: rms 9 max 17 freq -95638 +/- 13 delay 0 +/- 0 ptp4l[7392.866]: rms 12 max 19 freq -95643 +/- 16 delay 0 +/- 0 ptp4l[7393.866]: rms 11 max 20 freq -95655 +/- 12 delay 1 +/- 0 ptp4l[7394.866]: rms 6 max 11 freq -95646 +/- 9 delay 1 +/- 0 ptp4l[7395.866]: rms 10 max 20 freq -95649 +/- 13 delay 1 +/- 0 ptp4l[7396.867]: rms 10 max 16 freq -95638 +/- 12 delay 1 +/- 0 ptp4l[7397.867]: rms 10 max 16 freq -95638 +/- 14 delay 1 +/- 0 ptp4l[7398.867]: rms 13 max 29 freq -95653 +/- 15 delay 1 +/- 0 ptp4l[7399.867]: rms 12 max 27 freq -95662 +/- 14 delay -1 +/- 0 ptp4l[7400.868]: rms 9 max 11 freq -95669 +/- 9 delay 1 +/- 0 ptp4l[7401.868]: rms 9 max 11 freq -95676 +/- 8 delay 1 +/- 0 ptp4l[7402.868]: rms 14 max 20 freq -95678 +/- 19 delay 1 +/- 0 ptp4l[7403.868]: rms 13 max 29 freq -95684 +/- 17 delay 1 +/- 0 ptp4l[7404.869]: rms 17 max 27 freq -95660 +/- 18 delay -1 +/- 0 ptp4l[7405.869]: rms 19 max 27 freq -95696 +/- 18 delay -1 +/- 0 ptp4l[7406.869]: rms 18 max 29 freq -95715 +/- 13 delay 1 +/- 0

but when I am running the phc2sys with the below mentioned command the offset is around 3 to 4 digit which is much larger and i think they are not synchronized.

sudo phc2sys -s eth0 --step_threshold 0.0002 --first_step_threshold 0.0002 -f /etc/linuxptp/phc2sys.conf -O 0 phc2sys[7366.414]: CLOCK_REALTIME phc offset -79030 s0 freq -178503 delay 770 phc2sys[7367.415]: CLOCK_REALTIME phc offset -79685 s2 freq -179158 delay 760 phc2sys[7368.416]: CLOCK_REALTIME phc offset -79949 s2 freq -259107 delay 760 phc2sys[7369.417]: CLOCK_REALTIME phc offset -192 s2 freq -203334 delay 770 phc2sys[7370.417]: CLOCK_REALTIME phc offset 23133 s2 freq -180067 delay 770 phc2sys[7371.417]: CLOCK_REALTIME phc offset 23347 s2 freq -172913 delay 760 phc2sys[7372.418]: CLOCK_REALTIME phc offset 15393 s2 freq -173863 delay 761 phc2sys[7373.418]: CLOCK_REALTIME phc offset 9048 s2 freq -175590 delay 770 phc2sys[7374.418]: CLOCK_REALTIME phc offset 4761 s2 freq -177163 delay 761 phc2sys[7375.418]: CLOCK_REALTIME phc offset 2562 s2 freq -177933 delay 760 phc2sys[7376.418]: CLOCK_REALTIME phc offset 830 s2 freq -178897 delay 770 phc2sys[7377.419]: CLOCK_REALTIME phc offset 454 s2 freq -179024 delay 760 phc2sys[7378.419]: CLOCK_REALTIME phc offset -371 s2 freq -179712 delay 760 phc2sys[7379.419]: CLOCK_REALTIME phc offset -830 s2 freq -180283 delay 760 phc2sys[7380.419]: CLOCK_REALTIME phc offset -965 s2 freq -180667 delay 761 phc2sys[7381.419]: CLOCK_REALTIME phc offset 47 s2 freq -179944 delay 760 phc2sys[7382.420]: CLOCK_REALTIME phc offset 211 s2 freq -179766 delay 770 phc2sys[7383.420]: CLOCK_REALTIME phc offset 970 s2 freq -178944 delay 770 phc2sys[7384.420]: CLOCK_REALTIME phc offset 675 s2 freq -178948 delay 770 phc2sys[7385.420]: CLOCK_REALTIME phc offset 102 s2 freq -179318 delay 760 phc2sys[7386.420]: CLOCK_REALTIME phc offset -151 s2 freq -179541 delay 760 phc2sys[7387.421]: CLOCK_REALTIME phc offset 41 s2 freq -179394 delay 770 phc2sys[7388.421]: CLOCK_REALTIME phc offset 936 s2 freq -178487 delay 760 phc2sys[7389.421]: CLOCK_REALTIME phc offset 989 s2 freq -178153 delay 770 phc2sys[7390.421]: CLOCK_REALTIME phc offset 165 s2 freq -178680 delay 760 phc2sys[7391.421]: CLOCK_REALTIME phc offset 119 s2 freq -178677 delay 770 phc2sys[7392.422]: CLOCK_REALTIME phc offset 673 s2 freq -178087 delay 770 phc2sys[7393.422]: CLOCK_REALTIME phc offset -434 s2 freq -178992 delay 770 phc2sys[7394.422]: CLOCK_REALTIME phc offset -547 s2 freq -179235 delay 760 phc2sys[7395.422]: CLOCK_REALTIME phc offset -975 s2 freq -179827 delay 770 phc2sys[7396.422]: CLOCK_REALTIME phc offset -1678 s2 freq -180823 delay 760

[vladimiroltean]

What board is this?

[Maku-chan]

This is a soc-e board.

[vladimiroltean]

Since this is not a board supported by OpenIL, I would recommend: https://sourceforge.net/p/linuxptp/mailman/linuxptp-users/

[Maku-chan]

Thanks a lot. Do i need to subscribe to post on this forum. As I cant find the option to start the thread.

[vladimiroltean]

As far as I know you don't need to subscribe, just send an email to linuxptp-users@lists.sourceforge.net

[Maku-chan]

ok thanks a lot.

[Maku-chan]

Hi, I just want to ask a general question that what is usually the reason if the ptp clock is synchronized with the master but the phc2sys is not able to synchronize the system clock. I am new to this topic so just want to get some information.

Thanks.

[vladimiroltean]

They are synchronized, why do you say they aren't. They are synchronized to within +/- 1.7 us accuracy. Probably if you had less jitter in the PHC readout delay (currently it varies between 760 and 770 ns), you'd also have better tracking of the reference. Can you try to set the frequency of all your CPUs to the maximum, see if that makes the delay constant?

for cpu in cpu0 cpu1 cpu2 cpu3; do cat /sys/bus/cpu/devices/${cpu}/cpufreq/scaling_max_freq > /sys/bus/cpu/devices/${cpu}/cpufreq/scaling_min_freq; done

[Maku-chan]

Thanks I will do that. The offset goes till maximum 1600 so what is the maximum value for the phc offset.

[vladimiroltean]

The offset goes till maximum 1600 so what is the maximum value for the phc offset.

What does this question mean?

[Maku-chan]

I mean what is the maximum phc offset?. I am asking just to know the reference that if the offset exceeds that limit then the nodes are not synchronized any more.

[vladimiroltean]

The maximum reasonably expectable offset will depend on the needs of the application and the capabilities of the hardware. As a baseline, synchronization using phc2sys will always be worse than synchronization using ptp4l and hardware timestamping, since phc2sys calculates the target clock offset by:

1. Reading the target clock
2. Surrounding the target clock readout between two readouts of the system clock
3. Creating an approximation of the system clock's value at the time that the target clock was read at step 1, by picking the middle point between the first system clock readout and the second system clock readout (taken from step 2).
4. Repeating steps 1-3 a few times (check man phc2sys | grep '-N phc-num') and picking the readout interval that took the least amount of time.

static int read_phc(clockid_t clkid, clockid_t sysclk, int readings,
            int64_t *offset, uint64_t *ts, int64_t *delay)
{
    struct timespec tdst1, tdst2, tsrc;
    int i;
    int64_t interval, best_interval = INT64_MAX;

    /* Pick the quickest clkid reading. */
    for (i = 0; i < readings; i++) {
        if (clock_gettime(sysclk, &tdst1) ||
                clock_gettime(clkid, &tsrc) ||
                clock_gettime(sysclk, &tdst2)) {
            pr_err("failed to read clock: %m");
            return 0;
        }

        interval = (tdst2.tv_sec - tdst1.tv_sec) * NS_PER_SEC +
            tdst2.tv_nsec - tdst1.tv_nsec;

        if (best_interval > interval) {
            best_interval = interval;
            *offset = (tdst1.tv_sec - tsrc.tv_sec) * NS_PER_SEC +
                tdst1.tv_nsec - tsrc.tv_nsec + interval / 2;
            *ts = tdst2.tv_sec * NS_PER_SEC + tdst2.tv_nsec;
        }
    }
    *delay = best_interval;

    return 1;
}

If the readout of your target clock takes a variable amount of time, this will confuse the rudimentary phc2sys algorithm and will create a variably sized interval which will mean that the offset is more imprecise. Hence my suggestion to try maxing out the CPU frequency - the assumption being that you're using dynamic frequency scaling, which turns the CPU clocks down when there is not high enough load on them to justify a high frequency.

There are other tricks that certain kernel drivers can use (SYSOFF_PRECISE, SYSOFF_EXTENDED, SYSOFF_BASIC) which can improve the approximation accuracy. You need to check with your silicon vendor for the availability of these features in their drivers.