Re: [Linuxptp-users] sanity_freq_limit

[Daniel Le <dan...@ex...>]

My understanding is that clkid 0 is CLOCK_REALTIME, which is the system time, based on the definitions in Linux time.h. In the following, the master offset  remains high (497918992) after the system clock is stepped and after the PTP enters Slave mode. Does it mean that the system clock is not actually not stepped?

ptp4l[841551.567]: master offset  497923672 s1 freq  -11601 path delay      1182
ptp4l[841551.567]: Step system clock...
ptp4l[841551.567]: clockadj_set_freq: clkid=0 freq= +11601
ptp4l[841551.567]: clockadj_step: clkid=0 step= 497923672
ptp4l[841552.567]: master offset  497921336 s2 freq +50278454 path delay      1182
ptp4l[841552.567]: clockadj_set_freq: clkid=0 freq= +21546
ptp4l[841552.567]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[841553.517]: master offset  497918992 s2 freq +50776139 path delay      1222
ptp4l[841553.517]: clockadj_set_freq: clkid=0 freq= +23861
ptp4l[841554.466]: master offset  418089084 s2 freq +43211237 path delay  24354298
ptp4l[841554.466]: clockadj_set_freq: clkid=0 freq= -11237

PHC is not used in my system. I have a proprietary NIC FPGA-based MAC driver which has its own hardware clock, and in this scheme, synchronizes to the Linux system clock that in turn is synchronized to PTP Grandmaster via software timestamping mechanism. The timestamps of PTP packets are provided by the FPGA MAC driver may cause problem. It seems that the system clock fails to be stepped.

Thanks!
Daniel

-----Original Message-----
From: Richard Cochran [mailto:ric...@gm...] 
Sent: Friday, June 19, 2015 3:09 PM
To: Daniel Le
Cc: 'Miroslav Lichvar'; Lin...@li...
Subject: Re: [Linuxptp-users] sanity_freq_limit

On Fri, Jun 19, 2015 at 06:12:53PM +0000, Daniel Le wrote:
> Thanks Miroslav and Jake.
> 
> I'm running linuxptp-1.4 and Linux kernel 2.6.35.7 with customization. My older linuxptp version has pi_f_offset_const instead of first_step_threshold, which I didn't alter.
> 
> I added debugging code to confirm that the step takes place, however unclear how things are afterward.

The issue is probably a bug in your backport of the PHC code, or in the backported MAC driver.

Thanks,
Richard