linuxptp-users

[Linuxptp-users] sanity_freq_limit

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

Hello,

I have a couple of questions about the frequency limit. How much may it be reasonably increased from the default of 200000000 (20%)? And this parameter is only configurable via the config file. Is that correct?

Thanks,
Daniel

Re: [Linuxptp-users] sanity_freq_limit

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

Additionally, in slave clock operation and software time stamping mode, how (and where in the code) ptp4l can be forced to step the system clock with the time it first receives from a grandmaster clock?

/Daniel

From: Daniel Le 
Sent: Wednesday, June 17, 2015 6:36 PM
To: Lin...@li...
Subject: [Linuxptp-users] sanity_freq_limit

Hello,

I have a couple of questions about the frequency limit. How much may it be reasonably increased from the default of 200000000 (20%)? And this parameter is only configurable via the config file. Is that correct?

Thanks,
Daniel

Re: [Linuxptp-users] sanity_freq_limit

[Miroslav L. <mli...@re...>]

On Thu, Jun 18, 2015 at 01:58:13AM +0000, Daniel Le wrote:
> Additionally, in slave clock operation and software time stamping mode, how (and where in the code) ptp4l can be forced to step the system clock with the time it first receives from a grandmaster clock?

ptp4l should do that by default, it's set by the first_step_threshold
option.

> I have a couple of questions about the frequency limit. How much may it be reasonably increased from the default of 200000000 (20%)? And this parameter is only configurable via the config file. Is that correct?

Why do you need to increase it? 20% is a safe value for SW
timestamping. If you see clockcheck warning messages, it's probably a
bug in the kernel/driver. With HW timestamping a limit of a few
hundreds of ppm should be enough to cover the frequency offset between
a typical system clock and PTP clock.

-- 
Miroslav Lichvar

Re: [Linuxptp-users] sanity_freq_limit

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

> On Jun 18, 2015, at 2:58 AM, Miroslav Lichvar <mli...@re...> wrote:
> 
>> On Thu, Jun 18, 2015 at 01:58:13AM +0000, Daniel Le wrote:
>> Additionally, in slave clock operation and software time stamping mode, how (and where in the code) ptp4l can be forced to step the system clock with the time it first receives from a grandmaster clock?
> 
> ptp4l should do that by default, it's set by the first_step_threshold
> option.

Somehow when my system clock is initially (for example after a reboot) off the GM time by a couple of minutes, the master offset is huge and ptp4l takes hours to converge.

Thanks.

> 
>> I have a couple of questions about the frequency limit. How much may it be reasonably increased from the default of 200000000 (20%)? And this parameter is only configurable via the config file. Is that correct?
> 
> Why do you need to increase it? 20% is a safe value for SW
> timestamping. If you see clockcheck warning messages, it's probably a
> bug in the kernel/driver. With HW timestamping a limit of a few
> hundreds of ppm should be enough to cover the frequency offset between
> a typical system clock and PTP clock.
> 
> -- 
> Miroslav Lichvar

Re: [Linuxptp-users] sanity_freq_limit

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

Does ptp4l step only once (assuming the default first_step_threshold of 20 microseconds is met) no matter how master offsets vary afterward?

Daniel

-----Original Message-----
From: Daniel Le 
Sent: Friday, June 19, 2015 4:10 PM
To: 'Richard Cochran'
Cc: Lin...@li...
Subject: Re: [Linuxptp-users] sanity_freq_limit

"...or that the change in time is not reflected in the subsequent time stamps". This is a good pointer for debugging. The system clock may have been stepped, but the FPGA hardware clock is not stepped and continues to provide the timestamps from its un-stepped clock.

Much appreciate it.
Daniel

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

On Fri, Jun 19, 2015 at 07:43:01PM +0000, Daniel Le wrote:
> 
> 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.

Okay, so you have a special custom setup.  I cannot really guess what is wrong, but it does appear that whatever clock you are using is failing to jump, or that the change in time is not reflected in the subsequent time stamps.

Thanks,
Richard

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

