linuxptp-users — Open discussion on using the linuxptp software.

Re: [Linuxptp-users] Installation of Linuxptp on Ubuntu PC

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

On Sat, Aug 29, 2015 at 06:09:56PM +0100, Guo Hao wrote:
> ptp4l[7726.711]: master offset         -8 s2 freq   +3835 path delay
> 825
> 
> Does this mean the clock offset between the 82574 NIC and the Master Clock
> is in the range less than 100 ns?

Yes.
 
> Does that mean the system time is synchronized to the ptp hardware clock on
> the 82574 NIC?

Yes, but remember that there is probably some offset in the low
microseconds range.  The "delay" tells you that reading the PHC time
over the PCIe bus takes about 13 microseconds.
 
> However I cannot run ptp4l and phc2sys as a daemon process under Ubuntu:
> 
> root@Hao-Ubuntu:~# service ptp4l start
> ptp4l: unrecognized service
> root@Hao-Ubuntu:~#
> 
> Any idea on this?

Just start the programs by hand.  To start them automatically, one
easy way is to put the commands into /etc/rc.local.
 
> Therefore, I doubt whether there is a inherent delay between the point when
> the Ethernet capture card request for the ToD and point the Ethernet
> capture card really gets the information or the system time is not
> synchronized by the hardware clock of the 82574 NIC.

But you said,

   the Ethernet capture card gets the 1-PPS from the same GPS clock.

so the ToD from the host is irrelevant.  The capture has the GPS's
1-PPS, and so the phase of its time stamps should be correct to a few
hundred nanoseconds.

The ~1 usec difference is probably just the sum of the GPS device's
egress latency and the capture card's ingress latency.  The number is
perfectly reasonable, if one or both of the devices has MAC time
stamping.

HTH,
Richard

Re: [Linuxptp-users] Installation of Linuxptp on Ubuntu PC

[Guo H. <gh...@gm...>]

Hi Richard,

Finally, I can make the ptp4l program works and the output of ptp4l -E -2
-H -i eth0 -m -q is shown as below:

ptp4l[7709.666]: master offset        -46 s2 freq   +3798 path delay
828
ptp4l[7710.667]: master offset         68 s2 freq   +3898 path delay
828
ptp4l[7711.669]: master offset         40 s2 freq   +3890 path delay
831
ptp4l[7712.672]: master offset         41 s2 freq   +3903 path delay
831
ptp4l[7713.678]: master offset         43 s2 freq   +3918 path delay
831
ptp4l[7714.679]: master offset        -77 s2 freq   +3810 path delay
831
ptp4l[7715.679]: master offset         41 s2 freq   +3905 path delay
831
ptp4l[7716.685]: master offset         39 s2 freq   +3916 path delay
830
ptp4l[7717.689]: master offset        -52 s2 freq   +3836 path delay
830
ptp4l[7718.692]: master offset        -34 s2 freq   +3839 path delay
829
ptp4l[7719.695]: master offset        -28 s2 freq   +3835 path delay
828
ptp4l[7720.697]: master offset        -50 s2 freq   +3804 path delay
828
ptp4l[7721.701]: master offset         95 s2 freq   +3934 path delay
828
ptp4l[7722.702]: master offset        -27 s2 freq   +3841 path delay
828
ptp4l[7723.703]: master offset         -3 s2 freq   +3857 path delay
828
ptp4l[7724.705]: master offset        -33 s2 freq   +3826 path delay
828
ptp4l[7725.709]: master offset        -20 s2 freq   +3829 path delay
827
ptp4l[7726.711]: master offset         -8 s2 freq   +3835 path delay
825

Does this mean the clock offset between the 82574 NIC and the Master Clock
is in the range less than 100 ns?

After that I make install the linuxptp package and follow the instruction
from Red Hat:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s1-Using_the_PTP_management_Client.html

I can use the pmc and phc2sys utilities and the output of phc2sys -s eth0
-w -m -q is shown below:

phc2sys[7981.691]: phc offset       -70 s2 freq  -22120 delay  13340
phc2sys[7982.691]: phc offset       -81 s2 freq  -22152 delay  13270
phc2sys[7983.691]: phc offset       -46 s2 freq  -22141 delay  13340
phc2sys[7984.691]: phc offset        70 s2 freq  -22039 delay  13340
phc2sys[7985.692]: phc offset        48 s2 freq  -22040 delay  13410
phc2sys[7986.692]: phc offset        19 s2 freq  -22055 delay  13340
phc2sys[7987.692]: phc offset       -23 s2 freq  -22091 delay  13410
phc2sys[7988.692]: phc offset       -47 s2 freq  -22122 delay  13340
phc2sys[7989.692]: phc offset        11 s2 freq  -22078 delay  14318
phc2sys[7990.692]: phc offset       -14 s2 freq  -22100 delay  13340
phc2sys[7991.693]: phc offset        27 s2 freq  -22063 delay  13340
phc2sys[7992.693]: phc offset       237 s2 freq  -21845 delay  13829
phc2sys[7993.693]: phc offset      -220 s2 freq  -22231 delay  13340
phc2sys[7994.693]: phc offset       -71 s2 freq  -22148 delay  13340
phc2sys[7995.693]: phc offset      -188 s2 freq  -22286 delay  16483
phc2sys[7996.693]: phc offset       188 s2 freq  -21966 delay  13340
phc2sys[7997.694]: phc offset       119 s2 freq  -21979 delay  13340
phc2sys[7998.694]: phc offset        14 s2 freq  -22048 delay  13340
phc2sys[7999.694]: phc offset       -87 s2 freq  -22145 delay  13270


Does that mean the system time is synchronized to the ptp hardware clock on
the 82574 NIC?


However I cannot run ptp4l and phc2sys as a daemon process under Ubuntu:

root@Hao-Ubuntu:~# service ptp4l start
ptp4l: unrecognized service
root@Hao-Ubuntu:~#

Any idea on this?

I am carrying out a test on verify the timestamp accuracy of an Ethernet
capture card.
This card obtains the ToD info from the host PC while accept the 1-PPS
signal to tick afterwards.

The host PC is synchronized to the GPS clock via Linuxptp (PTP port 1 on
GPS clock in use) and the Ethernet capture card gets the 1-PPS from the
same GPS clock.

Then I connect PTP port 2 of the GPS clock directly to the Ethernet capture
card via 3 m RJ45 cable.
When I compare the timestamp within the Follow_Up and the receipt timestamp
of corresponding Sync by Ethernet capture card, the time difference is
about 1.15 us, which might be not reasonable.

I got similar result around 1.5 us before I used Linuxptp and I used NTP to
sync the host pc with the GPS clock at that moment.

Therefore, I doubt whether there is a inherent delay between the point when
the Ethernet capture card request for the ToD and point the Ethernet
capture card really gets the information or the system time is not
synchronized by the hardware clock of the 82574 NIC.


Thank you very much and look forward to your feedback soon.


Best regards,
    Hao




On 29 August 2015 at 13:59, Richard Cochran <ric...@gm...>
wrote:

> On Sat, Aug 29, 2015 at 12:19:25PM +0100, Guo Hao wrote:
> > Hi Richard,
> >
> > i have 2 Intel 82547 NICs and they should support hardware timestamping.
>                  ^^^^^
> 82574 ?
>
> > Please see below the output of ethtool -T ethx:
>
> Ok, then:
>
> - Download and untar the linuxptp sources.
> - Change into the directory.
> - Type "make"
>
> Then, run the program:
>
>   ./ptp4l -m -q -i eth0
>
>
> HTH,
> Richard
>
>

Re: [Linuxptp-users] Installation of Linuxptp on Ubuntu PC

