> -Original Message-
> From: Vladimir Oltean
> Sent: Monday, November 22, 2021 4:38 PM
> To: richardcoch...@gmail.com
> Cc: linuxptp-devel@lists.sourceforge.net
> Subject: [Linuxptp-devel] [PATCH 2/2] util: fix dangling file descriptors on
> the
> error path of posix_clock_open
>
>
> -Original Message-
> From: Keller, Jacob E
> Sent: Monday, November 22, 2021 5:23 PM
> To: Vladimir Oltean ; richardcoch...@gmail.com
> Cc: linuxptp-devel@lists.sourceforge.net
> Subject: RE: [Linuxptp-devel] [PATCH 2/2] util: fix dangling file descriptors
> on the
> error path of
When we determine that the "device" argument represents a path to a char
device, we call phc_open() and then we attempt to see, if the device
real path starts with "/dev/ptp", what number comes afterwards. If that
fails, we should close the char device we've just opened.
Fixes: 380d023abb1f
Ed uses the ptp_kvm driver with phc2sys, and Debian 10 has an udev rule
which creates a symlink for this device called /dev/ptp_kvm.
/lib/udev/rules.d/50-udev-default.rules:
SUBSYSTEM=="ptp", ATTR{clock_name}=="KVM virtual PTP", SYMLINK += "ptp_kvm"
Since the blamed patch, posix_clock_open(),
Now that we are registering a clock even for the PPS source when it
supports that (i.e. when it is a PHC), introduce a new API to retrieve
its clock in order to add timestamps to it.
The timestamps are a mere approximation. We configure the kernel to emit
periodic output and then never hear back
The previous patches have established that:
- a PPS sink deals with extts events
- a clock deals with synchronization via a servo loop
Therefore, the code for synchronization should not be part of the
implementation of a PPS sink. Move it to the main ts2phc.c.
This allows it to be used by a PPS
Make this information more visible by default, since it is the key
output of this program.
Signed-off-by: Vladimir Oltean
Reviewed-by: Jacob Keller
---
v4->v5: rebase on top of the variable renames
v1->v4: none
ts2phc_pps_sink.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
As discussed in this email thread:
https://sourceforge.net/p/linuxptp/mailman/message/37047555/
there is a desire to synchronize multiple DSA switches in a
boundary_clock_jbod setup, using a PPS signal, and the ts2phc program
already offers a solid base.
This patch series extends the ts2phc
The ts2phc program will introduce clock synchronization which is
orthogonal to the direction in which PPS is emitted (from the master
to the slave).
To have a more consistent terminology, we can avoid using the
ultra-generic term "slave" and replace it with "PPS sink", which
describes the role of
Eliminate the ad-hoc use of global variables in the ts2phc program by
introducing one data structure that incorporates them. This might make
the code more understandable to people coming from a kernel background,
since it resembles the type of data organization used there. It is also
now closer to
This propagates the use of "struct ts2phc_private" all the way into the
PPS source API, in preparation of a new use case that will be supported
soon: some PPS sources (to be precise, the "PHC" kind) instantiate a
struct clock which could be disciplined by ts2phc.
When a PHC A emits a pulse and
At the moment, a clock which emits PPS is not synchronizable, and
therefore called "master", and a clock which timestamps PPS is
synchronizable, and therefore called "slave".
The ts2phc program is preparing to decouple the concept of clock
synchronization from the concept of who emits PPS and who
The ts2phc program will introduce clock synchronization which is
orthogonal to the direction in which PPS is emitted (from the master
to the slave).
To have a more consistent terminology, we can avoid using the
ultra-generic term "master" and replace it with "PPS source", which
describes the role
Monitor the port state change events from ptp4l, and use that
information to determine the "reference" clock.
Then synchronize all other clocks in our list to that source, by feeding
into their respective servo loop an offset equal to the delta between
their timestamp and the timestamp of the
Currently in ts2phc, PPS sinks are also the only candidates for the
clocks that get synchronized. There are 2 aspects that make this too
restrictive:
- Not all PPS sinks may be target clocks for synchronization. Consider a
dynamic environment of multiple DSA switches using boundary_clock_jbod,
This introduces the '-a' option in ts2phc, an option inspired from
phc2sys that puts the clocks in "automatic" mode. In this mode, ts2phc
listens, as a PMC, to port state change events from ptp4l, and detects
which port state machine, if any, has transitioned to PS_SLAVE. That
port's clock will
This API was introduced for 2 reasons:
1. Some hardware can emit PPS signals but not starting from arbitrary
absolute times, but rather just emit at a certain phase offset from
the beginning of each second. We _could_ patch ts2phc to always
specify a start time of 0.0 to
Enforce type correctness and make all callers of pmc_agent_query_port_properties
pass an enum port_state argument instead of plain int.
Signed-off-by: Vladimir Oltean
---
v4->v5: patch is new
phc2sys.c | 6 --
pmc_agent.c | 2 +-
pmc_agent.h | 3 ++-
3 files changed, 7 insertions(+), 4
hi,
step_threshold default config is 0.0. Hence it was not doing time-sync when
moving from s0 to s2 via s1. After changing value of step_threshold, time-sync
is happening.
Question: Any reason as to why step_threshold is set 0.0? What should be the
proper value?
Also first_step_threshold
hi,
phc2sys has 3 phases
1) unlock (s0, SERVO_UNLOCKED
2) time-sync (s1, SERVO_JUMP)
3) freq-sync (s2, SERVO_LOCKED)
Based on the log capture below:
Nov 10 03:49:05 phc2sys: [21956.824] CLOCK_REALTIME phc offset 8 s2
freq +9775 delay 2252
Nov 4 12:50:40 ptp4l: [21957.406] rms 3
20 matches
Mail list logo