Re: [Linuxptp-users] sanity_freq_limit

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

On Mon, Jun 22, 2015 at 03:35:19AM +0000, Daniel Le wrote:
> Does ptp4l step only once (assuming the default first_step_threshold of 20 microseconds is met) no matter how master offsets vary afterward?

No, you can step a second and subsequent times by setting
'step_threshold' to a non-zero value.

HTH,
Richard

Re: [Linuxptp-users] sanity_freq_limit

[Miroslav L. <mli...@re...>]

On Thu, Jun 18, 2015 at 07:18:53AM +0000, Daniel Le wrote:
> > On Jun 18, 2015, at 2:58 AM, Miroslav Lichvar <mli...@re...> wrote:
> > 
> >> On Thu, Jun 18, 2015 at 01:58:13AM +0000, Daniel Le wrote:
> >> Additionally, in slave clock operation and software time stamping mode, how (and where in the code) ptp4l can be forced to step the system clock with the time it first receives from a grandmaster clock?
> > 
> > ptp4l should do that by default, it's set by the first_step_threshold
> > option.
> 
> Somehow when my system clock is initially (for example after a reboot) off the GM time by a couple of minutes, the master offset is huge and ptp4l takes hours to converge.

That's odd. Can you post your ptp4l config and log when it starts?

-- 
Miroslav Lichvar

Re: [Linuxptp-users] sanity_freq_limit

[Keller, J. E <jac...@in...>]

On Wed, 2015-06-17 at 22:35 +0000, Daniel Le wrote:
> Hello,
> 

Hi,

> I have a couple of questions about the frequency limit. How much may 
> it be reasonably increased from the default of 200000000 (20%)? And 
> this parameter is only configurable via the config file. Is that 
> correct?
>  

The sanity_freq_limit shouldn't really be increased beyond 20%.
Especially most hardware doesn't really support larger frequency
offsets. Some might, but it's not really necessary.


As for the other issue with clock jump, make sure your
first_step_threshold is low enough that it will perform a jump. It
should be by default but if you wouldn't mind including your config
here, and the resulting output of ptp4l as suggested by Miroslav.

Regards,
Jake

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

Re: [Linuxptp-users] sanity_freq_limit

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

Below is my ptp4l config file.

$cat ptp4l.conf
[global]
domainNumber                   0
slaveOnly                               1
priority1                                  128
priority2                                  128
clockClass                               248
clockAccuracy                        254
offsetScaledLogVariance  65535
freq_est_interval                 1
time_stamping                      software
tx_timestamp_timeout     1
logging_level                         6
verbose                                    0
use_syslog                              1
summary_interval               0
[eth2]
delay_mechanism                  E2E
network_transport                UDPv4
delayAsymmetry                    0
logAnnounceInterval            1
logSyncInterval                        0
logMinDelayReqInterval      0
logMinPdelayReqInterval    0
announceReceiptTimeout   3
syncReceiptTimeout              0
delay_filter                                moving_average
delay_filter_length                10
path_trace_enabled              0
fault_reset_interval              4

And the log messages at start in "good case". I didn't save the log where my system time was initially off a few minutes, though I remember the master offsets were above 200000000. I'll need to reproduce such condition in order to capture the exact log messages.