[Guo H. <gh...@gm...>]

Hi Richard,

Thanks a lot for the help.
Sorry I make a mistake. It should be Intel 82574 NIC.

Will try to install the linuxptp now.


Best regards,
    Hao


On 29 August 2015 at 13:59, Richard Cochran <ric...@gm...>
wrote:

> On Sat, Aug 29, 2015 at 12:19:25PM +0100, Guo Hao wrote:
> > Hi Richard,
> >
> > i have 2 Intel 82547 NICs and they should support hardware timestamping.
>                  ^^^^^
> 82574 ?
>
> > Please see below the output of ethtool -T ethx:
>
> Ok, then:
>
> - Download and untar the linuxptp sources.
> - Change into the directory.
> - Type "make"
>
> Then, run the program:
>
>   ./ptp4l -m -q -i eth0
>
>
> HTH,
> Richard
>
>

Re: [Linuxptp-users] Installation of Linuxptp on Ubuntu PC

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

On Sat, Aug 29, 2015 at 12:19:25PM +0100, Guo Hao wrote:
> Hi Richard,
> 
> i have 2 Intel 82547 NICs and they should support hardware timestamping.
                 ^^^^^
82574 ?

> Please see below the output of ethtool -T ethx:

Ok, then:

- Download and untar the linuxptp sources.
- Change into the directory.
- Type "make"

Then, run the program:

  ./ptp4l -m -q -i eth0


HTH,
Richard

Re: [Linuxptp-users] Installation of Linuxptp on Ubuntu PC

[Guo H. <gh...@gm...>]

Hi Richard,

i have 2 Intel 82547 NICs and they should support hardware timestamping.

Please see below the output of ethtool -T ethx:

