Hi,

I'm trying to setup a Ubuntu server that synchronizes its time via NTP and sends PTPv2 downstream via unicast messages. In my current setup I'm using unicast negotiation. The problem that I'm facing is that after the host sends a "Signalling message" with the requested rate to the server, the server answers with another "Signalling message" granting the requests and then following a number of "Announce message" with originTimestamp (both seconds and nanoseconds) set to zero. My host does not seem to like it and fails to synchronize and request unicast transmission in another "Signalling message". However, I have noticed that the current clock we have running in the network actually sends the originTimestamp with some initial values...

Thanks! Jesus

Hello,

I want to syncronize Android devices via PTP. Is it possible to port ptpd to an Android device?? Or there is a plan for it? I‘m a beginner on PTP. And I want to know which project is recommended for porting? ptpd or linuxptp?

Thank you very much!

I am using ptpd in slave mode. This is the version that I'm using, it is not the newest one, but this one was available from package sources. ptpd -g -b eth0 -D -f /var/log/ptpd/stats.log

Installed: 2.2.2-debian1-2 Candidate: 2.2.2-debian1-2 Version table: *** 2.2.2-debian1-2 0 500 http://ba.archive.ubuntu.com/ubuntu/ trusty/universe amd64 Packages 100 /var/lib/dpkg/status

My master clock is running ptp4l with (hopefully?) hardware timestamping. ptp4l -4 -H -i p1p1

The associated network card doing this is an Intel 82574L.

ethtool output:

Time stamping parameters for p1p1:
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)

Now to the issue.

If I look in the slave log, I see lines like this:

2016-02-22 09:11:24.258947, slv, 6805cafffe39dabc(unknown)/01,  0.000000000,  0.000000365,  0.000000000,  0.000001337, 31081, 0, S
2016-02-22 09:11:25.259040, slv, 6805cafffe39dabc(unknown)/01,  0.000000000,  0.000002293,  0.000000000,  0.000003250, 31083, 0, S
2016-02-22 09:11:26.259097, slv, 6805cafffe39dabc(unknown)/01,  0.000000000,  0.000002104,  0.000000000,  0.000000958, 31085, 0, S
2016-02-22 09:11:27.259169, slv, 6805cafffe39dabc(unknown)/01,  0.000000000,  0.000000642,  0.000000000,  0.000000327, 31085, 0, S

One Way Delay and Slave to Master are 0, my feeling says that this can not be correct, as the one-way-delay should at least be larger than 0. This slave has a Broadcom BCM5754 NIC.

Time stamping parameters for eth1:
Capabilities:
    software-transmit     (SOF_TIMESTAMPING_TX_SOFTWARE)
    software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)
    software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
PTP Hardware Clock: none
Hardware Transmit Timestamp Modes:
    off                   (HWTSTAMP_TX_OFF)
    on                    (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
    none                  (HWTSTAMP_FILTER_NONE)
    ptpv1-l4-event        (HWTSTAMP_FILTER_PTP_V1_L4_EVENT)
    ptpv2-l4-event        (HWTSTAMP_FILTER_PTP_V2_L4_EVENT)
    ptpv2-l2-event        (HWTSTAMP_FILTER_PTP_V2_L2_EVENT)

I also have another slave, same output in the logfile:

2016-02-22 09:13:36.265614, slv, 6805cafffe39dabc(unknown)/01,  0.000000000,  0.000021380,  0.000000000,  0.000030137, -3721, 0, S
2016-02-22 09:13:37.265580, slv, 6805cafffe39dabc(unknown)/01,  0.000000000,  0.000001287,  0.000000000, -0.000027563, -3720, 0, S
2016-02-22 09:13:38.265691, slv, 6805cafffe39dabc(unknown)/01,  0.000000000, -0.000005543,  0.000000000,  0.000016477, -3725, 0, S

The drift here is way better than the other slave, probably because the NIC (Intel 82579LM) on this machine has some hardware timestamping function. But I thought they are not active in ptpd, or is the NIC doing some stuff here?

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: 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)

Is this behaviour correct?

Thank you.

While running ptpd2 v2.3.2 as slave-only I noticed, that ptpd does stop workingcorrectly when no master has been available for a while (>20h)(test if reproducable is running), or the master reports a time near unix time epoch begin for about 20min (reproducable).

A) While no master is available it does this in the event log roughly every minute:

2016-10-13 12:43:20.057055 ptpd2[5407].eth0 (warning)   (lstn_reset) Still in LISTENING after 5 restarts - restarting transports
2016-10-13 12:43:20.422848 ptpd2[5407].eth0 (notice)    (lstn_reset) Now in state: PTP_LISTENING

B) When master is reporting wrong time 01/01/1970 00:xx:xx, then my client dies this every second:

2016-10-13 11:00:42.131852 ptpd2[492].eth0 (notice)    (lstn_reset) Now in state: PTP_LISTENING
2016-10-13 11:00:42.299015 ptpd2[492].eth0 (info)      (lstn_reset) New best master selected: a0369ffffe9240b4(unknown)/1
2016-10-13 11:00:42.299358 ptpd2[492].eth0 (notice)    (slv) Now in state: PTP_SLAVE, Best master: a0369ffffe9240b4(unknown)/1 (IPv4:192.168.209.236)
2016-10-13 11:00:42.769114 ptpd2[492].eth0 (notice)    (slv) Received first Sync from Master
2016-10-13 11:00:42.789209 ptpd2[492].eth0 (critical)  (slv) Offset above 1 second (1476348743.061028957 s). Clock will step.
2016-10-13 11:00:42.789431 ptpd2[492].eth0 (error)     (slv) Could not set system time      (strerror: Invalid argument)

For every A) and B) it also gets two more open sockets, shown below with lsof:

COMMAND  PID USER   FD   TYPE     DEVICE SIZE/OFF   NODE NAME
... <usual ports>
ptpd2   5407 root   15u  sock        0,8      0t0  11455 can't identify protocol
ptpd2   5407 root   16u  sock        0,8      0t0  11552 can't identify protocol
... <increasing list of shown ports>

Once it "stops working", this is what the event log shows every ten seconds:

2016-10-13 11:13:34.812035 ptpd2[492].eth0 (error)     (init) Could not get interface list      (strerror: Too many open files)
2016-10-13 11:13:34.812266 ptpd2[492].eth0 (error)     (init) Failed to initialize network
2016-10-13 11:13:34.812404 ptpd2[492].eth0 (error)     (flt) PTPd init failed - will retry in 10 seconds

I looked through the code, but could not find a place, where sockets are left behind / are not closed.

Attached the event log of a 20 min run, which ended in the "stop working" state. (PTP master falsely reported 01/01/1970 00:00, which caused ptpd2[492].eth0 (error) (slv) Could not set system time (strerror: Invalid argument) and thus ptpd2[492].eth0 (notice) (lstn_reset) Now in state: PTP_LISTENING is executed twice every second. Thus sockets are used up more quickly.) ptpd2_master_wrong_time___ptpd_failed_after_20min.txt

Attached the event log and lsof output of a 2h run without PTP master, which is still ongoing and likely to fail after 20h (prediction). Will come back to this, once I can reproduce it. ptpd2__no_master__2h_elapsed__eventlog.txt ptpd2_master_wrong_time___ptpd_failed_after_20min.txt

I configured integration of PTPd with NTPd and when I start PTPd I'm getting following warning message:

TimingService.NTP0: Could not start NTP service. Will keep retrying.

After adding enable mode7 in ntp.conf I managed to fix this issue. Seems that PTPd uses deprecated NTP stuff (see this thread).

when you build the rpms with ./rpmbuild.sh --tag, it now makes rpms like ptpd-2.3.2-1.el6.1466165333.fb3ef76.x86_64.rpm

the tag format is <timestamp of last commit>.<short last commit hash>

if you use the --service2 option, it will generate a ptpd2 service (instead of default ptpd)

Quorum of Grandmaster Clocks or a Quorum of any PTPd clients-servers

RE NTP-SEC Quorum Fix

NTP-org only recently fixed a long running "Security Issue" by requiring client-server sync to only be made final or doable if and only if there is a quorum of available NTP servers (LOCAL or GLOBAL).

The way PTPd seems to depend on "one and only one" or at best local 2 Grandmasters is just begging for spoofing, local or global.

There is NO DEFAULT CONFIG for most LINUX BRANCHES -- so it all just begs for trouble.

As most PTP configs have NTP also running, this massive security and reliability problem has been hidden by over-provisioning.

PTP should be able to run SOLO like NTP, and work with reasonably better reliability.

EVP_MD_CTX can conflict with openssl that defines a completely different typedef with same name.

Since this typedef is used only twice in the entire ptpd, substitute EVP_MD_CTX with EVP_MD5_CTX.

Signed-off-by: Giulio Benetti [email protected]

I want to synchronize a slave cpu to a master cpu. The ptpd in masteronly mode runs perfectly. But I have problems with the ptpd in slaveonly mode. After some hours it is dead and I have to kill it (kill -8) an restart it.

Version: ptpd v2.3.1 Hardware: IMX6

This is how I startet ptpd:

# strace -o strace.log /usr/bin/ptpd2 --config-file /etc/ptpd.conf -C
Warning: It is recommended to set the delay request interval (ptpengine:log_dela
yreq_interval) in unicast mode
2016-06-16 06:04:36.195419 ptpd2[438].startup (info)      (___) Configuration OK
2016-06-16 06:04:36.209302 ptpd2[438].startup (info)      (___) Successfully acquired lock on /var/run/ptpd2.lock
2016-06-16 06:04:36.218048 ptpd2[438].startup (notice)    (___) PTPDv2 started successfully on eth0.2 using "slaveonly" preset (PID 438)
2016-06-16 06:04:36.219717 ptpd2[438].startup (info)      (___) TimingService.PTP0: PTP service init