ptp4l[792695.130]: port 1: get_ts_info not supported
ptp4l[792695.131]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[792695.131]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[792697.130]: port 1: new foreign master 00b0ae.fffe.02d103-1
ptp4l[792701.130]: selected best master clock 00b0ae.fffe.02d103
ptp4l[792701.130]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[792701.991]: port 1: minimum delay request interval 2^-7
ptp4l[792703.068]: master offset   -1555032 s0 freq  -13556 path delay     -5078
ptp4l[792704.068]: master offset   -1563606 s0 freq  -13556 path delay      1196
ptp4l[792705.068]: master offset   -1565962 s0 freq  -13556 path delay      1212
ptp4l[792706.068]: master offset   -1568258 s0 freq  -13556 path delay      1204
ptp4l[792707.068]: master offset   -1570542 s0 freq  -13556 path delay      1184
ptp4l[792708.068]: master offset   -1553450 s0 freq  -13556 path delay     -5284
ptp4l[792709.068]: master offset   -1562224 s0 freq  -13556 path delay      1186
ptp4l[792710.068]: master offset   -1564536 s0 freq  -13556 path delay      1198
ptp4l[792711.068]: master offset   -1566872 s0 freq  -13556 path delay      1194
ptp4l[792712.068]: master offset   -1569158 s0 freq  -13556 path delay      1180
ptp4l[792713.068]: master offset   -1571482 s0 freq  -13556 path delay      1196
ptp4l[792714.068]: master offset   -1554204 s0 freq  -13556 path delay     -5330
ptp4l[792715.068]: master offset   -1563042 s0 freq  -13556 path delay      1204
ptp4l[792716.068]: master offset   -1565384 s0 freq  -13556 path delay      1210
ptp4l[792717.068]: master offset   -1567668 s0 freq  -13556 path delay      1194
ptp4l[792718.068]: master offset   -1569978 s0 freq  -13556 path delay      1200
ptp4l[792719.068]: master offset   -1554292 s1 freq  -13510 path delay     -4826
ptp4l[792720.068]: master offset   -1556592 s2 freq -170726 path delay     -4826
ptp4l[792720.068]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[792721.068]: master offset   -1564970 s2 freq -173128 path delay      1212
ptp4l[792722.068]: master offset   -1567220 s2 freq -174921 path delay      1162
ptp4l[792723.068]: master offset   -1569548 s2 freq -176723 path delay      1186
ptp4l[792724.068]: master offset   -1571854 s2 freq -178525 path delay      1188
ptp4l[792725.068]: master offset    -523684 s2 freq  -74232 path delay   -348970

/Daniel

-----Original Message-----
From: Miroslav Lichvar [mailto:mli...@re...] 
Sent: Thursday, June 18, 2015 4:20 AM
To: Daniel Le
Cc: Lin...@li...
Subject: Re: [Linuxptp-users] sanity_freq_limit

On Thu, Jun 18, 2015 at 07:18:53AM +0000, Daniel Le wrote:
> > On Jun 18, 2015, at 2:58 AM, Miroslav Lichvar <mli...@re...> wrote:
> > 
> >> On Thu, Jun 18, 2015 at 01:58:13AM +0000, Daniel Le wrote:
> >> Additionally, in slave clock operation and software time stamping mode, how (and where in the code) ptp4l can be forced to step the system clock with the time it first receives from a grandmaster clock?
> > 
> > ptp4l should do that by default, it's set by the 
> > first_step_threshold option.
> 
> Somehow when my system clock is initially (for example after a reboot) off the GM time by a couple of minutes, the master offset is huge and ptp4l takes hours to converge.

That's odd. Can you post your ptp4l config and log when it starts?

--
Miroslav Lichvar

Re: [Linuxptp-users] sanity_freq_limit

[Miroslav L. <mli...@re...>]

On Fri, Jun 19, 2015 at 04:15:20AM +0000, Daniel Le wrote:
> And the log messages at start in "good case". I didn't save the log where my system time was initially off a few minutes, though I remember the master offsets were above 200000000. I'll need to reproduce such condition in order to capture the exact log messages.

Your config looks good to me. The default value of first_step_threshold
is 20 microseconds, so in your test with ~1.5 millisecond initial
offset it should have stepped.

> ptp4l[792717.068]: master offset   -1567668 s0 freq  -13556 path delay      1194
> ptp4l[792718.068]: master offset   -1569978 s0 freq  -13556 path delay      1200
> ptp4l[792719.068]: master offset   -1554292 s1 freq  -13510 path delay     -4826
> ptp4l[792720.068]: master offset   -1556592 s2 freq -170726 path delay     -4826

But as we can see, it didn't step for some reason. Here is a test I
did using the same config file and it does step for me.

