This is useful when dealing with timestamps returned by various
ancillary PHC ioctl kernel APIs, such as extts.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
The capability command for phc_ctl does not display the number of pins
or the cross timestamping support. Add this as output so that the user
can see the complete device capabilities.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
The API to obtain the time stamp of a PPS source indicates the validity of
the returned value. However, the current code does not ever test the
validity information in any way. This patch lets the clients ignore PPS
values that lack a valid time stamp.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Each slave creates an instance of a servo. However, when cleaning up, the
code neglected to free the servo, resulting in a memory leak. This patch
fixes the issue by calling the appropriate method to destroy the servo.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
When creating a ts2phc slave, a clock is obtained by invoking the
posix_clock_open() method. However, in case of an error, the same clock
is closed again by calling close(2) on the associated file descriptor
directly. While not incorrect, still the code should instead use the
close function that matches the open method.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Currently it is very finicky to deploy linuxptp in an automated build
system and make KBUILD_OUTPUT pick up the output of "make
headers_install" in order for the application to make full use of the
features exposed by the runtime kernel. And the toolchain/libc will
almost certainly never contain recent enough kernel headers to be of any
use here. And there's no good reason for that: the application can probe
at runtime for the sysoff methods supported by the kernel anyway.
So let's provide the kernel definitions for sysoff, sysoff_precise and
sysoff_extended, such that SYSOFF_COMPILE_TIME_MISSING is not something
that will bother us any longer.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
The poll(2) system call may set POLLERR in the returned events. Normally
no errors are returned unless specifically requested by setting an
appropriate socket option. Nevertheless, the poll(2) API is quite generic,
and there is no guarantee that the kernel networking stack might push an
error event one day. This patch adds defensive code in order to catch any
unexpected error condition.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
This saves a few bytes of static storage and less instructions are
executed when looking for the best offset.
Signed-off-by: Georg Sauthoff <mail@gms.tf>
ptp4l is too silent when receiving, for whatever reason, out of order
messages. If the reordering is persistent (which is either a broken
network, or a broken kernel), the behavior looks like a complete
synchronization stall, since the application is designed to never
attempt to recover from such a condition.
At least save some people some debugging hours and print when the
application reaches this code path. Since it's a debugging tool, we
don't want to create false alarms when the occasional packet gets
reordered in a production system, but have this information readily
available when the program's log level is set to debug, instead of
having users fish for it with code instrumentation.
[ RC - corrected printf format for sequence id. ]
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
The application's main event loop (clock_poll) is woken up by poll() and
dispatches the socket receive queue events to the corresponding ports as
needed.
So it is a bug if poll() wakes up the process for data availability on a
socket's receive queue, and then recvmsg(), called immediately
afterwards, goes to sleep trying to retrieve it. This patch will
generate an error that will be propagated to the user if this condition
happens.
Can it happen?
As of this patch, ptp4l uses the SO_SELECT_ERR_QUEUE socket option,
which means that poll() will wake the process up, with revents ==
(POLLIN | POLLERR), if data is available in the error queue. But
clock_poll() does not check POLLERR, just POLLIN, and draws the wrong
conclusion that there is data available in the receive queue (when it is
in fact available in the error queue).
When the above condition happens, recvmsg() will sleep typically for a
whole sync interval waiting for data on the event socket, and will be
woken up when the new real frame arrives. It will not dequeue follow-up
messages during this time (which are sent to the general message socket)
and when it does, it will already be late for them (their seqid will be
out of order). So it will drop them and everything that comes after. The
synchronization process will fail.
The above condition shouldn't typically happen, but exceptional kernel
events will trigger it. It helps to be strict in ptp4l in order for
those events to not blow up in even stranger symptoms unrelated to the
root cause of the problem.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
On some platforms, time_t has recently switched from "long" to "long
long" [1]. For these platforms it is necessary to use "%lld" as printf
format specifier because the ABI differs between "long" and "long long".
I found no way for creating something similar to PRId64 for time_t. No
idea how to determine whether it's "long" or "long long". So I cast
everything to "long long" instead.
[1] https://git.musl-libc.org/cgit/musl/commit/?id=38143339646a4ccce8afe298c34467767c899f51
Signed-off-by: Christian Eggers <ceggers@arri.de>
After a successful message exchange, the delay measurement values are
processed by the port code. This patch makes the values available to a
monitor by calling the appropriate method.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
The slave delay timing data TLV provides the delay time stamps along with
the associated correction field. This patch introduces a method to allow
publication of these values to a remote monitor.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
The monitoring module accepts Sync timing events. This patch hooks up the
port receive path to call into the monitor.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
This patch adds a new module for slave event monitoring with its own
configuration option, a UDS address. If the option is enabled, then
the monitor will send events to the configured address. The default
setting produces an inactive monitor that does nothing.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
The 2019 version of 1588 known as v2.1 introduces new TLV type and
management IDs. This patch adds the new definitions.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
The current code truncates the size of path trace TLVs which exceed the
expected maximum based on the largest possible message size. However if
another TLV follows, then a gap would appear, that is, an area in the
message buffer not pointed to by any TLV descriptor. In order to avoid
forwarding such malformed messages, this patch changes the logic to reject
them.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Code in other modules will need this special port ID value. This patch
makes it available through the port header file.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
The utility function to compare port IDs takes pointers, but it only needs
to read the referenced data. This patch marks the parameters as const,
allowing passing constants in the future.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
The port_forward_to() method clobbers the specific error code returned
by the transport layer with -1. This patch lets the code preserve the
specific error in question.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
The transport layer's functional interface foresees having error codes
percolate back up to the caller. However, up until now, the sk module
simply returned -1 for any error. This patch lets the code return the
specific error instead.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
The transport layer's functional interface foresees having error codes
percolate back up to the caller. However, up until now, the raw module
simply returned -1 for any error. This patch lets the code return the
specific error instead. In addition, it removes the gratuitous printing
of the error message, leaving that task up to caller, just like the other
transport modules.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
The transport layer's functional interface foresees having error codes
percolate back up to the caller. However, up until now, the uds module
simply returned -1 for any error. This patch lets the code return the
specific error instead. In addition, it removes the gratuitous printing
of the error message, leaving that task up to caller, just like the other
transport modules.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
The transport layer's functional interface foresees having error codes
percolate back up to the caller. However, up until now, the udp6 module
simply returned -1 for any error. This patch lets the code return the
specific error instead.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
The transport layer's functional interface foresees having error codes
percolate back up to the caller. However, up until now, the udp module
simply returned -1 for any error. This patch lets the code return the
specific error instead.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
When using the "free running" option, a slaved port remains in the
UNCALIBRATED state. If the actual servo resides in and external program,
for example when following the 802.1AS recommendations, that program can
signal the synchronization state using the "synchronization uncertain"
management message. This patch lets the port state transitions from
UNCALIBRATED to SLAVE based on that message.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
IEEE 1588 v2.1 and ITU G.8275.1/2 call for an optional "synchronization
uncertain" flag passed in Announce messages along with the other flags
from the time properties data set. The value of the flag depends is a
logical OR function of the inputs from the remote master and the local
process. This patch adds background support for handling the flag.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Recently the Linux kernel's PTP Hardware Clock interface was expanded
to include a "write phase" mode where the clock servo in implemented
in hardware. This mode hearkens back to the tradition ntp_adjtime
interface, passing a measured offset into the kernel's servo.
This patch adds a new configuration option and logic to support the
write phase mode.
Because the hardware's adjustment bandwidth may be limited, this mode
is only activated when the servo reaches SERVO_LOCKED_STABLE state, in
order to achieve reasonably fast locking times. Users may control the
SERVO_LOCKED_STABLE state by configuring 'servo_offset_threshold' and
'servo_num_offset_values' accordingly.
Example configuration file highlights:
unicast_listen 1
logSyncInterval 0
logMinDelayReqInterval 0
first_step_threshold 0.001000000
step_threshold 0
clock_servo pi
write_phase_mode 1
servo_offset_threshold 50
servo_num_offset_values 10
tsproc_mode raw
Signed-off-by: Vincent Cheng <vincent.cheng.xh@renesas.com>
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
The logic for the Automotive Profile added a message interval update
mechanism that triggers whenever the servo enters the "stable locked"
state. This SERVO_LOCKED_STABLE state is active when the
configuration option servo_offset_threshold is non-zero and
servo_offset_threshold criteria is satisfied.
However, in general, the state of the servo can and should be
independent of any profile specific optional behavior. In particular,
the "stable locked" state will be used in the future to trigger other
kinds useful logic. For example, an upcoming write phase mode feature
would like to take advantage of the SERVO_LOCKED_STABLE state to
trigger its activation.
This patch introduces a proper configuration option to enable
transmission of the message interval request that is specific to the
Automotive Profile.
Signed-off-by: Vincent Cheng <vincent.cheng.xh@renesas.com>
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Many GPS radios provide both a 1-PPS and time of day information via
NMEA sentences. This patch introduces a ts2phc master that decodes
the "recommended minimum data" sentence, RMC, which provides UTC time
and a validity flag. Together with the file based leap second table,
this sentence provides adequate time of day for determining the time
of the PPS edge.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
There are several issues surrounding leap seconds that emerge when a clock
takes on the Grand Master role. One of them is the fact that GPS radios
provide time of day in the UTC time scale and not in TAI, and they do not,
in general, provide any conversion information. Another issue is the
expectation that the GM provide correct leap second status flags to the
network. Although both NTP and GPS do, in theory, provide on-line leap
second status, in practice the information is not reliable due to poor
implementations.
In order to provide correct leap second status and TAI - UTC offsets,
this patch introduces a leap second table based on the information
published by the IETF and NIST. The hard coded default table can be
updated at run time by reading the standard leap seconds file from the
commonly used tzdata package.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
This patch introduces a new ts2phc source using a PHC device. There
are multiple use cases for such a master. By connecting pins of two
or more separate PHC devices together, one may act as the source, and
the others may be synchronized to it in hardware. In this way, "just
a bunch of devices" together forms a Transparent Clock. If the master
clock is synchronized to a global time source (like a PPS from a GPS),
then the system becomes a mutli-port Grand Master or a Boundary Clock
with GM capability.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Some PTP Hardware Clocks have input pins that can generate time stamps
on the edges of external signals. This functionality can be used in
various ways. For example, one can synchronize a PHC device to a
global time source by taking a Pulse Per Second signal from the source
into the PHC. This patch adds support for synchronizing one or more
PHC slaves to a given master clock.
The implementation follows a modular design that allows adding
different kinds of master clocks in the future. This patch starts off
with a single "generic" PPS master, meaning a PPS signal that lacks
and time or date information. The generic master assumes that the
Linux system time is approximately correct (by NTP or RTC for example)
in order to calculate the time of the incoming PPS edges.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: Balint Ferencz <fernya@gmail.com>
If more than one local UDS client subscribes to push notifications,
only the last one receives data from the ptp4l service. This happens
because ptp4l uses the PortIdentity as a unique key to track client
subscriptions. As a result, it is not possible for both phc2sys and
pmc to receive push notifications at the same time, for example.
This patch sets the PortIdentity.portNumber attribute of UDS clients
to the local process ID, making each such client subscription unique.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Allow interactive input like
set SUBSCRIBE_EVENTS_NP duration 60 NOTIFY_PORT_STATE on
to request push notifications from the ptp4l service.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
The header file, pmc_common.h, makes some private macros public. The
intent was to use those macros in SNMP code, but that development never
materialized into production code. This patch removes the private macros
from public view.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
The clock layer indeed replies to management GET actions for this item,
but it sends an empty management message by mistake. This patch fixes the
issue by replying with a payload of the correct length.
While we are at it, correct overly zealous line breaking according to our
coding style.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Currently there is a method to convert a timespec into a tmv_t, but
not the other way round. This patch adds the missing function in
anticipation of a new feature that will need this conversion.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Vladimir Oltean
Jacob Keller
Richard Cochran
Georg Sauthoff
Werner Macho
Christian Eggers
Vincent Cheng