Re: [Linuxptp-users] Hardware PTP clock synchronization

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

On Sat, Aug 03, 2013 at 11:14:43AM +0300, Гаврилов Александр wrote:
> 
> ptp4l.conf:
> 
> #tx_timestamp_retries   1
> tx_timestamp_timeout    1000

Good ...

> [root@lab32 linuxptp-1.3]# ptp4l -f "ptp4l.conf" -i p16p1 -m
> ptp4l[2946.559]: selected /dev/ptp0 as PTP clock
> ptp4l[2946.573]: port 1: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[2946.573]: port 0: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[2947.895]: port 1: new foreign master ece555.fffe.2de639-2
> ptp4l[2951.885]: selected best master clock ece555.fffe.2de639
> ptp4l[2951.885]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
> ptp4l[2955.029]: poll tx timestamp timeout
                   ^^^^^^^^^^^^^^^^^^^^^^^^^
> ptp4l[2955.029]: port 1: send delay request failed

Hm, before you had:

   ptp4l[3709.401]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
   ptp4l[3710.039]: recvmsg tx timestamp failed: Resource temporarily unavailable
   ptp4l[3710.039]: port 1: send delay request failed

   ptp4l[733.452]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
   ptp4l[734.458]: recvmsg tx timestamp failed: Resource temporarily unavailable
   ptp4l[734.458]: port 1: send peer delay request failed

So I suspect that you were running a version prior to 1.2, can that be
true?

In any case, the hardware is clearly missing time stamps. You can just
ignore this error. What happens when you let the program continue?
Does every delay request throw an error, or do some succeed?

If only some of the messages fail, then you can just set the
fault_reset_interval config option to "ASAP" to avoid the long fault
time.

HTH,
Richard