ptp4l[8898442.271]: master offset   -1093869 s0 freq   -1946 path delay     54642
ptp4l[8898443.271]: master offset   -1094931 s0 freq   -1946 path delay     54642
ptp4l[8898444.271]: master offset   -1102224 s1 freq   -6078 path delay     55329
ptp4l[8898445.271]: master offset       9378 s2 freq   -5131 path delay     55329

What linuxptp and kernel versions are you using?

-- 
Miroslav Lichvar

Re: [Linuxptp-users] sanity_freq_limit

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

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.

(1) On one slave clock device, where its system time is off by 1 hour and 35 minutes behind.

Jun 19 14:31:24 (none) user.warn ptp4l: [16.960] port 1: get_ts_info not supported
Jun 19 14:31:24 (none) user.notice ptp4l: [16.961] port 1: INITIALIZING to LISTENING on INITIALIZE
Jun 19 14:31:24 (none) user.notice ptp4l: [16.961] port 0: INITIALIZING to LISTENING on INITIALIZE
Jun 19 14:31:26 (none) user.notice ptp4l: [18.886] port 1: new foreign master 00b0ae.fffe.02d104-1
Jun 19 14:31:30 (none) user.notice ptp4l: [22.886] selected best master clock 00b0ae.fffe.02d104
Jun 19 14:31:30 (none) user.notice ptp4l: [22.886] port 1: LISTENING to UNCALIBRATED on RS_SLAVE
Jun 19 14:31:30 (none) user.notice ptp4l: [23.118] port 1: minimum delay request interval 2^-7
Jun 19 14:31:33 (none) user.info ptp4l: [25.823] master offset -5479246314194 s0 freq      +0 path delay      3492
Jun 19 14:31:34 (none) user.info ptp4l: [26.823] master offset -5479246315624 s0 freq      +0 path delay      3550
Jun 19 14:31:35 (none) user.info ptp4l: [27.823] master offset -5479246316774 s0 freq      +0 path delay      3512
Jun 19 14:31:36 (none) user.info ptp4l: [28.822] master offset -5479246318180 s0 freq      +0 path delay      3542
Jun 19 14:31:37 (none) user.info ptp4l: [29.822] master offset -5479246319340 s0 freq      +0 path delay      3486
Jun 19 14:31:38 (none) user.info ptp4l: [30.822] master offset -5479247196552 s0 freq      +0 path delay    295486
Jun 19 14:31:39 (none) user.info ptp4l: [31.822] master offset -5479246905902 s0 freq      +0 path delay      3520
Jun 19 14:31:40 (none) user.info ptp4l: [32.822] master offset -5479246907136 s0 freq      +0 path delay      3506
Jun 19 14:31:41 (none) user.info ptp4l: [33.822] master offset -5479246908448 s0 freq      +0 path delay      3538
Jun 19 14:31:42 (none) user.info ptp4l: [34.822] master offset -5479246909704 s0 freq      +0 path delay      3514
Jun 19 14:31:43 (none) user.info ptp4l: [35.822] master offset -5479247782844 s0 freq      +0 path delay    294126
Jun 19 14:31:44 (none) user.info ptp4l: [36.822] master offset -5479247493484 s0 freq      +0 path delay      3518
Jun 19 14:31:45 (none) user.info ptp4l: [37.821] master offset -5479247494752 s0 freq      +0 path delay      3538
Jun 19 14:31:46 (none) user.info ptp4l: [38.821] master offset -5479247496104 s0 freq      +0 path delay      3546
Jun 19 14:31:47 (none) user.info ptp4l: [39.821] master offset -5479247497316 s0 freq      +0 path delay      3514
Jun 19 14:31:48 (none) user.info ptp4l: [40.821] master offset -5479247498658 s0 freq      +0 path delay      3540
Jun 19 14:31:49 (none) user.info ptp4l: [41.821] master offset -5479248375064 s1 freq -128819 path delay    295242
Jun 19 14:31:49 (none) user.info ptp4l: [41.821] Step system clock...
Jun 19 14:31:49 (none) user.info ptp4l: [41.821] clockadj_set_freq: clkid=0 freq= +28819
Jun 19 14:31:49 (none) user.info ptp4l: [41.821] clockadj_step: clkid=0 step=5479248375064
Jun 19 14:31:50 (none) user.info ptp4l: [42.821] master offset -5479248376376 s2 freq -100000000 path delay    295242
Jun 19 14:31:50 (none) user.info ptp4l: [42.821] clockadj_set_freq: clkid=0 freq=     +0
Jun 19 14:31:50 (none) user.notice ptp4l: [42.821] port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
Jun 19 14:31:51 (none) user.info ptp4l: [43.921] master offset -5479248085876 s2 freq -100000000 path delay      3494
Jun 19 14:31:51 (none) user.info ptp4l: [43.921] clockadj_set_freq: clkid=0 freq=     +0
Jun 19 14:31:52 (none) user.info ptp4l: [45.021] master offset -5479248087212 s2 freq -100000000 path delay      3518
Jun 19 14:31:52 (none) user.info ptp4l: [45.021] clockadj_set_freq: clkid=0 freq=     +0
Jun 19 14:31:53 (none) user.info ptp4l: [46.121] master offset -5479248088444 s2 freq -100000000 path delay      3502
Jun 19 14:31:53 (none) user.info ptp4l: [46.121] clockadj_set_freq: clkid=0 freq=     +0
Jun 19 14:31:55 (none) user.info ptp4l: [47.221] master offset -5479200033936 s2 freq -100000000 path delay -14414590
Jun 19 14:31:55 (none) user.info ptp4l: [47.221] clockadj_set_freq: clkid=0 freq=     +0
Jun 19 14:31:56 (none) user.info ptp4l: [48.320] master offset -5478966697088 s2 freq -100000000 path delay -81086222
Jun 19 14:31:56 (none) user.info ptp4l: [48.321] clockadj_set_freq: clkid=0 freq=     +0
Jun 19 14:31:57 (none) user.info ptp4l: [49.420] master offset -5478802913984 s2 freq -100000000 path delay -78204170
Jun 19 14:31:57 (none) user.info ptp4l: [49.420] clockadj_set_freq: clkid=0 freq=     +0
Jun 19 14:31:58 (none) user.info ptp4l: [50.520] master offset -5478862522102 s2 freq -100000000 path delay  -6196760
Jun 19 14:31:58 (none) user.info ptp4l: [50.520] clockadj_set_freq: clkid=0 freq=     +0
Jun 19 14:31:59 (none) user.info ptp4l: [51.620] master offset -5478868723712 s2 freq -100000000 path delay      3538
Jun 19 14:31:59 (none) user.info ptp4l: [51.620] clockadj_set_freq: clkid=0 freq=     +0
Jun 19 14:32:00 (none) user.info ptp4l: [52.720] master offset -5478868724940 s2 freq -100000000 path delay      3518
Jun 19 14:32:00 (none) user.info ptp4l: [52.720] clockadj_set_freq: clkid=0 freq=     +0
Jun 19 14:32:01 (none) user.info ptp4l: [53.820] master offset -5478710523928 s2 freq -100000000 path delay -50266518
Jun 19 14:32:01 (none) user.info ptp4l: [53.820] clockadj_set_freq: clkid=0 freq=     +0
Jun 19 14:32:02 (none) user.info ptp4l: [54.920] master offset -5478513781464 s2 freq -100000000 path delay -80343798
Jun 19 14:32:02 (none) user.info ptp4l: [54.920] clockadj_set_freq: clkid=0 freq=     +0