hao@Hao-Ubuntu:~$ ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
    hardware-transmit     (SOF_TIMESTAMPING_TX_HARDWARE)
    software-transmit     (SOF_TIMESTAMPING_TX_SOFTWARE)
    hardware-receive      (SOF_TIMESTAMPING_RX_HARDWARE)
    software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)
    software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
    hardware-raw-clock    (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
    off                   (HWTSTAMP_TX_OFF)
    on                    (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
    none                  (HWTSTAMP_FILTER_NONE)
    all                   (HWTSTAMP_FILTER_ALL)
    ptpv1-l4-sync         (HWTSTAMP_FILTER_PTP_V1_L4_SYNC)
    ptpv1-l4-delay-req    (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ)
    ptpv2-l4-sync         (HWTSTAMP_FILTER_PTP_V2_L4_SYNC)
    ptpv2-l4-delay-req    (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ)
    ptpv2-l2-sync         (HWTSTAMP_FILTER_PTP_V2_L2_SYNC)
    ptpv2-l2-delay-req    (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ)
    ptpv2-event           (HWTSTAMP_FILTER_PTP_V2_EVENT)
    ptpv2-sync            (HWTSTAMP_FILTER_PTP_V2_SYNC)
    ptpv2-delay-req       (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ)
hao@Hao-Ubuntu:~$


hao@Hao-Ubuntu:~$ ethtool -T eth1
Time stamping parameters for eth1:
Capabilities:
    hardware-transmit     (SOF_TIMESTAMPING_TX_HARDWARE)
    software-transmit     (SOF_TIMESTAMPING_TX_SOFTWARE)
    hardware-receive      (SOF_TIMESTAMPING_RX_HARDWARE)
    software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)
    software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
    hardware-raw-clock    (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 1
Hardware Transmit Timestamp Modes:
    off                   (HWTSTAMP_TX_OFF)
    on                    (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
    none                  (HWTSTAMP_FILTER_NONE)
    all                   (HWTSTAMP_FILTER_ALL)
    ptpv1-l4-sync         (HWTSTAMP_FILTER_PTP_V1_L4_SYNC)
    ptpv1-l4-delay-req    (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ)
    ptpv2-l4-sync         (HWTSTAMP_FILTER_PTP_V2_L4_SYNC)
    ptpv2-l4-delay-req    (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ)
    ptpv2-l2-sync         (HWTSTAMP_FILTER_PTP_V2_L2_SYNC)
    ptpv2-l2-delay-req    (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ)
    ptpv2-event           (HWTSTAMP_FILTER_PTP_V2_EVENT)
    ptpv2-sync            (HWTSTAMP_FILTER_PTP_V2_SYNC)
    ptpv2-delay-req       (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ)




Best regards,
    Hao





On 29 August 2015 at 09:17, Richard Cochran <ric...@gm...>
wrote:

> On Fri, Aug 28, 2015 at 10:59:37PM +0100, Guo Hao wrote:
> > hao@Hao-Ubuntu:~$ uname -a
> > Linux Hao-Ubuntu 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15
> > 17:43:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>
> Ok, so your kernel is new enough, and I guess that the ubuntu kernel
> does include PTP support.
>
> Now, check your network interfaces for time stamping support:
>
>     ethtool -T eth0
>     ethtool -T eth1
>     ...
>
> Post the output of these commands.
>
> Thanks,
> Richard
>
>

Re: [Linuxptp-users] Installation of Linuxptp on Ubuntu PC

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

On Fri, Aug 28, 2015 at 10:59:37PM +0100, Guo Hao wrote:
> hao@Hao-Ubuntu:~$ uname -a
> Linux Hao-Ubuntu 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15
> 17:43:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Ok, so your kernel is new enough, and I guess that the ubuntu kernel
does include PTP support.

Now, check your network interfaces for time stamping support:

    ethtool -T eth0
    ethtool -T eth1
    ...

Post the output of these commands.

Thanks,
Richard

Re: [Linuxptp-users] Installation of Linuxptp on Ubuntu PC

[Guo H. <gh...@gm...>]

Hi Richard,

Thanks a lot for the reply.

The output of uname -a is:

hao@Hao-Ubuntu:~$ uname -a
Linux Hao-Ubuntu 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15
17:43:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux


Best regards,
     Hao

On 28 August 2015 at 22:56, Guo Hao <gh...@gm...> wrote:

> Hi Richard,
>
> Thanks a lot for the reply.
>
> The output of uname -a is:
>
> hao@Hao-Ubuntu:~$ uname -a
> Linux Hao-Ubuntu 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15
> 17:43:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>
>
> Best regards,
>      Hao
>
>
> On 28 August 2015 at 21:39, Richard Cochran <ric...@gm...>
> wrote:
>
>> On Fri, Aug 28, 2015 at 08:23:51PM +0100, Guo Hao wrote:
>> > So could you please tell me how to move forward from the kernel part?
>> > Thank you very much for your help.
>>
>> You do not need to compile the kernel if it is new enough.
>>
>> Tell us the output of this command:
>>
>>         uname -a
>>
>> Thanks,
>> Richard
>>
>
>

Re: [Linuxptp-users] Installation of Linuxptp on Ubuntu PC

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

On Fri, Aug 28, 2015 at 08:23:51PM +0100, Guo Hao wrote:
> So could you please tell me how to move forward from the kernel part?
> Thank you very much for your help.

You do not need to compile the kernel if it is new enough.

Tell us the output of this command:

	uname -a

Thanks,
Richard

[Linuxptp-users] Installation of Linuxptp on Ubuntu PC

[Guo H. <gh...@gm...>]

Hi Richard,

I am new to Linuxptp as well as the Ubuntu / Linux system.

Could please provide more details on how to install Linuxptp on Ubuntu?
I tried to compile the Ubuntu kernel but cannot find any option such as
"configure_pps" after command make menuconfig.

So could you please tell me how to move forward from the kernel part?
Thank you very much for your help.



Best regards,
    Hao

[Linuxptp-users] Installation of Linux PTP on Ubuntu

[Hao G. <gh...@gm...>]

Dear Richard, 

I am new to the Ubuntu / Linux system but I would like to install Linuxptp
on Ubuntu and run my PC as the PTP slave to certain PTP masters. 

Could you provide more details on how to make Linuxptp work on Ubuntu?

Thanks a lot and look forward to your feedback soon.


Best regards,
    Hao 

Re: [Linuxptp-users] Missing Sanity Checks for malloc()/calloc()/strdup() in linuxptp-1.5

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

On Thu, Aug 27, 2015 at 04:06:23PM +0200, Xavier Bestel wrote:
> Under linux malloc() will only return NULL when you get out of address
> space, i.e. virtually never on a 64bits machine. Low memory situations are
> handled elsewhere (e.g. OOM killer).
> So I don't think checking malloc() for NULL is that wise.

It depends on the kernel overcommit configuration. In the default
configuration getting NULL is unlikely, but that doesn't mean it
should result in a segfault. I'm just not convinced there is any point
in trying to recover from that.

-- 
Miroslav Lichvar

Re: [Linuxptp-users] Missing Sanity Checks for malloc()/calloc()/strdup() in linuxptp-1.5

[Xavier B. <xav...@fr...>]

Under linux malloc() will only return NULL when you get out of address 
space, i.e. virtually never on a 64bits machine. Low memory situations 
are handled elsewhere (e.g. OOM killer).
So I don't think checking malloc() for NULL is that wise.

     Xav

Le 21/08/2015 18:43, Bill Parker a écrit :
> This was a manual review of the code, I did not use something like 
> clang-analyzer to find these :)
>
> The wrapper approach makes sense as well (IMO).
>
> Bill
>
> On Fri, Aug 21, 2015 at 8:52 AM, Keller, Jacob E 
> <jac...@in... <mailto:jac...@in...>> wrote:
>
>     On Fri, 2015-08-21 at 08:55 +0200, Miroslav Lichvar wrote:
>
>     > I think an easier and cleaner approach would be to write
>     wrappers for
>     > the strdup/calloc/malloc/realloc functions which just send an error
>     > message and call exit(1) when the allocation fails, and use the
>     > wrappers everywhere in the code.
>     >
>
>     Yea, I think this is probably a good call. We could use these
>     everywhere in the code base.
>
>     Regards,
>     Jake
>
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Re: [Linuxptp-users] ptp4l summary_interval

[Harold L. <hla...@pi...>]

Jake,

Agree with 'ptp4l' and 'phc2sys' interval values appearing to be in different units, was reading something last week and it appears as if 'phc2sys' can have a configuration file associated with it as well (will need to go back and review), is this correct?

Thanks,
Harld

-----Original Message-----
From: Keller, Jacob E [mailto:jac...@in...] 
Sent: Wednesday, August 26, 2015 4:22 PM
To: Harold Lapprich <hla...@pi...>; lin...@li...
Subject: Re: [Linuxptp-users] ptp4l summary_interval

On Wed, 2015-08-26 at 18:28 +0000, Harold Lapprich wrote:
> Hi Jake,
>  
> The content of my configuration file:
>  
> [global]
> verbose 0
> summary_interval 6
> [eth0]
>  
> Parses without error but the log file /var/volatile/log/messages:
>  
> Jul 30 17:20:22 zx3-pm3-zynq7 user.info ptp4l: [10651.690] rms 13563 
> max 78070 freq  +2032 +/- 893 delay 10761 +/- 255 Jul 30 17:20:29 
> zx3-pm3-zynq7 user.info phc2sys: [10658.624] rms  923 max 1687 freq  
> +2407 +/- 1041 delay  2692 +/-  13 Jul 30 17:20:39 zx3-pm3-zynq7 
> user.info phc2sys: [10668.626] rms 1538 max 2760 freq  +3758 +/- 1445 
> delay  2689 +/-  12 Jul 30 17:20:49 zx3-pm3-zynq7 user.info phc2sys: 
> [10678.628] rms  947 max 2179 freq  +2823 +/- 822 delay  2685 +/-  13 
> Jul 30 17:20:59 zx3-pm3-zynq7 user.info phc2sys: [10688.630] rms  668 
> max 1137 freq  +3100 +/- 692 delay  2702 +/-  32 Jul 30 17:21:09 
> zx3-pm3-zynq7 user.info phc2sys: [10698.633] rms  744
> max 1469 freq  +2854 +/- 661 delay  2683 +/-   9
> Jul 30 17:21:19 zx3-pm3-zynq7 user.info phc2sys: [10708.635] rms 1092 
> max 2331 freq  +3324 +/- 989 delay  2693 +/-  20 Jul 30 17:21:26 
> zx3-pm3-zynq7 user.info ptp4l: [10715.700] rms  820 max 2312 freq  
> +3085 +/- 756 delay 10834 +/- 265
>  
>  
> It was an error on my part, I wasn't waiting long enough in comparison 
> to 'ph2sys -u 6' it is much slower.
>  
> Thanks,
> Harold

I think the -u option in phc2sys may take a value in differing units. I am not sure

Regards,
Jake

Re: [Linuxptp-users] ptp4l summary_interval

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

On Wed, 2015-08-26 at 18:28 +0000, Harold Lapprich wrote:
> Hi Jake,
>  
> The content of my configuration file:
>  
> [global]
> verbose 0
> summary_interval 6
> [eth0]
>  
> Parses without error but the log file /var/volatile/log/messages:
>  
> Jul 30 17:20:22 zx3-pm3-zynq7 user.info ptp4l: [10651.690] rms 13563
> max 78070 freq  +2032 +/- 893 delay 10761 +/- 255
> Jul 30 17:20:29 zx3-pm3-zynq7 user.info phc2sys: [10658.624] rms  923
> max 1687 freq  +2407 +/- 1041 delay  2692 +/-  13
> Jul 30 17:20:39 zx3-pm3-zynq7 user.info phc2sys: [10668.626] rms 1538
> max 2760 freq  +3758 +/- 1445 delay  2689 +/-  12
> Jul 30 17:20:49 zx3-pm3-zynq7 user.info phc2sys: [10678.628] rms  947
> max 2179 freq  +2823 +/- 822 delay  2685 +/-  13
> Jul 30 17:20:59 zx3-pm3-zynq7 user.info phc2sys: [10688.630] rms  668
> max 1137 freq  +3100 +/- 692 delay  2702 +/-  32
> Jul 30 17:21:09 zx3-pm3-zynq7 user.info phc2sys: [10698.633] rms  744
> max 1469 freq  +2854 +/- 661 delay  2683 +/-   9
> Jul 30 17:21:19 zx3-pm3-zynq7 user.info phc2sys: [10708.635] rms 1092
> max 2331 freq  +3324 +/- 989 delay  2693 +/-  20
> Jul 30 17:21:26 zx3-pm3-zynq7 user.info ptp4l: [10715.700] rms  820
> max 2312 freq  +3085 +/- 756 delay 10834 +/- 265
>  
>  
> It was an error on my part, I wasn't waiting long enough in
> comparison to 'ph2sys -u 6' it is much slower.
>  
> Thanks,
> Harold

I think the -u option in phc2sys may take a value in differing units. I
am not sure

Regards,
Jake

Re: [Linuxptp-users] ptp4l summary_interval

[Harold L. <hla...@pi...>]

Hi Jake,

The content of my configuration file:

[global]
verbose 0
summary_interval 6
[eth0]

Parses without error but the log file /var/volatile/log/messages:

Jul 30 17:20:22 zx3-pm3-zynq7 user.info ptp4l: [10651.690] rms 13563 max 78070 freq  +2032 +/- 893 delay 10761 +/- 255
Jul 30 17:20:29 zx3-pm3-zynq7 user.info phc2sys: [10658.624] rms  923 max 1687 freq  +2407 +/- 1041 delay  2692 +/-  13
Jul 30 17:20:39 zx3-pm3-zynq7 user.info phc2sys: [10668.626] rms 1538 max 2760 freq  +3758 +/- 1445 delay  2689 +/-  12
Jul 30 17:20:49 zx3-pm3-zynq7 user.info phc2sys: [10678.628] rms  947 max 2179 freq  +2823 +/- 822 delay  2685 +/-  13
Jul 30 17:20:59 zx3-pm3-zynq7 user.info phc2sys: [10688.630] rms  668 max 1137 freq  +3100 +/- 692 delay  2702 +/-  32
Jul 30 17:21:09 zx3-pm3-zynq7 user.info phc2sys: [10698.633] rms  744 max 1469 freq  +2854 +/- 661 delay  2683 +/-   9
Jul 30 17:21:19 zx3-pm3-zynq7 user.info phc2sys: [10708.635] rms 1092 max 2331 freq  +3324 +/- 989 delay  2693 +/-  20
Jul 30 17:21:26 zx3-pm3-zynq7 user.info ptp4l: [10715.700] rms  820 max 2312 freq  +3085 +/- 756 delay 10834 +/- 265


It was an error on my part, I wasn't waiting long enough in comparison to 'ph2sys -u 6' it is much slower.

Thanks,
Harold



-----Original Message-----
From: Keller, Jacob E [mailto:jac...@in...]
Sent: Wednesday, August 26, 2015 2:19 PM
To: Harold Lapprich <hla...@pi...>; lin...@li...
Subject: Re: [Linuxptp-users] ptp4l summary_interval

On Wed, 2015-08-26 at 16:48 +0000, Harold Lapprich wrote:
> To All,
>
> Gotten to the point in a design where the need for printed out has
> been reduced and for 'phc2sys' one can use '-u' to reduce the output,
> in an older version of 'linuxptp: ptp4l' 'summary_interval' was
> supported and it handled the reduced output to the log file very
> similar to 'phc2sys'. Currently using 'linuxptp: 1.5' and
> 'summary_interval' is no longer supported and the man page shows no
> new parameter (tried -l for the heck of it with no luck), can someone
> respond with the alternative for the directive 'summary_interval' to
> reduce output?
>
> Thanks,
> Harold

Hi Harold,

According to ptp4l.8 summary_interval is supported.... you have to use it in the configuration file. :)

Does this not appear to work for you?

Regards,
Jake

Re: [Linuxptp-users] ptp4l summary_interval

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

On Wed, 2015-08-26 at 16:48 +0000, Harold Lapprich wrote:
> To All,
>  
> Gotten to the point in a design where the need for printed out has
> been reduced and for 'phc2sys' one can use '-u' to reduce the output,
> in an older version of 'linuxptp: ptp4l' 'summary_interval' was
> supported and it handled the reduced output to the log file very
> similar to 'phc2sys'. Currently using 'linuxptp: 1.5' and
> 'summary_interval' is no longer supported and the man page shows no
> new parameter (tried -l for the heck of it with no luck), can someone
> respond with the alternative for the directive 'summary_interval' to
> reduce output?
>  
> Thanks,
> Harold

Hi Harold,

According to ptp4l.8 summary_interval is supported.... you have to use
it in the configuration file. :)

