Re: [Linuxptp-users] Question regarding ptp4l

[Nemo C. <nem...@gm...>]

 I found answers for first few questions,

>In two hours of test, I see 8 times tx_timestamp timeout issue for path delay. 
>
>ptp4l[5818.284]: timed out while polling for tx timestamp
>ptp4l[5818.284]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
>ptp4l[5818.284]: port 1: send peer delay request failed
>ptp4l[5818.284]: port 1: SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
>
>And when this happens, ptp4l stops synchronizing the local time for almost 14 to 15 sec. Only phc2sys is active. I am not sure if this is related to the jump I see. 
>1. Can you please explain if this is expected?
>2. Why would ptp4l stop if pdelay request send fails? 
>3. Why can't ptp4l keep receiving the SYNC/FollowUp and use the last known path delay for synchronizing the local clock?this behavior happens because of the below parameter not being used and left it to its default which is 4 (16 seconds)
       fault_reset_interval
              The  time  in  seconds  between the detection of a port's fault and the fault being
              reset. This value is expressed as a power of two. Setting this value to -128 or  to
              the  special  key word "ASAP" will let the fault be reset immediately.  The default
              is 4 (16 seconds).
>The other issue I found was, the "cumulativeScaledRateOffset" received in the FollowUp TLV has a spike continuously for a while, this is exactly when the slave jumped to 32 us offset. I have attached the snipped showing this.
>
>4. Could you please tell me why this spike would happen continously?
>5. I also see such spikes elsewhere, but not as 5 consecutive times as shown in the above. Would this contribute to the jump?

I am still trying to find answer for these questions.



    On Wednesday, 12 October, 2022 at 04:15:58 pm GMT-4, vignesh shanmugam via Linuxptp-users <lin...@li...> wrote:  
 
  By increasing the tx_timestamp_timeout to 100ms., I confirmed that the timeout issue is fixed.

But I still see the jumps of around 100 usec now. Again, it is correlating with jumps in cSRO (Cumulative Scaled Rate Ratio.)

Any pointers are appreciated.


    On Wednesday, 12 October, 2022 at 09:07:34 am GMT-4, vignesh shanmugam <vig...@ya...> wrote:  
 
  Does anyone have any inputs for this behavior?
In two hours of test, I see 8 times tx_timestamp timeout issue for path delay. 

ptp4l[5818.284]: timed out while polling for tx timestamp
ptp4l[5818.284]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[5818.284]: port 1: send peer delay request failed
ptp4l[5818.284]: port 1: SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)


And when this happens, ptp4l stops synchronizing the local time for almost 14 to 15 sec. Only phc2sys is active. I am not sure if this is related to the jump I see. 
1. Can you please explain if this is expected?
2. Why would ptp4l stop if pdelay request send fails? 
3. Why can't ptp4l keep receiving the SYNC/FollowUp and use the last known path delay for synchronizing the local clock?

The other issue I found was, the "cumulativeScaledRateOffset" received in the FollowUp TLV has a spike continuously for a while, this is exactly when the slave jumped to 32 us offset. I have attached the snipped showing this.

4. Could you please tell me why this spike would happen continously?
5. I also see such spikes elsewhere, but not as 5 consecutive times as shown in the above. Would this contribute to the jump?

Thanks!



    On Friday, 7 October, 2022 at 10:38:40 am GMT-4, vignesh shanmugam <vig...@ya...> wrote:  
 
  Hi Richard,
This is Intel CPU, has support for HW timestamping in the MAC.

I also found few more issues when analyzing the logs and pcap,

In two hours of test, I see 8 times tx_timestamp timeout issue for path delay. 

ptp4l[5818.284]: timed out while polling for tx timestamp
ptp4l[5818.284]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[5818.284]: port 1: send peer delay request failed
ptp4l[5818.284]: port 1: SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)


And when this happens, ptp4l stops synchronizing the local time for almost 14 to 15 sec. Only phc2sys is active. I am not sure if this is related to the jump I see. 
1. Can you please explain if this is expected?
2. Why would ptp4l stop if pdelay request send fails? 
3. Why can't ptp4l keep receiving the SYNC/FollowUp and use the last known path delay for synchronizing the local clock?

The other issue I found was, the "cumulativeScaledRateOffset" received in the FollowUp TLV has a spike continuously for a while, this is exactly when the slave jumped to 32 us offset. I have shown the snippet below.




4. Could you please tell me why this spike would happen continously?
5. I also see such spikes elsewhere, but not as 5 consecutive times as shown in the above. Would this contribute to the jump?

Thanks!



    On Friday, 7 October, 2022 at 10:08:03 am GMT-4, Richard Cochran <ric...@gm...> wrote:  
 
 On Thu, Oct 06, 2022 at 06:44:29PM +0000, vignesh shanmugam via Linuxptp-users wrote:
> Can you point me some clues what could cause this?

What is the MAC?  Does it use software time stamping?

Thanks,
Richard
      _______________________________________________
Linuxptp-users mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxptp-users