(2) On another slave clock device, where its system time is almost same as the correct time.

sbin #ptp4l -m -q -i eth3 -s -S
ptp4l[841529.107]: clockadj_set_freq: clkid=0 freq= -25768
ptp4l[841529.107]: port 1: get_ts_info not supported
ptp4l[841529.108]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[841529.108]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[841529.628]: port 1: new foreign master 00b0ae.fffe.02d103-1
ptp4l[841533.629]: selected best master clock 00b0ae.fffe.02d103
ptp4l[841533.629]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[841533.709]: port 1: minimum delay request interval 2^-7
ptp4l[841535.566]: master offset  496921588 s0 freq  -74232 path delay      1186
ptp4l[841536.566]: master offset  496919220 s0 freq  -74232 path delay      1214
ptp4l[841537.566]: master offset  497436366 s0 freq  -74232 path delay   -171964
ptp4l[841538.567]: master offset  497260880 s0 freq  -74232 path delay      1186
ptp4l[841539.567]: master offset  497258554 s0 freq  -74232 path delay      1212
ptp4l[841540.567]: master offset  497256258 s0 freq  -74232 path delay      1204
ptp4l[841541.567]: master offset  497253920 s0 freq  -74232 path delay      1202
ptp4l[841542.567]: master offset  497251618 s0 freq  -74232 path delay      1200
ptp4l[841543.567]: master offset  497768934 s0 freq  -74232 path delay   -172016
ptp4l[841544.567]: master offset  497593414 s0 freq  -74232 path delay      1196
ptp4l[841545.567]: master offset  497591074 s0 freq  -74232 path delay      1204
ptp4l[841546.567]: master offset  497588774 s0 freq  -74232 path delay      1200
ptp4l[841547.567]: master offset  497586420 s0 freq  -74232 path delay      1218
ptp4l[841548.567]: master offset  498103830 s0 freq  -74232 path delay   -172036
ptp4l[841549.567]: master offset  497928290 s0 freq  -74232 path delay      1204
ptp4l[841550.567]: master offset  497925954 s0 freq  -74232 path delay      1204
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
ptp4l[841555.423]: master offset  403879084 s2 freq +42194116 path delay  12854794
ptp4l[841555.423]: clockadj_set_freq: clkid=0 freq=  +5884
ptp4l[841556.381]: master offset  416730386 s2 freq +43895976 path delay      1188
ptp4l[841556.381]: clockadj_set_freq: clkid=0 freq=  +4024
ptp4l[841557.337]: master offset  416728028 s2 freq +44312469 path delay      1206
ptp4l[841557.337]: clockadj_set_freq: clkid=0 freq= -12469
ptp4l[841558.293]: master offset  416725754 s2 freq +44728967 path delay      1180
ptp4l[841558.293]: clockadj_set_freq: clkid=0 freq= -28967
ptp4l[841559.248]: master offset  416723444 s2 freq +45145459 path delay      1186
ptp4l[841559.248]: clockadj_set_freq: clkid=0 freq= -45459
ptp4l[841560.203]: master offset  416721094 s2 freq +45561946 path delay      1200
ptp4l[841560.203]: clockadj_set_freq: clkid=0 freq= +38054
ptp4l[841561.157]: master offset  389860090 s2 freq +43265705 path delay   7781368
ptp4l[841561.157]: clockadj_set_freq: clkid=0 freq= +34295
ptp4l[841562.114]: master offset  186064456 s2 freq +23072206 path delay  68717870
ptp4l[841562.114]: clockadj_set_freq: clkid=0 freq= +27794
ptp4l[841563.091]: master offset   43535162 s2 freq +8862812 path delay  68388060
ptp4l[841563.091]: clockadj_set_freq: clkid=0 freq= +37188