Does this not appear to work for you?

Regards,
Jake

[Linuxptp-users] ptp4l summary_interval

[Harold L. <hla...@pi...>]

To All,

Gotten to the point in a design where the need for printed out has been reduced and for 'phc2sys' one can use '-u' to reduce the output, in an older version of 'linuxptp: ptp4l' 'summary_interval' was supported and it handled the reduced output to the log file very similar to 'phc2sys'. Currently using 'linuxptp: 1.5' and 'summary_interval' is no longer supported and the man page shows no new parameter (tried -l for the heck of it with no luck), can someone respond with the alternative for the directive 'summary_interval' to reduce output?

Thanks,
Harold

Re: [Linuxptp-users] Missing Sanity Checks for malloc()/calloc()/strdup() in linuxptp-1.5

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

On Fri, Aug 21, 2015 at 08:55:01AM +0200, Miroslav Lichvar wrote:
> I think an easier and cleaner approach would be to write wrappers for
> the strdup/calloc/malloc/realloc functions which just send an error
> message and call exit(1) when the allocation fails, and use the
> wrappers everywhere in the code.

If you want to do that way for timemaster, fine.

But for ptp4l/pmc/phc2sys, I prefer proper error handling.

Thanks,
Richard

Re: [Linuxptp-users] Missing Sanity Checks for malloc()/calloc()/strdup() in linuxptp-1.5

[Bill P. <wp...@gm...>]

This was a manual review of the code, I did not use something like
clang-analyzer to find these :)

The wrapper approach makes sense as well (IMO).

Bill

On Fri, Aug 21, 2015 at 8:52 AM, Keller, Jacob E <jac...@in...>
wrote:

> On Fri, 2015-08-21 at 08:55 +0200, Miroslav Lichvar wrote:
>
> > I think an easier and cleaner approach would be to write wrappers for
> > the strdup/calloc/malloc/realloc functions which just send an error
> > message and call exit(1) when the allocation fails, and use the
> > wrappers everywhere in the code.
> >
>
> Yea, I think this is probably a good call. We could use these
> everywhere in the code base.
>
> Regards,
> Jake

Re: [Linuxptp-users] Missing Sanity Checks for malloc()/calloc()/strdup() in linuxptp-1.5

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

On Fri, 2015-08-21 at 08:55 +0200, Miroslav Lichvar wrote:

> I think an easier and cleaner approach would be to write wrappers for
> the strdup/calloc/malloc/realloc functions which just send an error
> message and call exit(1) when the allocation fails, and use the
> wrappers everywhere in the code.
> 

Yea, I think this is probably a good call. We could use these
everywhere in the code base.

Regards,
Jake

Re: [Linuxptp-users] Missing Sanity Checks for malloc()/calloc()/strdup() in linuxptp-1.5

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

Hi,

(this probably belongs to the linuxptp-devel list)

On Thu, Aug 20, 2015 at 02:51:04PM -0700, Bill Parker wrote:
> Hello All,
> 
>     In reviewing source code in linuxptp-1.5, I found several instances
> where the return values for calls to malloc()/calloc()/strdup() are not
> checked for a return value of NULL, indicating failure.  This is in file
> 'timemaster.c', and the patch file below should address these issues,
> and also free()'s previously allocated memory in the order it was
> allocated:

Is this to fix warnings from a static code analyzer?

There are other places in the timemaster code where memory is
allocated, e.g. the parray_* and string_* function calls. If the code
tried to handle them all, it would be a mess.

I think an easier and cleaner approach would be to write wrappers for
the strdup/calloc/malloc/realloc functions which just send an error
message and call exit(1) when the allocation fails, and use the
wrappers everywhere in the code.

-- 
Miroslav Lichvar

Re: [Linuxptp-users] Missing Sanity Checks for malloc()/calloc()/strdup() in linuxptp-1.5

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

Hi Bill,

On Thu, 2015-08-20 at 14:51 -0700, Bill Parker wrote:
> Hello All,
> 
>     In reviewing source code in linuxptp-1.5, I found several
> instances
> where the return values for calls to malloc()/calloc()/strdup() are
> not
> checked for a return value of NULL, indicating failure.  This is in
> file
> 'timemaster.c', and the patch file below should address these issues,
> and also free()'s previously allocated memory in the order it was
> allocated:
> 

