On Tue, Aug 30, 2022 at 09:30:33AM +0200, Kurt Kanzenbach wrote:
> ptp4l supports setting of socket priority. This is useful for traffic shaping
> e.g., utilizing Tx steering using TAPRIO or mqprio Qdisc or VLAN egress
> mappings.
Why can't Qdisc use the dialed dscp_event and dscp_general
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,
PMC agents such as phc2sys tend to suppress uninteresting port state
transitions, to avoid running useless code when nothing really changed
in ptp4l.
With the addition of a PMC agent in ts2phc, it becomes desirable to
place that logic in a common implementation file, to avoid duplication.
Choose
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
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
Previous changes/clarifications to ts2phc 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
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 of periodic output transitions are not really known.
We configure the kernel to emit periodic
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
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
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
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 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
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
---
v5->v6: none
v4->v5: rebase on top of the variable renames
v1->v4: none
ts2phc_pps_sink.c | 4 ++--
1 file changed, 2 insertions(+), 2
Hi,
Any more review comments related to this patch or is there a chance it could be
accepted?
BR,
Magnus Armholt
> -Original Message-
> From: Magnus Armholt
> Sent: tiistai 9. elokuuta 2022 8.26
> To: linuxptp-devel@lists.sourceforge.net
> Cc: Magnus Armholt
> Subject: [PATCH v5]
On Tue Aug 30 2022, Erez wrote:
>> There already are two sockets. One for event messages and another for
>> everything else. A (multicast) PTP server sends event messages at a
>> constant rate. The rate of other messages depends on the number of
>> clients and rate of their requests.
>>
>
> Yet I
On Tue, 30 Aug 2022 at 12:52, Miroslav Lichvar wrote:
> On Tue, Aug 30, 2022 at 12:43:24PM +0200, Erez wrote:
> > On Tue, 30 Aug 2022 at 12:28, Miroslav Lichvar
> wrote:
> >
> > > On Tue, Aug 30, 2022 at 09:30:33AM +0200, Kurt Kanzenbach wrote:
> > > > ptp4l supports setting of socket priority.
On Tue, 30 Aug 2022 at 13:22, Maciek Machnikowski
wrote:
> On Wed, Aug 24, 2022 at 04:32:21PM +0530, SyncMonk Technologies wrote:
> > Adding virtual port support for ts2phc.
> >
> > Signed-off-by: Greg Armstrong
> > Signed-off-by: Leon Goldin
> > Signed-off-by: Vipin Sharma
> > Signed-off-by:
Hi Maciek,
Thanks for pointing this out. There was a memory leak as well. We have
fixed it and will be updating the patch set.
Thanks,
Devasish Dey
SyncMonk Technologies.
On Tue, 30 Aug 2022 at 16:56, Maciek Machnikowski
wrote:
> On Wed, Aug 24, 2022 at 04:32:22PM +0530, SyncMonk
Hi Maciek,
Thanks for pointing it out. We will update the patch set name. It was a
mistake as we were working on the APTS feature.
The virtual port is added to have announce message from the External source
for BMCA participation so that it becomes a selection source along with
other ports for
On Wed, Aug 24, 2022 at 04:32:22PM +0530, SyncMonk Technologies wrote:
> adding APTS to participate in BMCA
>
> Passing the announce message for external source to ptp4l using virtual
> port to avoid selection of master from PTP source.
>
> Signed-off-by: Greg Armstrong
> Signed-off-by: Leon
On Wed, Aug 24, 2022 at 04:32:21PM +0530, SyncMonk Technologies wrote:
> Adding virtual port support for ts2phc.
>
> Signed-off-by: Greg Armstrong
> Signed-off-by: Leon Goldin
> Signed-off-by: Vipin Sharma
> Signed-off-by: Devasish Dey
> ---
> makefile | 6 +-
> ts2phc_vport.c | 282
On Wed, Aug 24, 2022 at 04:32:20PM +0530, SyncMonk Technologies wrote:
> Adding virtual port support to ptp4l
>
> Signed-off-by: Greg Armstrong
> Signed-off-by: Leon Goldin
> Signed-off-by: Vipin Sharma
> Signed-off-by: Devasish Dey
> +.B vport_address
> +Specifies the address of UNIX
On Tue, Aug 30, 2022 at 12:43:24PM +0200, Erez wrote:
> On Tue, 30 Aug 2022 at 12:28, Miroslav Lichvar wrote:
>
> > On Tue, Aug 30, 2022 at 09:30:33AM +0200, Kurt Kanzenbach wrote:
> > > ptp4l supports setting of socket priority. This is useful for traffic
> > shaping
> > > e.g., utilizing Tx
On Tue, Aug 30, 2022 at 12:42:03PM +0200, Kurt Kanzenbach wrote:
> On Tue Aug 30 2022, Miroslav Lichvar wrote:
> > Is it useful to set the priority for non-event messages? Their timing
> > is not so important and there can be a lot of traffic generated
> > remotely (e.g. management messages).
>
>
On Tue, 30 Aug 2022 at 12:28, Miroslav Lichvar wrote:
> On Tue, Aug 30, 2022 at 09:30:33AM +0200, Kurt Kanzenbach wrote:
> > ptp4l supports setting of socket priority. This is useful for traffic
> shaping
> > e.g., utilizing Tx steering using TAPRIO or mqprio Qdisc or VLAN egress
> > mappings.
>
On Tue Aug 30 2022, Miroslav Lichvar wrote:
>> @@ -196,6 +196,19 @@ static int udp_open(struct transport *t, struct
>> interface *iface,
>> pr_warning("Failed to set general DSCP priority.");
>> }
>>
>> +socket_priority = config_get_int(t->cfg, "global",
On Tue, Aug 30, 2022 at 09:30:33AM +0200, Kurt Kanzenbach wrote:
> ptp4l supports setting of socket priority. This is useful for traffic shaping
> e.g., utilizing Tx steering using TAPRIO or mqprio Qdisc or VLAN egress
> mappings.
>
> However, that's only implemented for Layer 2 transport. Extend
On Wed, Aug 24, 2022 at 04:32:19PM +0530, SyncMonk Technologies wrote:
> Adding virtual PTP port support
> As per G.8275 (Annex-B) including virtual PTP ports on a PTP clock. This
> virtual port will be used to support APTS, IWF between different
> clock_domains.
Please name the patchset
ptp4l supports setting of socket priority. This is useful for traffic shaping
e.g., utilizing Tx steering using TAPRIO or mqprio Qdisc or VLAN egress
mappings.
However, that's only implemented for Layer 2 transport. Extend this for UDPv4
and UDPv6 transports. Update the man page accordingly.
29 matches
Mail list logo
