[Linuxptp-devel] [PATCH] Fix the descriptions of "G.8275.portDS.localPriority" and "G.8275.defaultDS.localPriority" in ptp4l man page.
The descriptions of "G.8275.portDS.localPriority" and "G.8275.defaultDS.localPriority" in ptp4l man page says that these options are only used when "dataset_comparison" is set to "telecom". But the possible values for "dataset_comparison" are "ieee1588" and "G.8275.x". The valid value is "G.8275.x" not "telecom". Signed-off-by: Tomofumi Yoshida --- ptp4l.8 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ptp4l.8 b/ptp4l.8 index 8c2969f..9e9fba7 100644 --- a/ptp4l.8 +++ b/ptp4l.8 @@ -324,7 +324,7 @@ comparison algorithm. The value of this option is associated with Announce messages arriving on a particular port and is used as a tie breaker whenever clockClass, clockAccuracy, offsetScaledLogVariance, and priority2 are equal. This option is only used when -"dataset_comparison" is set to "telecom". +"dataset_comparison" is set to "G.8275.x". The default value is 128. Warning: the BMCA is guaranteed to produce a spanning tree (that is, a @@ -451,7 +451,7 @@ alternate Best Master Clock Algorithm (BMCA) with a unique data set comparison algorithm. The value of this option is associated with the local clock and is used as a tie breaker whenever clockClass, clockAccuracy, offsetScaledLogVariance, and priority2 are equal. This -option is only used when "dataset_comparison" is set to "telecom". +option is only used when "dataset_comparison" is set to "G.8275.x". The default value is 128. Warning: the BMCA is guaranteed to produce a spanning tree (that is, a -- 2.34.1 ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 1/1] Fix management TLV print.
On Mon, Mar 07, 2022 at 03:57:19PM +0100, Erez Geva wrote: > Use proper management TLV name in print. > Use a simple 16 unsigned bits format. > Follow standard name for number of records in a table. > > Signed-off-by: Erez Geva > --- > pmc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/pmc.c b/pmc.c > index 7916153..ab36856 100644 > --- a/pmc.c > +++ b/pmc.c > @@ -545,8 +545,8 @@ static void pmc_show(struct ptp_message *msg, FILE *fp) > break; > case MID_UNICAST_MASTER_TABLE_NP: > umtn = (struct unicast_master_table_np *) mgt->data; > - fprintf(fp, "MID_UNICAST_MASTER_TABLE_NP " > - IFMT "actual_table_size %" PRIu16, > + fprintf(fp, "UNICAST_MASTER_TABLE_NP " Dropping MID_ prefix = good catch > + IFMT "actualTableSize %hu", but fields of unicast_master_table_np are all lower case following our Codingstyle (custom stuff avoids camelCase) > umtn->actual_table_size); See? --- ^^ Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCHv5 2/2] ptp4l: get bond phc directly if kernel support the new hwtstamp flag
On Fri, Jan 21, 2022 at 12:42:49PM +0800, Hangbin Liu wrote:
> In clock_create(), try get ts info first, if failed, try the old way.
How does this sentence relate to this...
> @@ -1001,10 +1001,16 @@ struct clock *clock_create(enum clock_type type,
> struct config *config,
> c->timestamping = timestamping;
> required_modes = clock_required_modes(c);
> STAILQ_FOREACH(iface, &config->interfaces, list) {
> - memset(ts_label, 0, sizeof(ts_label));
> - if (!rtnl_get_ts_device(interface_name(iface), ts_label))
> - interface_set_label(iface, ts_label);
> - interface_get_tsinfo(iface);
> + /* try find lowerlay device if we can't get iface tsinfo
> directly */
> + if (interface_get_tsinfo(iface) ||
> + (interface_tsinfo_valid(iface) &&
> + !interface_tsmodes_supported(iface, required_modes))) {
> + memset(ts_label, 0, sizeof(ts_label));
> + if (!rtnl_get_ts_device(interface_name(iface),
> ts_label))
> + interface_set_label(iface, ts_label);
> + interface_get_tsinfo(iface);
> + }
I really have no idea what this is supposed to do.
Why test for
interface_tsinfo_valid(iface) && !interface_tsmodes_supported(iface,
required_modes)
twice in a row !?!?!?
> +
> if (interface_tsinfo_valid(iface) &&
> !interface_tsmodes_supported(iface, required_modes)) {
See that ? ^^^
Thanks,
Richard
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Inconsistent remote timestamps in the P2P mode
On Fri, Nov 19, 2021 at 03:16:49AM -0800, Methlal Pallewatta wrote: > In the section 6.6.4 (page 35) of the IEEE Std 1588-2008 the following is > stated about the port 2 in the P2P mode. > > Port-2 either: > 1. returns the difference between the timestamps t2 and t3 in the > Pdelay_Resp message > 2. returns the difference between the timestamps t2 and t3 in a > Pdelay_Resp_Follow_Up message > 3. returns the timestamps t2 and t3 in the Pdelay_Resp and > Pdelay_Resp_Follow_Up messages, > respectively Yes, but actually, the exact steps are spelled out starting on page 114: 11.4.3 Peer delay mechanism operational specifications > I found that the IXIA master that I used was using option 2 and was not > sending the actual timestamp t2 but sending out 0 instead. The action of the "delay requestor" is the same in any case, and this is spelled out starting on page 115: 1) Generate timestamp t4 upon receipt of the Pdelay_Resp message 2) If asymmetry corrections are required, modify the correctionField of the Pdelay_Resp message per 11.6.5 3) If the twoStepFlag of the received Pdelay_Resp message is FALSE, indicating that no Pdelay_Resp_Follow_Up message will be received, compute the as: = [(t4 - t1) - correctionField of Pdelay_Resp]/2 4) If the twoStepFlag of the received Pdelay_Resp message is TRUE indicating that a Pdelay_Resp_Follow_Up will be received, compute the as follows: = [(t4 - t1) - (responseOriginTimestamp - requestReceiptTimestamp) - correctionField of Pdelay_Resp - correctionField of Pdelay_Resp_Follow_Up]/2 Which part of that is linuxptp doing incorrectly? > At the same time > the Syncs were the actual timestamp as the originTimestamp. How are Sync messages relevant here? Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v2 1/4] unicast: Add support to check if message was received from an entry in the unicast master table.
> -Original Message- > From: vincent.cheng...@renesas.com > Sent: Saturday, March 19, 2022 7:04 PM > To: Keller, Jacob E > Cc: linuxptp-devel@lists.sourceforge.net > Subject: Re: [Linuxptp-devel] [PATCH v2 1/4] unicast: Add support to check if > message was received from an entry in the unicast master table. > > >I'm ok with the name if Richard is, but thought I'd voice my bikeshed > >opinion. > > Changed to unicast_client_msg_is_from_master_table_entry() in v3 patch. > The unicast_client prefix is to keep with existing naming in the file. > > Thanks, > Vincent Yep that seems reasonable to me. Thanks, Jake ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