It is common practice for this list to use git-send-email to generate
the patch, rather than creating the email by hand. Then the subject of
the email could be the commit message. You can also use --- scissors
feature to include comments that may not be valid inside a commit
message but should appear on the mailing list. That being said, this
patch looks ok.

One general comment is for blocks which have early returns it may be
worth using a "goto err_xyz;" style instead of copying error
recovery/handling. This often can simplify the "undo the stuff we
already did as we exit" to reduce repeated code (which is a likely
place to add memory leaks in the future as code changes).

I couldn't easily tell if any of the blocks would really benefit from
this or not, but it is something to think about.

<snip>

> 
> running 'make' in the linuxptp-1.5 source tree (with the code added
> above) results in a clean build, btw.
> 
> I am attaching the patch file (diff -u format) to this bug report...
> 
> Comments, Questions, Complaints, Suggestions? :)


Thanks for the patch!

Regards,
Jake

[Linuxptp-users] Missing Sanity Checks for malloc()/calloc()/strdup() in linuxptp-1.5

[Bill P. <wp...@gm...>]

Hello All,

    In reviewing source code in linuxptp-1.5, I found several instances
where the return values for calls to malloc()/calloc()/strdup() are not
checked for a return value of NULL, indicating failure.  This is in file
'timemaster.c', and the patch file below should address these issues,
and also free()'s previously allocated memory in the order it was
allocated:

=======================================================================

--- timemaster.c.orig    2015-08-19 18:35:03.044000000 -0700
+++ timemaster.c    2015-08-19 18:57:01.046000000 -0700
@@ -268,9 +268,18 @@
     }

     source = malloc(sizeof(*source));
+    if (!source) {
+        pr_err("low memory, failed to add source to ntp_server");
+        return NULL;
+    }
     source->type = NTP_SERVER;
     source->ntp = ntp_server;
     source->ntp.address = strdup(source->ntp.address);
+    if (!source->ntp.address) {
+        pr_err("low memory, failed to add source->ntp.address");
+        free(source);
+        return NULL;
+    }

     return source;
 }
@@ -282,6 +291,10 @@
     int r = 0;

     source = malloc(sizeof(*source));
+    if (!source) {
+        pr_err("low memory, failed to add source to ptp_parse");
+        goto failed;
+    }
     source->type = PTP_DOMAIN;
     source->ptp.delay = DEFAULT_PTP_DELAY;
     source->ptp.ntp_poll = DEFAULT_PTP_NTP_POLL;
@@ -482,10 +495,19 @@
     char buf[4096], *line, *section_name = NULL;
     char **section_lines = NULL;
     int ret = 0;
-
+
+    if (!config) {
+        pr_err("low memory, failed to add config to config_parse");
+        return NULL;
+    }
     config->sources = (struct source **)parray_new();
     config->ntp_program = DEFAULT_NTP_PROGRAM;
     config->rundir = strdup(DEFAULT_RUNDIR);
+    if (!config->rundir) {
+        pr_err("low memory, failed to add config->rundir to config_parse");
+        free(config);
+        return NULL;
+    }

     init_program_config(&config->chronyd, "chronyd",
                 NULL, DEFAULT_CHRONYD_SETTINGS, NULL);
@@ -666,6 +688,10 @@

     /* get PHCs used by specified interfaces */
     phcs = malloc(num_interfaces * sizeof(int));
+    if (!phcs) {
+        pr_err("low memory, failed to add phcs to ptp_source");
+        return 0;
+    }
     for (i = 0; i < num_interfaces; i++) {
         phcs[i] = -1;

@@ -719,6 +745,11 @@

             /* don't use this PHC in other sources */
             phc = malloc(sizeof(int));
+            if (!phc) {
+                pr_err("low memory, failed to add phc to ptp_source");
+                free(phcs);
+                return 0;
+            }
             *phc = phcs[i];
             parray_append((void ***)allocated_phcs, phc);
         }
@@ -727,9 +758,22 @@
                        config->rundir, *shm_segment);

         config_file = malloc(sizeof(*config_file));
+        if (!config_file) {
+            pr_err("low memory, failed to add config_file to ptp_source");
+            free(phc);
+            free(phcs);
+            return 0;
+        }
         config_file->path = string_newf("%s/ptp4l.%d.conf",
                         config->rundir, *shm_segment);
         config_file->content = strdup("[global]\n");