I also added code to verify if the servo reset occurs when the calculated offset is higher than default sanity_freq_limit.

Jun 18 20:08:59 (none) user.warn ptp4l: [521.858] clockcheck: clock jumped backward or running slower than expected!
Jun 18 20:08:59 (none) user.info ptp4l: [521.858] MAX-foffset=-206031909 flimit=200000000
Jun 18 20:08:59 (none) user.info ptp4l: [521.858] pi_reset .....................
Jun 18 20:08:59 (none) user.warn ptp4l: [521.966] clockcheck: clock jumped forward or running faster than expected!
Jun 18 20:08:59 (none) user.info ptp4l: [521.966] MIN-foffset=+267792097 flimit=200000000
Jun 18 20:08:59 (none) user.info ptp4l: [521.966] pi_reset .....................
Jun 18 20:08:59 (none) user.info ptp4l: [522.070] master offset    1015988 s0 freq +108331 path delay      3518
Jun 18 20:09:00 (none) user.info ptp4l: [523.070] master offset    1014652 s0 freq +108331 path delay      3542
Jun 18 20:09:01 (none) user.info ptp4l: [524.070] master offset    1013376 s0 freq +108331 path delay      3538
Jun 18 20:09:02 (none) user.info ptp4l: [525.070] master offset     924804 s0 freq +108331 path delay     32622
Jun 18 20:09:03 (none) user.info ptp4l: [526.070] master offset     952644 s0 freq +108331 path delay      3506
Jun 18 20:09:04 (none) user.info ptp4l: [527.070] master offset     951354 s0 freq +108331 path delay      3512

