Re: [Linuxptp-users] SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT

[Richard C. <ric...@gm...>]

On Thu, Apr 02, 2015 at 03:38:38PM +0000, Daniel Le wrote:
> [DL] The FPGA has its own clock and a proprietary slewing mechanism to sync to a time source. It does not use phc2sys
>          because my embedded system doesn't have 3.x Linux kernel.
> 
> [DL] In the case of PTP time source, the FPGA engine on the NIC periodically reads the kernel system time
>          (do_gettimeofday) in order to step/slew to the system time which is synchronized to PTP grandmaster time.

(IOW, software time stamping)
 
> [DL] The ptp4l program is run with -S option, however, for example when sending/receiving packets via IPv4 transport
>          in udp_send() and udp_recv(), a timestamping pipe is used to get the FPGA hardware timestamps of the packets,
>          instead of the functions sendto() and sk_receive().

(IOW, hardware time stamping)

This design seems wrong to me.  Why not let the FPGA have it own
clock, and then synchronize the Linux system time to it?  That is how
all the other devices do it.

In any case, you have some elaborate custom kernel and ptp4l
modifications.  I really can't help you with those, sorry.

> [DL] Could you further elaborate this clockcheck_sample functionality (such as uncorrected frequency)?

Please take a look at the code.  It is not all that complicated.
 
>          Is my understating of the following correct?
>          - The synchronized clock is the PTP clock and is maintained by PTP packet TX/RX timestamps per 1588 standard.

Yes.

>          - The system monotonic clock (CLOCK_MONOTONIC) is the Linux kernel system clock.

No. See 'man 3 clock_gettime'.
 
> [DL] What is the threshold to determine that clock jumped forward/backward too much?

The code does this:

    Check the sanity of the synchronized clock by comparing its uncorrected
    frequency with the system monotonic clock. When the measured frequency
    offset is larger than the value of the sanity_freq_limit option (20% by
    default), a warning message will be printed and the servo will be reset.
    Setting the option to zero disables the check.
    
    This is useful to detect when the clock is broken or adjusted by another
    program.
 
> [DL]Upon a system boot-up or restart, how does PTP slave clock sets the system clock initially? Is CLOCK_REALTIME involved?

First of all, the ptp4l program will not start at boot-up or restart
unless you arrange for that to happen.  Secondly, the ptp4l program
sets its target clock (either the PHC in the case of HW time stamping,
or CLOCK_REALTIME for SW time stamping) to match that of the remote
master, according to the 'first_step_threshold' configuration option.

HTH,
Richard