I use unicast mode but I also had the same problem in multicast mode. The logs of the ptpd are attached and I also added my pdpd.conf and a shortend strace log.

I can't recognize any error, but maybe someone else could help me. I also can provide more information if needed.

ptp-strace-short.log.txt ptpd.conf.txt ptpd2.event.log.txt ptpd2.stats.log.txt ptpd2.status.log.txt

Thanks Chris

I have a use case where a single machine runs multiple daemons in parallel where each is bound to separate interface. One daemon runs as a slave while the others run as masters. The idea here is that the slave daemon sets the local time while the master daemons synchronize with computers connected to the associated interface. There are two distinct issues I've encountered in configuring the daemons:

1. When a daemon is in slave only mode and told to ignore lock files, it does not synchronize with the grand master, nor does it respond to management messages. The .status file shows that the daemon stays in a listening mode with no RX packets received. When using the default locking mechanism (no option passed), it works as expected - it enters slave mode and responds to management messages.
2. When the daemon is in masterslave mode and passed the argument to ignore lock files, it does not respond to management messages, but does synchronize properly with a slave located on another machine. When using the default locking mechanism (no option passed), it works as expected - it responds to management messages.

• I have tested the above with both short and long versions of the flags as well as passing a configuration file.
• I have used both a hard and soft grand master - no change.
• I am running CentOS 6.6

It seems that every minute the follow up messages are delayed. I've attached a corresponding wireshark capture. The first delayed packet is number 144. ptpd2-syncfup-interval.zip

Hello blogger, to realize ptp2 using hardware timestamp for time synchronization, in addition to the MAC to support hardware timestamp, does the source code of ptpd2 need to be modified? Or what configuration does ptpd2 need to do?

Is there any API provided in linux to read the master slave delay or offset from master. For QNX, there is support provided through DCMD_PTPD using devctl. Link : http://www.qnx.com/developers/docs/7.0.0/index.html#com.qnx.doc.neutrino.devctl/topic/ptpd/dcmd_ptpd_delayms.html Is there any way to fetch these details in Linux.

Any suggestions are welcome.

I have a grandmaster clock that doesn't set UTC Reasonable until it receives a GNSS time. I'd like to have PTPD not sync time until the reasonable bit is set the first time. Does current code support that capability?

I keep getting the above error when launching on a bridge network:

sudo ptpd -i br0 -L -M -V
2022-02-08 16:58:12.835012 ptpd2[31029].startup (info)      (___) Configuration OK
2022-02-08 16:58:12.838644 ptpd2[31029].startup (notice)    (___) PTPDv2 started successfully on br0 using "masteronly" preset (PID 31029)
2022-02-08 16:58:12.838669 ptpd2[31029].startup (info)      (___) TimingService.PTP0: PTP service init
# Timestamp, State, Clock ID, One Way Delay, Offset From Master, Slave to Master, Master to Slave, Observed Drift, Last packet Received, One Way Delay Mean, One Way Delay Std Dev, Offset From Master M
ean, Offset From Master Std Dev, Observed Drift Mean, Observed Drift Std Dev, raw delayMS, raw delaySM
2022-02-08 16:58:12.838687, init, 
2022-02-08 16:58:12.847963 ptpd2[31029].br0 (error)     (init) error while setting outgoig multicast interface (IP_MULTICAST_IF)      (strerror: Invalid argument)
2022-02-08 16:58:12.848197 ptpd2[31029].br0 (error)     (init) Failed to initialize network
2022-02-08 16:58:12.848213, flt, 
2022-02-08 16:58:12.848220 ptpd2[31029].br0 (error)     (flt) PTPd init failed - will retry in 10 seconds
2022-02-08 16:58:12.848229, init, 
2022-02-08 16:58:22.838695 ptpd2[31029].br0 (notice)    (init) TimingService.PTP0: elected best TimingService
2022-02-08 16:58:22.838741 ptpd2[31029].br0 (info)      (init) TimingService.PTP0: acquired clock control
2022-02-08 16:58:23.071723 ptpd2[31029].br0 (error)     (init) error while setting outgoig multicast interface (IP_MULTICAST_IF)      (strerror: Invalid argument)
2022-02-08 16:58:23.072059 ptpd2[31029].br0 (error)     (init) Failed to initialize network
2022-02-08 16:58:23.072183, flt, 
2022-02-08 16:58:23.072192 ptpd2[31029].br0 (error)     (flt) PTPd init failed - will retry in 10 seconds
2022-02-08 16:58:23.072230, init,