+        if (!config_file->content) {
+            pr_err("low memory, failed to add config_file->content to
ptp_source");
+            free(config_file);
+            free(phc);
+            free(phcs);
+            return 0;
+        }
         extend_config_string(&config_file->content,
                      config->ptp4l.settings);
         extend_config_string(&config_file->content,
@@ -811,7 +855,17 @@
     struct config_file *ntp_config = malloc(sizeof(*ntp_config));
     char **command = NULL;

+    if (!ntp_config) {
+        pr_err("low memory, failed to add ntp_config to add_ntp_program");
+        return NULL;
+    }
+
     ntp_config->content = strdup("");
+    if (!ntp_config->content) {
+        pr_err("low memory, failed to add ntp_config->content to
add_ntp_program");
+        free(ntp_config);
+        return NULL;
+    }

     switch (config->ntp_program) {
     case CHRONYD:
@@ -866,6 +920,10 @@
     int **allocated_phcs = (int **)parray_new();
     int ret = 0, shm_segment = 0;

+    if (!script) {
+        pr_err("low memory, failed to add script to script_create");
+        return NULL;
+    }
     script->configs = (struct config_file **)parray_new();
     script->commands = (char ***)parray_new();

=======================================================================

running 'make' in the linuxptp-1.5 source tree (with the code added
above) results in a clean build, btw.

I am attaching the patch file (diff -u format) to this bug report...

Comments, Questions, Complaints, Suggestions? :)

Bill Parker (wp02855 at gmail dot com)

Re: [Linuxptp-users] Grandmaster Auto-Negotiation and Reconfiguration of phc2sys to ptp4l Synchronization

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

On Tue, Aug 18, 2015 at 11:14:29PM +0000, Harold Lapprich wrote:
> 	9. A background application written by me CheckMasterStatus is
> 	started on each of the system nodes at boot monitoring PTP
> 	status using PMC.

Yes, that is whole point of why the pmc program exists.

> Automatic system recovery is something everyone would want built
> into the clock architecture and therefore manual configuration has
> to be done at system bring-up/boot using 'linuxptp', ptp4l, phcsys
> and pmc (no use for 'timemaster').

Not everyone has the same esoteric requirements you have.  We provide
programs that cover common use cases by default.  However, we do *not*
hard code random assumptions about how people will use PTP.  Intead,
the tools, when used properly, allow you to adapt linuxptp to your
particular scenario.

Richard

Re: [Linuxptp-users] Grandmaster Auto-Negotiation and Reconfiguration of phc2sys to ptp4l Synchronization

[Harold L. <hla...@pi...>]

Jake,

OK using the definition of master/slave with respect to the PTP-network:

	1.  The PTP-network is a master when receiving time from the system clock (NTP feeds the system clock, and 'phc2sy' 'feeds the PTP master hardware clock which then feeds the PTP network),
	2. And the PTP-network is the slave when setting system clock (the 'ptp4'l writes the hardware clock, then 'phc2sys' writes the system clock tuned to the hardware clock).

When the PTP-network is the master the system clock is being sit by some source (NTP, GPS, the system crystal, etc.).

Topic of interest is when the PTP-network is a master.

Timemaster is slave-only. That is, PTP slave. The timemaster configures such that it 'ptp4l' node will *never* become master clock. Therefore 'timemaster' is totally useless when one wants any node to become PTP master should the master fail.

Example: 6 PTP node network:

	1. ptp4l -i eth0 (so it can become master if the master fails); phcsys -a -r -r (phcsys uses system clock to set hardware clock if it should become master)
	2. ptp4l -i eth0 (so it can become master if the master fails); phcsys -a -r -r (phcsys uses system clock to set hardware clock if it should become master)
	3. ptp4l -i eth0 (so it can become master if the master fails); phcsys -a -r -r (phcsys uses system clock to set hardware clock if it should become master)
	4. ptp4l -i eth0 (so it can become master if the master fails); phcsys -a -r -r (phcsys uses system clock to set hardware clock if it should become master)
	5. ptp4l -i eth0 (so it can become master if the master fails); phcsys -a -r -r (phcsys uses system clock to set hardware clock if it should become master)
	6. ptp4l -i eth0 (so it can become master if the master fails); phcsys -a -r -r (phcsys uses system clock to set hardware clock if it should become master)

	7. In a Linux system all PTP nodes are created at boot,

	8. By auto-negotiation one of the nodes becomes PTP master and the remaining 5 nodes become PTP slaves,

	9. A background application written by me CheckMasterStatus is started on each of the system nodes at boot monitoring PTP status using PMC.
		. if PTP master the ntpd deamon is started to feed the system clock
		. if PTP slave a check is made for ntdp running on the system and if it exist it is  killed (this would happen as devices are plugged and unplugged into the network and ptp4l considers the new device to be a more accurate source).



Was hoping to use 'timemaster' but since it will only start ptp4l in slave only mode (i.e., ptp4l -i eth0 -s) it won't work when automatic recovery of the network is needed.

Automatic system recovery is something everyone would want built into the clock architecture and therefore manual configuration has to be done at system bring-up/boot using 'linuxptp', ptp4l, phcsys and pmc (no use for 'timemaster').

Harold

-----Original Message-----
From: Keller, Jacob E [mailto:jac...@in...] 
Sent: Tuesday, August 18, 2015 4:04 PM
To: mli...@re...; Harold Lapprich <hla...@pi...>
Cc: lin...@li...
Subject: Re: [Linuxptp-users] Grandmaster Auto-Negotiation and Reconfiguration of phc2sys to ptp4l Synchronization

Hi,

On Tue, 2015-08-18 at 14:54 +0000, Harold Lapprich wrote:
> Jake,
> 
> Thanks for the detailed reply. My apologies but I need to iterate on 
> this one more time, want to keep master/slave with respect to the 
> system-network and NOT the PTP-network (for example the PTP-network is 
> a slave to the system-network master).
> 

It doesn't matter what you want. The terminology is what it means. You changing it is confusing the discussion.

The PTP network derives it's time from somewhere, be that GPS, NTP, it's own crystal on the grandmaster, whatever. This is not relevant to PTP. However, how you transition this time in is, sure.


> Want to drop the 'ptp4l'  scenario of system-network master from the 
> discussion to simplify things, another words PTP-network is always a 
> slave to the system-network or to NTP/ntpd master:
> 

PTP always derives it's time from some source.

> 1.      NTP --> system clock -> phc2sys -> ptp4l (master) -> network
> out to other PTP slaves --> ptp4l (slave) --> phc2sys --> system clock 
> (No NTP here)
> 

When PTP is a master node, it gets its time from some source. In this case, NTP feeds the system clock, and phc2sys feeds the PTP master hardware clock which then feeds the PTP network.

> 
> 
> Timemaster is slave-only. That is, PTP slave. The timemaster 
> configures such that it's ptp4l node will *never* become master clock. 
> The reason for this is because phc2sys only supports ntpshm segment 
> clock going from slave mode, and would have to switch servos which no 
> one has written code for.
> 

Time master is slaveOnly, that is, PTP will always be slave, so it will always be creating a SHM segment clock that may (or may not) feed PTP.

> For example:
> ptp4l -i eth0
> phc2sys -a -r -r
> chronyd 'local stratum 1' 'allow'
> 
> The example configuration file shows 'ptp4l' being able to assume 
> GrandMaster but NOT system-network master due to a clock update
> 

The example configuration file for PTP allows it perfectly to become GrandMaster and feed the system time. The issue you have is that when this happens you STILL have NTP configured to set the host clock. Your whole  issue is that NTP is not aware of this and tries to reset system clock instead of serving that time. You need to fix NTP to assume that the system clock is absolute. 

> conflict between 'phc2sys' and the NTP/ntpd deamon (along with the SHM 
> or shared memory code issue you mentioned). Therefore 'phc2sys'
> must always be a slave passing updates to 'ptp4l' which is GrandMaster 
> to the PTP-network?
> 

This only happens when ptp4l is in "slave" mode. phc2sys will only write the system clock (when configured in -a -r mode) when ptp4l is
*receiving* time from the network. Ie; it is deriving its time source from some other GrandMaster clock.

> If 'ptp4l' can NOT become GrandMaster there would be no way of 
> synchronizing system-network clock with PTP-network clock.
> 

Sure there is. Not every node has to be configured the same way. You configure one node manually with high values for its clock source and then it is elected GrandMaster clock. Then the other nodes are slaveOnly so they will never send announce messages, thus will never be selected.

The issue is that the default NTP keeps trying to reset the clock after phc2sys configures it.

If ptp4l is in "master" (or even the GrandMaster of a larger network) you can configure NTP to write the system clock, then phc2sys to tune the hardware clock running ptp4l to the system clock time source. Thus, ptp4l will serve (or as above, feed) the PTP network with this time source.

If ptp4l is in "slave" mode it receives PTP time from the PTP network and tunes its internal clock. Then phc2sys feeds the system time from the internal clock.

However, by default, ntpd is also trying to feed the system clock via its own mechanism. This is the conflict. Two sources controlling the clock.

Thus, timemaster gets around this by not having phc2sys feed the system clock, but instead feed an SHM segmnent which ntpd/chronyd read to use as a possible input, along with NTP, and feed the system time from whichever is best.

The issue is that phc2sys can't switch between these two modes, because phc2sys would have to change servos which is not supported.

Regards,
Jake


> Thanks,
> Harold
> 
> 
> 
> 
> -----Original Message-----
> From: Keller, Jacob E [mailto:jac...@in...]
> Sent: Monday, August 17, 2015 6:14 PM
> To: mli...@re...; Harold Lapprich < 
> hla...@pi...>
> Cc: lin...@li...
> Subject: Re: [Linuxptp-users] Grandmaster Auto-Negotiation and 
> Reconfiguration of phc2sys to ptp4l Synchronization
> 
> Hello again,
> 
> I think you're still missing something.
> 
> Timemaster is slave-only. That is, PTP slave. The timemaster 
> configures such that it's ptp4l node will *never* become master clock. 
> The reason for this is because phc2sys only supports ntpshm segment 
> clock going from slave mode, and would have to switch servos which no 
> one has written code for.
> 
> Thus, timemaster will only ever setup PTP slaves. Ie: these nodes can 
> never be elected as the master clock in the PTP network at all.
> 
> I'm not sure what you mean by "entireSystem-network".
> 
> Hopefully we are clear here, and "master/slave" designation only 
> refers to PTP network.
> 
> You can decide what the SOURCE of the time on the ptp master is, 
> either GPS, NTP, etc. That's not of concern to PTP network.
> 
> timemaster lets you configure a ptp4l *slave* to feed a time clock to 
> chronyd such that chronyd will either use NTP or PTP time whichever 
> one is considered more accurate.
> 
> I don't believe timemaster configures chronyd to actually *serve* the 
> PTP time onto the NTP protocol, but Miroslav can correct me if I am 
> wrong.
> 
> If you have a PTP master node, then it needs to get time from 
> somewhere. Usually this would be from say, NTP which writes the master 
> clock then the phc2sys writes the hardware clock onboard the ethernet 
> device using the system clock as a reference.
> 
> In reverse, the ptp4l writes the hardware clock, then phc2sys writes 
> the system clock tuned to the hardware clock. But by default ntpd and 
> chronyd are configured to write the system clock and thus we have two 
> processes writing to the system clock, which results in the 
> clock_check errors you saw at the beginning of this thread.
> 
> Those are the two flows in regards to ptp4l clock, system clock and 
> phc2sys and chronyd's roles.
> 
> phc2sys can also provide a "SHM" reference to chronyd WITHOUT writing 
> the system clock, and chronyd will use this as a reference to tune the 
> system clock. This however can't work when phc2sys must write the 
> hardware clock, as chronyd and ntpd don't know of the hardware clock.
> Thus, phc2sys can't swap between these modes, since it is not designed 
> to change servos from the PI servo to the NTPSHM servo mid run, thus 
> it can't automatically switch if the node is selected as master. This 
> is why timemaster configures ptp4l as slave only.
> 
> Regards,
> Jake
> 
> On Mon, 2015-08-17 at 21:56 +0000, Harold Lapprich wrote:
> Jake,
> 
> Thanks for clarifying the function of the 'timemaster', a program 
> purely for configuring other programs. Going to go through your 
> response 1 line item at a time to simplify my response and clarify my 
> understanding. Getting specific terms in place for discussing this 
> matter has been helpful.
> 
> So “master” means serving time out over the entireSystem-network NOT 
> the PTP-network (intentionally separating entireSystem-network and 
> PTP-network). When 'master' is used it is with regards to the 
> entireSystem-network and GrandMaster is used with regards to the PTP 
> -network.
> 
> 
> 
> Miroslav mentioned that 'timemaster' is PTP slave only and starts 
> ptp4l with the slaveOnly option, so it can't become a master and that 
> didn't add up for me. I believe master and GrandMaster were getting 
> mixed up here (the slaveOnly options is for GrandMaster and not 
> master).
> 
> "No, timemaster is currently PTP slave only. It starts ptp4l with the 
> slaveOnly option, so it can't become a master. With current phc2sys it 
> wouldn't work anyway. It would need to be modified to switch between 
> two servos, NTP SHM when the PTP clock is synchronized and a real 
> servo when the system clock is the source."
> 
> 
> "For example:
> 
> ptp4l -i eth0
> 
> phc2sys -a -r -r
> 
> chronyd 'local stratum 1' 'allow'"
> 
> This example provided 'ptp4l -i eth0' shows ptp4l starting withOUT the 
> slaveOnly option '-s' so in this case 'ptp4l' can assume GrandMaster 
> of the PTP-network (again it appears to be a mixing of the terms 
> master/entireSystem-network and Grandmaster/PTP-network)?
> 
> 
> 
> Thanks for the flow diagram in your response is most helpful, I was 
> thinking 'timemaster' did more than just configure programs:
> 
> 
> 1.      NTP --> system clock -> phc2sys -> ptp4l (master) -> network
> out to other PTP slaves --> ptp4l (slave) --> phc2sys --> system clock 
> (No NTP here)
> 
>         As you mentioned ptp4l(master) is the GrandMaster of the PTP 
> -network but NOT the 'master' serving time out over the entireSystem 
> -network. And ptp4l(master) is a slave to the NTP daemon via 
> 'phc2sys'.
> 
> So having 'phc2sys' use the system clock to update 'ptp4l' isn't an 
> issue since the system clock is only being updated by one program the 
> ntpd deamon.
> 
> 
> 
> 
> 
> OK we are now discussing the following flow configuration (if ptp4l 
> was to be the GrandMaster/PTP-network and 'master' of the
> entireSystem-network):
> 
> 
> 1.      NTP< --system clock<- - phc2sys<-- ptp4l (master) -> network
> out to other PTP slaves --> ptp4l (slave) --> phc2sys --> system clock 
> (No NTP here)
> 
> To perform the NTP syncs PTP master setup, you need to do something
> like:
> 
> 
> 1.      Configure NTP to control the system clock
> 
> 2.      Configure phc2sys to drive the PTP hardware clock on your
> device. Your problem is that this behavior does not allow automatic 
> configuration, because phc2sys can’t switch servos while running.
> Since it will attempt to drive the system time 100% when tuning system 
> time to ptp4l you get the result where NTP attempts to interfere.
> 
> a.      If you do this manually, however, then it won’t automatically
> switch directions for you
> 
> In this case the system running the NTP server (ntpd deamon) would be 
> taking system time and broadcasting it across the entireSystem 
> -network or the 'master' using the Network Timing Protocol (NTP).
> Also running on this same system would be the GrandMaster/PTP 
> -network. There would be NO conflict changing the system clock since 
> 'phc2sys' would be the only program  and the ntpd daemon would be 
> broadcasting it across the entireSystem-network, correct?
> 
> But there is an issue should the GrandMaster fail (removed or powered
> down) in that both the NTP server and GrandMaster would be loss. In 
> this case the remaining slave/PTP-network devices would auto 
> -negotiate another GrandMaster but no NTP server would co-exist. So a 
> program would need to be running in the background on all systems 
> checking for a switch from slave to a GrandMaster/PTP-network device 
> and bring a NTP server up upon detecting a switch from slave to 
> GrandMaster, correct?
> 
> 
> 
> 
> 
> It is possible your device is good enough to actually be the grand 
> -master of time, in which case it could be used to set the system time 
> as well. But that would really only occur if your PTP node is a 
> dedicated clock, and I can’t say I have experience setting one of 
> those up.
> 
> This is a good point and I don't have an answer right now. If just a 
> local PTP-network existed then one of the system could be the NTP 
> server but way when you have the entire local network covered by PTP.
> 
> 
> Thanks,
> Harold
> 
> 
> 
> 
> 
> From: Keller, Jacob E [mailto:jac...@in...]
> Sent: Monday, August 17, 2015 2:09 PM
> To: Harold Lapprich <hla...@pi...>; Miroslav Lichvar 
> <mli...@re...>
> Cc: lin...@li...
> Subject: RE: [Linuxptp-users] Grandmaster Auto-Negotiation and 
> Reconfiguration of phc2sys to ptp4l Synchronization
> 
> Hi,
> 
> Timemaster is a program to help simplify the configuration of the 
> other programs, in that sense, it doesn’t “do” any of the things on 
> its own.
> 
> The flow diagram should be:
> 
> 
> 1.      NTP --> system clock -> phc2sys -> ptp4l (master) -> network
> out to other PTP slaves --> ptp4l (slave) --> phc2sys --> system clock 
> (No NTP here)
> 
> If you’re ptp4l is “master” that means it is serving time out the 
> network and thus is the only time when NTP should be configured it.
> In this case, ptp4l would function as master on the PTP network, but 
> would be the slave of the NTP daemon via phc2sys.
> 
> It is possible your device is good enough to actually be the grand 
> -master of time, in which case it could be used to set the system time 
> as well. But that would really only occur if your PTP node is a 
> dedicated clock, and I can’t say I have experience setting one of 
> those up.
> 
> To perform the NTP syncs PTP master setup, you need to do something
> like:
> 
> 
> 1.      Configure NTP to control the system clock
> 
> 2.      Configure phc2sys to drive the PTP hardware clock on your
> device. Your problem is that this behavior does not allow automatic 
> configuration, because phc2sys can’t switch servos while running.
> Since it will attempt to drive the system time 100% when tuning system 
> time to ptp4l you get the result where NTP attempts to interfere.
> 
> a.      If you do this manually, however, then it won’t automatically
> switch directions for you
> 
> I believe that is the crux if your issue here. In addition, I think 
> you have the notion of slave/master backwards. Slave means that it is 
> receiving time from the network and thus is the “master” time source 
> in the system. Master means it is serving time out the network and is 
> thus the “slave” to the system time. This dual usage of terminology 
> can get confusing.
> 
> Regards,
> Jake
> 
> From: Harold Lapprich [mailto:hla...@pi...]
> Sent: Monday, August 17, 2015 10:16 AM
> To: Miroslav Lichvar
> Cc: Keller, Jacob E; lin...@li...<mailto:
> lin...@li...>
> Subject: RE: [Linuxptp-users] Grandmaster Auto-Negotiation and 
> Reconfiguration of phc2sys to ptp4l Synchronization
> 
> Miroslav,
> 
> Thanks again for the quick response, trying to simplify the discussion 
> and therefore minimize any mis-understanding by providing the 
> following simply flow diagrams:
> 
> Need to support the following 2 scenarios using the 'linuxptp'
> applications but NOT both in the same network configuration (only 1 of 
> the 2 will exist)
> 
>         1. NTP <---- timemaster <---- system clock <---- phc2sys <---
> - 'ptp4l (master)' ----//---->ptp4l (slaves)---->phc2sys---->system 
> clock
> 
>         2. NTP ----> timemaster ----> system clock ----> phc2sys ---
> -> 'ptp4l (master)' ----//----ptp4l (slaves)---->phc2sys---->system
> clock
> 
> Please let me know if the proceeding flow diagrams are NOT correct?
> 
> 
> 
> 
> I. Do you need NTP as a time source? Or just serve time over NTP? The 
> former conflicts with your requirement to allow ptp4l to be a master 
> as phc2sys would need to be the process that synchronizes the clock 
> and not chronyd/ntpd.
> 
> Want the ability to have NTP as a time source or serve time over NTP 
> but not both at the same time (therefore need the capability to do 
> both, 1: when local network configuration is standalone then a network 
> server will be locked to PTP time via PTP-->NTP, and 2: when the local 
> network is a subset of a larger network and therefore NTP -
> -> PTP). The configuration will be a known entity and therefore the
> 'linuxptp' application configuration files created appropriately this 
> is NOT something that needs to happen automatically.
> 
> 
> 
> 
> II. The former conflicts with your requirement to allow ptp4l to be a 
> master as phc2sys would need to be the process that synchronizes the 
> clock and not chronyd/ntpd.
> 
> It is my understanding that 1 of the PTP clients has to be a master 
> (ptp4l master) but the master can be locked to the system clock by 
> phc2sys (this is what I am currently doing, ptp4l -i eth0 and phc2sys 
> -a -r -r).
> Then 'timemaster' would be used to synchronize the system clock to 
> NTP.
> 
>         1. NTP <---- timemaster <---- system clock <---- phc2sys <---
> - 'ptp4l (master)' ----//---->ptp4l (slaves)---->phc2sys---->system 
> clock
> 
> 
> 
> 
> III. The problem is that when phc2sys is configured to feed 
> chronyd/ntpd, it is not able to synchronize the PTP clock in the 
> reverse direction when ptp4l is master.
> 
> It is my understanding that the ptp4l(master) will be driving phc2sys 
> to drive the system clock (1: 'ptp2l -i eth0 -m', 'phc2sys -a -r -r 
> -m'; 2: 'ptp4l -i eth0 -s -m', 'phc2sys -a -r -m'). Or another words 
> PTP master clock will be driving everything.
> 
>         1. NTP <---- timemaster <---- system clock <---- phc2sys <---
> - 'ptp4l (master)' ----//---->ptp4l (slaves)---->phc2sys---->system 
> clock
> 
> 
> 
> 
> Jake Keller
> 
> If you run ptp4l on all your systems, and each one also running 
> phc2sys, it will:
> 
> on system which is "master"
> 
> phc2sys will drive the ptp4l hw clock based on local time
> 
> ptp4l will sync time out the network using PTP
> 
> on systems which are not master
> 
> ptp4l will sync time in from network to hw clock
> 
> phc2sys will sync hw clock to CLOCK_REALTIME.
> 
> 
> Also Jake Keller response: "But if you want to also use NTP as a clock 
> source, then you need to use timemaster, as otherwise phc2sys and ntpd 
> will interfere with each other." Dosen't this imply that using 
> 'timemaster' will remove this issue (phc2sys will synchronize the PTP 
> (master) clock to the system clock and NTP will synchronize the system 
> clock)?
> 
> 
> Harold
> 
> 
> 
> 
> -----Original Message-----
> From: Miroslav Lichvar [mailto:mli...@re...]
> Sent: Monday, August 17, 2015 11:54 AM
> To: Harold Lapprich <hla...@pi...<mailto:
> hla...@pi...>>
> Cc: Keller, Jacob E <jac...@in...<mailto:
> jac...@in...>>; lin...@li...<mail
> to:lin...@li...>
> Subject: Re: [Linuxptp-users] Grandmaster Auto-Negotiation and 
> Reconfiguration of phc2sys to ptp4l Synchronization
> 
> On Mon, Aug 17, 2015 at 02:14:36PM +0000, Harold Lapprich wrote:
> >        "If you run ptp4l on all your systems, and each one also 
> > running phc2sys, it will:
> > 
> >        on system which is "master"
> > 
> >                phc2sys will drive the ptp4l hw clock based on local 
> > time
> > 
> >                ptp4l will sync time out the network using PTP
> > 
> >        on systems which are not master
> > 
> >                ptp4l will sync time in from network to hw clock
> > 
> >                phc2sys will sync hw clock to CLOCK_REALTIME.
> > 
> >        But if you want to also use NTP as a clock source, then you 
> > need to use timemaster, as otherwise phc2sys and ntpd will interfere 
> > with each other."
> 
> Strictly speaking you just need to configure phc2sys to use the NTP 
> SHM servo to feed chronyd/ntpd so they can select the best source or 
> combine multiple sources and synchronize the clock. That's how phc2sys 
> is configured by timemaster.
> 
> Do you need NTP as a time source? Or just serve time over NTP? The 
> former conflicts with your requirement to allow ptp4l to be a master 
> as phc2sys would need to be the process that synchronizes the clock 
> and not chronyd/ntpd.
> 
> If you just need to serve NTP, you can configure chronyd/ntpd to not 
> synchronize the clock and keep phc2sys in the control of the clock.
> 
> > So when NTP is to be the clock source (and vice versa)  then 
> > 'timermaster' is needed because phc2sys and ntpd will interfere with 
> > one another. Now the problem is GrandMaster failure, if I understand 
> > you correctly when another PTP system on the network becomes the 
> > GrandMater 'timemaster' will NOT automatically reconfigure and start 
> > using NTP as the clock source (using timemaster to start PTP 
> > configuration on all systems on the PTP network)?
> 
> The problem is that when phc2sys is configured to feed chronyd/ntpd, 
> it is not able to synchronize the PTP clock in the reverse direction 
> when ptp4l is master.
> 
> > If this is the case then one would have to have another application 
> > running in the background to detect the switch, create the 
> > appropriate 'timemaster' configuration file and start?
> 
> There is currently no way to configure timemaster to serve local time 
> over PTP. phc2sys would need to allow that first.
> 
> --
> Miroslav Lichvar
>