-----Original Message-----
From: Miroslav Lichvar [mailto:mli...@re...] 
Sent: Friday, June 19, 2015 4:04 AM
To: Daniel Le
Cc: Lin...@li...
Subject: Re: [Linuxptp-users] sanity_freq_limit

On Fri, Jun 19, 2015 at 04:15:20AM +0000, Daniel Le wrote:
> And the log messages at start in "good case". I didn't save the log where my system time was initially off a few minutes, though I remember the master offsets were above 200000000. I'll need to reproduce such condition in order to capture the exact log messages.

Your config looks good to me. The default value of first_step_threshold is 20 microseconds, so in your test with ~1.5 millisecond initial offset it should have stepped.

> ptp4l[792717.068]: master offset   -1567668 s0 freq  -13556 path delay      1194
> ptp4l[792718.068]: master offset   -1569978 s0 freq  -13556 path delay      1200
> ptp4l[792719.068]: master offset   -1554292 s1 freq  -13510 path delay     -4826
> ptp4l[792720.068]: master offset   -1556592 s2 freq -170726 path delay     -4826

But as we can see, it didn't step for some reason. Here is a test I did using the same config file and it does step for me.

ptp4l[8898442.271]: master offset   -1093869 s0 freq   -1946 path delay     54642
ptp4l[8898443.271]: master offset   -1094931 s0 freq   -1946 path delay     54642
ptp4l[8898444.271]: master offset   -1102224 s1 freq   -6078 path delay     55329
ptp4l[8898445.271]: master offset       9378 s2 freq   -5131 path delay     55329

What linuxptp and kernel versions are you using?

--
Miroslav Lichvar

Re: [Linuxptp-users] sanity_freq_limit

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

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

Re: [Linuxptp-users] sanity_freq_limit

[Miroslav L. <mli...@re...>]

On Fri, Jun 19, 2015 at 09:08:56PM +0200, Richard Cochran wrote:
> 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.

He has SW timestamping. Maybe the kernel is missing ADJ_SETOFFSET
support? It would explaing why the step doesn't work. It seems it
appeared in kernel 2.6.39.

-- 
Miroslav Lichvar

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

Re: [Linuxptp-users] sanity_freq_limit

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

On Fri, Jun 19, 2015 at 07:43:01PM +0000, Daniel Le wrote:
> 
> 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.

Okay, so you have a special custom setup.  I cannot really guess what
is wrong, but it does appear that whatever clock you are using is
failing to jump, or that the change in time is not reflected in the
subsequent time stamps.

Thanks,
Richard

Re: [Linuxptp-users] sanity_freq_limit

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

"...or that the change in time is not reflected in the subsequent time stamps". This is a good pointer for debugging. The system clock may have been stepped, but the FPGA hardware clock is not stepped and continues to provide the timestamps from its un-stepped clock.

Much appreciate it.
Daniel

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

On Fri, Jun 19, 2015 at 07:43:01PM +0000, Daniel Le wrote:
> 
> 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.

Okay, so you have a special custom setup.  I cannot really guess what is wrong, but it does appear that whatever clock you are using is failing to jump, or that the change in time is not reflected in the subsequent time stamps.

Thanks,
Richard