Thread: [Linuxptp-devel] [RFC 0/1] Adding support for AVnu Automotive Profile
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-devel
|
From: Vedang P. <ved...@in...> - 2018-07-16 21:35:27
|
Hi, This patch is the first from a series of patches we'd like to contribute to Linuxptp in order to enable gPTP features from Avnu Automotive Profile. The automotive environment is unique in that it is a closed system. Every network device is known prior to startup and devices do not enter or leave the network, except in the case of failures. Because of the closed nature of the automotive network, it is possible to simplify and improve gPTP startup performance. Specifically, functions like election of a grand master and calculations of wire delays are tasks that can be optimized for a closed system. These gPTP features are specified in Chapter 6 from Avnu Automotive Profile spec [1]. The patch following the cover letter adds avnu_ap config option, the most important feature for the profile. avnu_ap will be used to determine whether AVnu Automotive Profile is enabled. If so, Best Master Clock Algorithm (BMCA) is disabled on the device and gmCapable is used to determine the device role (grand master or slave). So, both the config options together implement the ‘isGM’ static gPTP value mentioned in Section 6.2.1.1 of AVnu Automotive Profile [1]. There will be more features which we will submit soon, covering all gPTP features from Avnu Automotive Profile. These will include: - Switching Sync message interval and pdelay message intervals to a lower value once system stabilizes (Sections 6.2.3.1 and 6.2.3.2 in [1]). This will also add support for Message Interval request TLV (Section 10.5.4 in [2]). - Setting asCapable to true only in case of 802.1AS. This will be followed by an ability to set asCapable to true whenever the link is up in order to speed up startup. (Section 6.2.1.2 in [1]) - Option to save some properties like neighborRateRatio when the program exits. (Sections 6.2.2.2 and 6.2.2.3 in [1]) - Option to continue adjusting the clock even when slave does not receive Sync messages from master. (Section 6.3 bullet 4 sub bullet 6 -- lines 228 to 230) Please note that the above support is provided for ordinary clocks only (boundary clock is not support at the moment). Also, this profile should always be run along with 802.1AS profile. Let me know if you need more details about the points mentioned above. [1] Automotive Ethernet AVB Functional and Interoperability Specification - http://avnu.org/wp-content/uploads/2014/05/ Automotive-Ethernet-AVB-Func-Interop-Spec-v1.5-Public.pdf [2] IEEE Std 802.1AS™-2011 Specification: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5741898&tag=1 Vedang Patel (1): Add avnu_ap to enable AVnu Automotive Profile clock.c | 15 +++++++- clock.h | 8 +++++ config.c | 1 + configs/AVnu.cfg | 22 ++++++++++++ configs/default.cfg | 1 + fsm.c | 11 ++++++ port.c | 99 +++++++++++++++++++++++++++++++++++++++++++++++++---- ptp4l.8 | 10 ++++++ 8 files changed, 159 insertions(+), 8 deletions(-) create mode 100644 configs/AVnu.cfg -- 2.7.3 |
|
From: Vedang P. <ved...@in...> - 2018-07-16 21:35:32
|
This adds a new config option "avnu_ap" for ptp4l. Setting this option to 1 will enable the AVnu Automotive Profile (AVnu AP) [1] for the device. When it is active, best master clock algorithm (BMCA) will be disabled. gmCapable will be used to determine whether a device will be grand master or slave. By default, avnu_ap is set to 0. Setting it to 1 enables the AVnu Automotive Profile. It will have following consequences while running ptp4l: - When the port will initialize, the port will directly go into PS_GRAND_MASTER when gmCapable set to 1 or to PS_UNCALIBRATED when gmCapable is set to 0. - BMCA won't run. So, Announce messages (on master) and announce timeouts (on slave) will be disabled. - Source port identity won't be checked while processing Sync and Follow_Up messages. - SLAVE devices will not transition to MASTER when it receives Sync timeout. In all, this will add capabilities described in sections 6.2.1.1 and 6.3 (lines 191 to 199 - first 2 points) in [1]. Please note that this option is currently only supported for ordinary clocks running on 802.3 network transport. Defining avnu_ap in boundary clocks or any other mode of transport will return error. [1] - http://avnu.org/wp-content/uploads/2014/05/Automotive-Ethernet-AVB- Func-Interop-Spec-v1.5-Public.pdf Change-Id: Ida703d867c3f3bf405b66021c91d444505e9b042 Signed-off-by: Patel, Vedang <ved...@in...> --- clock.c | 15 +++++++- clock.h | 8 +++++ config.c | 1 + configs/AVnu.cfg | 22 ++++++++++++ configs/default.cfg | 1 + fsm.c | 11 ++++++ port.c | 99 +++++++++++++++++++++++++++++++++++++++++++++++++---- ptp4l.8 | 10 ++++++ 8 files changed, 159 insertions(+), 8 deletions(-) create mode 100644 configs/AVnu.cfg diff --git a/clock.c b/clock.c index 2400b2fb0dc3..501a1f511ba6 100644 --- a/clock.c +++ b/clock.c @@ -98,7 +98,8 @@ struct clock { int sde; int free_running; int freq_est_interval; - int grand_master_capable; /* for 802.1AS only */ + int grand_master_capable; /* for 802.1AS and AVnu AP only */ + int avnu_ap; /* For AVnu Automotive Profile (AVnu AP) only */ int utc_timescale; int utc_offset_set; int leap_set; @@ -1093,6 +1094,13 @@ struct clock *clock_create(enum clock_type type, struct config *config, } } + /* Specific to AVnu Automotive Profile. */ + c->avnu_ap = config_get_int(config, NULL, "avnu_ap"); + if (c->avnu_ap && c->type != CLOCK_TYPE_ORDINARY) { + pr_err("Only ordinary clocks are supported by AVnu_AP.\n"); + return NULL; + } + /* Initialize the parentDS. */ clock_update_grandmaster(c); c->dad.pds.parentStats = 0; @@ -1806,3 +1814,8 @@ double clock_rate_ratio(struct clock *c) } return servo_rate_ratio(c->servo); } + +int clock_avnu_ap(struct clock *c) +{ + return c->avnu_ap; +} diff --git a/clock.h b/clock.h index cc2910a59c4a..a51bca19b0ae 100644 --- a/clock.h +++ b/clock.h @@ -338,4 +338,12 @@ void clock_check_ts(struct clock *c, uint64_t ts); */ double clock_rate_ratio(struct clock *c); +/** + * Obtain the value for avnu_ap. This is used to determine whether device is + * running AVnu Automotive profile. + * @param c The clock interface. + * @return The value of avnu_ap. + */ +int clock_avnu_ap(struct clock *c); + #endif diff --git a/config.c b/config.c index 7914ba4b5166..9ee25bbb8f5e 100644 --- a/config.c +++ b/config.c @@ -191,6 +191,7 @@ static struct config_enum tsproc_enu[] = { struct config_item config_tab[] = { PORT_ITEM_INT("announceReceiptTimeout", 3, 2, UINT8_MAX), GLOB_ITEM_INT("assume_two_step", 0, 0, 1), + GLOB_ITEM_INT("avnu_ap", 0, 0, 1), PORT_ITEM_INT("boundary_clock_jbod", 0, 0, 1), GLOB_ITEM_INT("check_fup_sync", 0, 0, 1), GLOB_ITEM_INT("clockAccuracy", 0xfe, 0, UINT8_MAX), diff --git a/configs/AVnu.cfg b/configs/AVnu.cfg new file mode 100644 index 000000000000..9fa0a1d65e59 --- /dev/null +++ b/configs/AVnu.cfg @@ -0,0 +1,22 @@ +# +# AVnu Automotive Profile example configuration containing those attributes +# which differ from the defaults. See the file, default.cfg, for the complete +# list of available options. +# +# Since BMCA is disabled in AVnu AP, the gmCapable config option will have to +# be used to determine whether the device is a grand master or slave. +[global] +priority1 248 +priority2 248 +logSyncInterval -3 +syncReceiptTimeout 3 +neighborPropDelayThresh 800 +min_neighbor_prop_delay -20000000 +assume_two_step 1 +path_trace_enabled 1 +follow_up_info 1 +transportSpecific 0x1 +ptp_dst_mac 01:80:C2:00:00:0E +network_transport L2 +delay_mechanism P2P +avnu_ap 1 diff --git a/configs/default.cfg b/configs/default.cfg index c5a8b57c9314..248ccad5d963 100644 --- a/configs/default.cfg +++ b/configs/default.cfg @@ -90,6 +90,7 @@ delay_filter_length 10 egressLatency 0 ingressLatency 0 boundary_clock_jbod 0 +avnu_ap 0 # # Clock description # diff --git a/fsm.c b/fsm.c index ce6efad30937..af05abdae294 100644 --- a/fsm.c +++ b/fsm.c @@ -34,6 +34,17 @@ enum port_state ptp_fsm(enum port_state state, enum fsm_event event, int mdiff) case EV_INIT_COMPLETE: next = PS_LISTENING; break; + /* + * The following 2 cases are specific to AVnu AP. When we are + * running AVnu AP, BMCA is not run. So, we need to assign the + * state right after the ports initialization is complete. + */ + case EV_RS_GRAND_MASTER: + next = PS_GRAND_MASTER; + break; + case EV_RS_SLAVE: + next = PS_UNCALIBRATED; + break; default: break; } diff --git a/port.c b/port.c index e85f9fa6f52e..fff2523c62b8 100644 --- a/port.c +++ b/port.c @@ -1611,7 +1611,12 @@ int port_initialize(struct port *p) p->fda.fd[FD_FIRST_TIMER + i] = fd[i]; } - if (port_set_announce_tmo(p)) { + /* + * Do not set announce timeouts when running AVnu Automotive profiles. + * This is done as part of disabling the Best Master Clock Algorithm + * (BMCA) as specified in section 6.3 point 1 (lines 191 to 195). + */ + if (!clock_avnu_ap(p->clock) && port_set_announce_tmo(p)) { goto no_tmo; } if (unicast_client_enabled(p) && unicast_client_set_tmo(p)) { @@ -1717,6 +1722,14 @@ int process_announce(struct port *p, struct ptp_message *m) return result; } + /* + * Do not process Announce messages when running AVnu Automotive + * Profile, conforming to Section 6.3 point 1 (lines 191-195). + */ + if (clock_avnu_ap(p->clock)) { + return result; + } + switch (p->state) { case PS_INITIALIZING: case PS_FAULTY: @@ -1874,8 +1887,15 @@ void process_follow_up(struct port *p, struct ptp_message *m) case PS_SLAVE: break; } + + /* + * Do not verify source port identity if we are running AVnu Automotive + * Profile. This is conforming to Section 6.3 point 2 (lines 196 to + * 199) of AVnu Automotive Profile version 1.5. + */ master = clock_parent_identity(p->clock); - if (!pid_eq(&master, &m->header.sourcePortIdentity)) { + if (!clock_avnu_ap(p->clock) && + !pid_eq(&master, &m->header.sourcePortIdentity)) { return; } @@ -2177,8 +2197,15 @@ void process_sync(struct port *p, struct ptp_message *m) case PS_SLAVE: break; } + + /* + * Do not verify source port identity we are running AVnu Automotive + * Profile. This is conforming to Section 6.3 point 2 (lines 196 to + * 199) of AVnu Automotive Profile version 1.5. + */ master = clock_parent_identity(p->clock); - if (!pid_eq(&master, &m->header.sourcePortIdentity)) { + if (!clock_avnu_ap(p->clock) && + !pid_eq(&master, &m->header.sourcePortIdentity)) { return; } @@ -2331,7 +2358,20 @@ static void port_p2p_transition(struct port *p, enum port_state next) break; case PS_MASTER: case PS_GRAND_MASTER: - set_tmo_log(p->fda.fd[FD_MANNO_TIMER], 1, -10); /*~1ms*/ + /* + * Do not run BMCA in AVnu Automotive Profile (as mentioned in + * Section 6.3 point 1). + */ + if (clock_avnu_ap(p->clock)) { + /* + * If Avnu AP is active, we are skipping the + * PS_LISTENING state and directly going to PS_MASTER. + * So, set the delay timeout here. + */ + port_set_delay_tmo(p); + } else { + set_tmo_log(p->fda.fd[FD_MANNO_TIMER], 1, -10); /*~1ms*/ + } port_set_sync_tx_tmo(p); break; case PS_PASSIVE: @@ -2342,7 +2382,16 @@ static void port_p2p_transition(struct port *p, enum port_state next) flush_peer_delay(p); /* fall through */ case PS_SLAVE: - port_set_announce_tmo(p); + if (clock_avnu_ap(p->clock)) { + /* + * If AVnu AP is active, we are skipping the + * PS_LISTENING state and directly going to + * PS_UNCALIBRATED. So, set the delay timeout here. + */ + port_set_delay_tmo(p); + } else { + port_set_announce_tmo(p); + } break; }; } @@ -2460,7 +2509,18 @@ static enum fsm_event bc_event(struct port *p, int fd_index) port_renew_transport(p)) { return EV_FAULT_DETECTED; } - return EV_ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES; + + /* + * When AVnu AP is active, we never want the slave to + * transition to the master state. So, returning + * EV_SYNCHRONIZATION_FAULT ensures it returns back to + * PS_UNCALIBRATED. + */ + if (clock_avnu_ap(p->clock)) { + return EV_SYNCHRONIZATION_FAULT; + } else { + return EV_ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES; + } case FD_DELAY_TIMER: pr_debug("port %hu: delay timeout", portnum(p)); @@ -2850,6 +2910,12 @@ struct port *port_open(int phc_index, p->jbod = config_get_int(cfg, interface->name, "boundary_clock_jbod"); transport = config_get_int(cfg, interface->name, "network_transport"); + if (clock_avnu_ap(clock) && transport != TRANS_UDS && + transport != TRANS_IEEE_802_3) { + pr_err("AVnu Automotive profile can only run on Layer 2 transport."); + goto err_port; + } + if (transport == TRANS_UDS) { ; /* UDS cannot have a PHC. */ } else if (!interface->ts_info.valid) { @@ -2891,6 +2957,12 @@ struct port *port_open(int phc_index, p->portIdentity.portNumber = number; p->state = PS_INITIALIZING; p->delayMechanism = config_get_int(cfg, p->name, "delay_mechanism"); + if (clock_avnu_ap(clock) && p->delayMechanism != DM_P2P && + transport != TRANS_UDS) { + pr_err("AVnu Automotive profile can only support P2P delay mechanism."); + goto err_port; + } + p->versionNumber = PTP_VERSION; if (number && unicast_client_claim_table(p)) { @@ -2991,7 +3063,20 @@ int port_state_update(struct port *p, enum fsm_event event, int mdiff) if (port_initialize(p)) { event = EV_FAULT_DETECTED; } else { - event = EV_INIT_COMPLETE; + /* + * UDS ports are not used for time synchronization. + * So, do not set state when AVnu AP is activated. + */ + if (transport_type(p->trp) != TRANS_UDS && + clock_avnu_ap(p->clock)) { + if (clock_gm_capable(p->clock)) { + event = EV_RS_GRAND_MASTER; + } else { + event = EV_RS_SLAVE; + } + } else { + event = EV_INIT_COMPLETE; + } } next = p->state_machine(next, event, 0); } diff --git a/ptp4l.8 b/ptp4l.8 index 10c5c2f967cb..0dd13d2ba52b 100644 --- a/ptp4l.8 +++ b/ptp4l.8 @@ -661,6 +661,16 @@ The time source is a single byte code that gives an idea of the kind of local clock in use. The value is purely informational, having no effect on the outcome of the Best Master Clock algorithm, and is advertised when the clock becomes grand master. +.TP +.B avnu_ap +Enable Avnu Automotive Profile. This profile should always be run along with +802.1AS. When set to 1, gmCapable is used to determine whether the clock will +be a grand master for the local network. If gmCapable is 1, the device will +assume the grand master state else it will be the slave. Care should be taken +to make sure there is only 1 grand master in the network. The best master +clock algorithm (BMCA) won't run when Automotive profile is active. Also, +source port identity won't be checked in Sync and Follow_Up messages. The +default value of avnu_ap is 0 (disabled). .SH UNICAST DISCOVERY OPTIONS -- 2.7.3 |
|
From: Richard C. <ric...@gm...> - 2018-07-19 17:18:05
|
On Mon, Jul 16, 2018 at 02:34:47PM -0700, Vedang Patel wrote: > - Source port identity won't be checked while processing Sync and > Follow_Up messages. This comment is not about your patch but rather about the "profile"... Gotta love this: Don't check the source address! Well, I'm glad this is only for automotive. Its not like its safety critical or anything. Cheers, Richard |
|
From: Cliff S. <csp...@go...> - 2018-07-16 23:21:06
|
I don't like the complexity this overlays into ptp4l's state machine. Could you explain why you'd want to use this instead of a more standard profile? Having a grandmaster send an announce message doesn't seem like a significant burden to an automotive ethernet network, and ptp4l already supports a slave-only mode. I don't think that an automotive network is sufficiently different from an industrial network to necessitate a special profile, especially one that changes core behavior of the protocol. |
|
From: Richard C. <ric...@gm...> - 2018-07-19 15:15:05
|
On Mon, Jul 16, 2018 at 04:20:29PM -0700, Cliff Spradlin via Linuxptp-devel wrote: > I don't think that an automotive network is sufficiently different from an > industrial network to necessitate a special profile, especially one that > changes core behavior of the protocol. +1 I agree with the sentiment in this and your other reply. We don't hack random options all over the code. But, if the profile can be supported by adding non-invasive options, then we should implement as much as we can. The real problem of this patch is the approach. Instead of adding discrete options, it hacks its way in, ignoring the modular design that we already have in place. Thanks, Richard |
|
From: Patel, V. <ved...@in...> - 2018-07-18 17:37:03
|
On Mon, 2018-07-16 at 16:20 -0700, Cliff Spradlin wrote: > I don't like the complexity this overlays into ptp4l's state machine. > > Could you explain why you'd want to use this instead of a more > standard profile? Having a grandmaster send an announce message > doesn't seem like a significant burden to an automotive ethernet > network, and ptp4l already supports a slave-only mode. > To take advantage of the quicker startup time the profile specifies. If we look at table 6 in Section 5.5 of the spec[1], grand master is expected to start sending Sync/Follow-Up messages within 250ms. Without skipping BMCA, I don't see it happening. If slaveOnly is used, the device will still participate in BMCA. The Announce messages won't be processed when BMCA is not being run. So, there is no need to send those messages. There will be more features added later on which will further optimize linuxptp to run more efficiently on the automotive network. I have described all of the future enhancements in the cover letter: https://sourceforge.net/p/linuxptp/mailman/message/36369408/ > I don't think that an automotive network is sufficiently different > from an industrial network to necessitate a special profile, > especially one that changes core behavior of the protocol. > > [1] - http://avnu.org/wp-content/uploads/2014/05/Automotive-Ethernet-AV B-Func-Interop-Spec-v1.5-Public.pdf |
|
From: Cliff S. <csp...@go...> - 2018-07-18 19:20:45
|
On Wed, Jul 18, 2018 at 10:36 AM Patel, Vedang <ved...@in...> wrote: > To take advantage of the quicker startup time the profile specifies. > > There will be more features added later on which will further optimize > linuxptp to run more efficiently on the automotive network. I have > described all of the future enhancements in the cover letter: So the motivation behind these changes is quicker startup time, and faster synchronization of slave clocks. That is a good goal, but best implemented directly into an existing spec. Instead, this spec deeply modifies 802.1as creating yet another non-conforming variant of IEEE 1588. Removing Announce and BMCA seems to cause all sorts of additional complexity, such as all this logic for what a boundary clock should do based on the lack of a Sync message. If it just ran normal PTP it wouldn't need all this complexity - it could just promote its local clock as grandmaster. This spec has a lot of special logic that you haven't yet implemented - see "9.3.2 Non-Continuous Sync Values" for example. One of your planned features is to slow down Sync messages after stabilization, but that appears to require a special port-local signalling message to be sent and received. Normally I'd say that this spec could be implemented by creating a separate state machine (similar to the slaveOnly state machine), but this is all just too different. Personally, I think that if you really need to implement this spec, it would be better to fork linuxptp, strip out all the disabled and unnecessary features, and implement all special-case logic directly, instead of conditionally. As far as I can see, this spec will only become more divergent from IEEE 1588 and 802.1as over time with planned security and path redundancy features. If we look at table 6 in Section 5.5 of the spec[1], grand master is > expected to start sending Sync/Follow-Up messages within 250ms. Without > skipping BMCA, I don't see it happening. Without any patches ptp4l can already become grandmaster quickly: setting logAnnounceInterval to -10 gets through BMCA in 3 milliseconds on my computer. |
|
From: Hindman, G. <gav...@in...> - 2018-07-19 02:19:19
|
Sorry for the top-post, outlook only likes plain-text for inline replies. Regarding issues with the spec itself, there’s not much we can do about that – the spec’s the spec, and influencing that needs to be done within the Avnu working group. That said, the automotive profile will be superseded by 802.1AS-REV, and much of the automotive profile functionality is rolled forward to that revision, albeit differently in some cases, so similar changes are coming one way or another. But, that IEEE version will not be public for quite some time, and the automotive industry is not waiting around. Our goal with adding automotive profile support to LinuxPTP is explicitly to avoid forks and fragmentation, and keep everyone back in a common mainline until we can roll them over to 802.1AS-REV in the future. Yes, it’s a stop-gap, but a necessary one to avoid further fragmentation. Thanks, Gavin Hindman Intel Open-Source Technology Center From: Cliff Spradlin <csp...@go...> Sent: Wednesday, July 18, 2018 12:20 PM To: Patel, Vedang <ved...@in...> Cc: lin...@li...; Sanchez-Palencia, Jesus <jes...@in...>; Gomes, Vinicius <vin...@in...>; Hindman, Gavin <gav...@in...>; Guedes, Andre <and...@in...> Subject: Re: [Linuxptp-devel] [RFC 1/1] Add avnu_ap to enable AVnu Automotive Profile On Wed, Jul 18, 2018 at 10:36 AM Patel, Vedang <ved...@in...<mailto:ved...@in...>> wrote: To take advantage of the quicker startup time the profile specifies. There will be more features added later on which will further optimize linuxptp to run more efficiently on the automotive network. I have described all of the future enhancements in the cover letter: So the motivation behind these changes is quicker startup time, and faster synchronization of slave clocks. That is a good goal, but best implemented directly into an existing spec. Instead, this spec deeply modifies 802.1as creating yet another non-conforming variant of IEEE 1588. Removing Announce and BMCA seems to cause all sorts of additional complexity, such as all this logic for what a boundary clock should do based on the lack of a Sync message. If it just ran normal PTP it wouldn't need all this complexity - it could just promote its local clock as grandmaster. This spec has a lot of special logic that you haven't yet implemented - see "9.3.2 Non-Continuous Sync Values" for example. One of your planned features is to slow down Sync messages after stabilization, but that appears to require a special port-local signalling message to be sent and received. Normally I'd say that this spec could be implemented by creating a separate state machine (similar to the slaveOnly state machine), but this is all just too different. Personally, I think that if you really need to implement this spec, it would be better to fork linuxptp, strip out all the disabled and unnecessary features, and implement all special-case logic directly, instead of conditionally. As far as I can see, this spec will only become more divergent from IEEE 1588 and 802.1as over time with planned security and path redundancy features. If we look at table 6 in Section 5.5 of the spec[1], grand master is expected to start sending Sync/Follow-Up messages within 250ms. Without skipping BMCA, I don't see it happening. Without any patches ptp4l can already become grandmaster quickly: setting logAnnounceInterval to -10 gets through BMCA in 3 milliseconds on my computer. |
|
From: Richard C. <ric...@gm...> - 2018-07-19 15:02:01
|
On Mon, Jul 16, 2018 at 02:34:47PM -0700, Vedang Patel wrote:
> This adds a new config option "avnu_ap" for ptp4l. Setting this option
> to 1 will enable the AVnu Automotive Profile (AVnu AP) [1] for the
> device.
This is not how we do things.
I have said this more than once before. We don't add a single
monolithic Boolean option for some random profile or extension.
Instead, for each different behavior or attribute, we add a granular
option. Then, the profile is simply a configuration file selecting
the appropriate options.
> - BMCA won't run. So, Announce messages (on master) and announce
> timeouts (on slave) will be disabled.
There is no need to avoid the BMCA. Just make a BMCA that returns
static values. We already have slaveOnly and masterOnly. Your
profile should use those.
For the Announce messages, a simple 'inhibit_announce' option will
do.
> - Source port identity won't be checked while processing Sync and
> Follow_Up messages.
Single option.
> - SLAVE devices will not transition to MASTER when it receives Sync
> timeout.
slaveOnly.
> diff --git a/fsm.c b/fsm.c
> index ce6efad30937..af05abdae294 100644
> --- a/fsm.c
> +++ b/fsm.c
> @@ -34,6 +34,17 @@ enum port_state ptp_fsm(enum port_state state, enum fsm_event event, int mdiff)
> case EV_INIT_COMPLETE:
> next = PS_LISTENING;
> break;
> + /*
> + * The following 2 cases are specific to AVnu AP. When we are
> + * running AVnu AP, BMCA is not run. So, we need to assign the
> + * state right after the ports initialization is complete.
> + */
> + case EV_RS_GRAND_MASTER:
> + next = PS_GRAND_MASTER;
> + break;
> + case EV_RS_SLAVE:
> + next = PS_UNCALIBRATED;
> + break;
Don't hack your "special" code into 1588's FSM. Write your own (if needed).
> @@ -1717,6 +1722,14 @@ int process_announce(struct port *p, struct ptp_message *m)
> return result;
> }
>
> + /*
> + * Do not process Announce messages when running AVnu Automotive
> + * Profile, conforming to Section 6.3 point 1 (lines 191-195).
> + */
> + if (clock_avnu_ap(p->clock)) {
> + return result;
> + }
This is totally unnecessary, and it hurts the end user by taking an
option away. If an Announce is received, you should process it.
> @@ -2460,7 +2509,18 @@ static enum fsm_event bc_event(struct port *p, int fd_index)
> port_renew_transport(p)) {
> return EV_FAULT_DETECTED;
> }
> - return EV_ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES;
> +
> + /*
> + * When AVnu AP is active, we never want the slave to
> + * transition to the master state. So, returning
> + * EV_SYNCHRONIZATION_FAULT ensures it returns back to
> + * PS_UNCALIBRATED.
> + */
> + if (clock_avnu_ap(p->clock)) {
> + return EV_SYNCHRONIZATION_FAULT;
> + } else {
> + return EV_ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES;
> + }
Oh man. Just make a proper FSM please.
Thanks,
Richard
|
|
From: Richard C. <ric...@gm...> - 2018-07-19 15:08:15
|
On Mon, Jul 16, 2018 at 02:34:46PM -0700, Vedang Patel wrote: > - Switching Sync message interval and pdelay message intervals to a lower value > once system stabilizes (Sections 6.2.3.1 and 6.2.3.2 in [1]). This is an interesting option to have, all on its own. > This will also > add support for Message Interval request TLV (Section 10.5.4 in [2]). This is a complete waste of time, IMHO. The whole idea of this "profile" is that everything is statically configured. Why on earth should slaves then adjust the intervals later on? Nobody needs this. > - Option to save some properties like neighborRateRatio when the program exits. > (Sections 6.2.2.2 and 6.2.2.3 in [1]) No need to save on exit. If you like, script pmc to do this for you. However, a pre-seeded configuration option makes sense to add. > - Option to continue adjusting the clock even when slave does not receive Sync > messages from master. (Section 6.3 bullet 4 sub bullet 6 -- lines 228 to 230) Please explain exactly what you have in mind. Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2018-07-19 17:20:03
|
BTW, that CC: Patel is not an address to which we can reply. Please remove it from future mails. Thanks, Richard |
|
From: Patel, V. <ved...@in...> - 2018-07-19 21:15:34
|
On Thu, 2018-07-19 at 08:08 -0700, Richard Cochran wrote: > On Mon, Jul 16, 2018 at 02:34:46PM -0700, Vedang Patel wrote: > > > > - Switching Sync message interval and pdelay message intervals to a > > lower value > > once system stabilizes (Sections 6.2.3.1 and 6.2.3.2 in [1]). > This is an interesting option to have, all on its own. > A very basic question: What is the best way for master to determine the system has stabilized and change the sync interval? In the original plan, the slave would know and then it would send a signaling message to increase the interval. > > > > This will also > > add support for Message Interval request TLV (Section 10.5.4 in > > [2]). > This is a complete waste of time, IMHO. The whole idea of this > "profile" is that everything is statically configured. Why on earth > should slaves then adjust the intervals later on? > > Nobody needs this. > > > > > - Option to save some properties like neighborRateRatio when the > > program exits. > > (Sections 6.2.2.2 and 6.2.2.3 in [1]) > No need to save on exit. If you like, script pmc to do this for you. > However, a pre-seeded configuration option makes sense to add. > Ok will add a config option for the rate ratios. > > > > - Option to continue adjusting the clock even when slave does not > > receive Sync > > messages from master. (Section 6.3 bullet 4 sub bullet 6 -- lines > > 228 to 230) > Please explain exactly what you have in mind. > Here, I was just planning to adjust the clock such that it keeps on advancing based on last known value of cumulativeScaledRateOffset. But, after looking a bit more into the code, it looks like this might already be done. Need to look at the code a little more closely to know for sure. Thanks, Vedang > Thanks, > Richard > |
|
From: Richard C. <ric...@gm...> - 2018-07-21 05:41:55
|
On Thu, Jul 19, 2018 at 09:15:15PM +0000, Patel, Vedang wrote: > A very basic question: What is the best way for master to determine the > system has stabilized and change the sync interval? In the original > plan, the slave would know and then it would send a signaling message > to increase the interval. Hm. I had assumed that the master was supposed to switch automatically, but reading the pdf again, it appears to place the control of the change in interval into the downstream node. I would have guessed that in a carefully engineered system (like what they are talking about here), the initial convergence time would be known in advance and statically configured at the master. However, that is not what this spec. says. So it looks like we will need the signaling option after all. Thanks, Richard |
|
From: Patel, V. <ved...@in...> - 2018-07-19 21:23:01
|
Thanks for your inputs Richard. I will rework the patch as you
suggested. Some comments/questions for the patch inline.
On Thu, 2018-07-19 at 08:01 -0700, Richard Cochran wrote:
> On Mon, Jul 16, 2018 at 02:34:47PM -0700, Vedang Patel wrote:
> >
> > This adds a new config option "avnu_ap" for ptp4l. Setting this
> > option
> > to 1 will enable the AVnu Automotive Profile (AVnu AP) [1] for the
> > device.
> This is not how we do things.
>
> I have said this more than once before. We don't add a single
> monolithic Boolean option for some random profile or extension.
>
> Instead, for each different behavior or attribute, we add a granular
> option. Then, the profile is simply a configuration file selecting
> the appropriate options.
>
Ok. Will split this patch out into different options. Will send a
follow-up email on what I think the best options are.
> >
> > - BMCA won't run. So, Announce messages (on master) and announce
> > timeouts (on slave) will be disabled.
> There is no need to avoid the BMCA. Just make a BMCA that returns
> static values. We already have slaveOnly and masterOnly. Your
> profile should use those.
>
> For the Announce messages, a simple 'inhibit_announce' option will
> do.
>
Ok Will add it.
> >
> > - Source port identity won't be checked while processing Sync and
> > Follow_Up messages.
> Single option.
>
> >
> > - SLAVE devices will not transition to MASTER when it receives Sync
> > timeout.
> slaveOnly.
>
Ok Will look into the slaveOnly FSM.
> > diff --git a/fsm.c b/fsm.c
> > index ce6efad30937..af05abdae294 100644
> > --- a/fsm.c
> > +++ b/fsm.c
> > @@ -34,6 +34,17 @@ enum port_state ptp_fsm(enum port_state state,
> > enum fsm_event event, int mdiff)
> > case EV_INIT_COMPLETE:
> > next = PS_LISTENING;
> > break;
> > + /*
> > + * The following 2 cases are specific to AVnu AP.
> > When we are
> > + * running AVnu AP, BMCA is not run. So, we need
> > to assign the
> > + * state right after the ports initialization is
> > complete.
> > + */
> > + case EV_RS_GRAND_MASTER:
> > + next = PS_GRAND_MASTER;
> > + break;
> > + case EV_RS_SLAVE:
> > + next = PS_UNCALIBRATED;
> > + break;
> Don't hack your "special" code into 1588's FSM. Write your own (if
> needed).
>
Ok I will move this to a seperate FSM.
> >
> > @@ -1717,6 +1722,14 @@ int process_announce(struct port *p, struct
> > ptp_message *m)
> > return result;
> > }
> >
> > + /*
> > + * Do not process Announce messages when running AVnu
> > Automotive
> > + * Profile, conforming to Section 6.3 point 1 (lines 191-
> > 195).
> > + */
> > + if (clock_avnu_ap(p->clock)) {
> > + return result;
> > + }
> This is totally unnecessary, and it hurts the end user by taking an
> option away. If an Announce is received, you should process it.
>
Ok. Will remove this.
> >
> > @@ -2460,7 +2509,18 @@ static enum fsm_event bc_event(struct port
> > *p, int fd_index)
> > port_renew_transport(p)) {
> > return EV_FAULT_DETECTED;
> > }
> > - return EV_ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES;
> > +
> > + /*
> > + * When AVnu AP is active, we never want the slave
> > to
> > + * transition to the master state. So, returning
> > + * EV_SYNCHRONIZATION_FAULT ensures it returns
> > back to
> > + * PS_UNCALIBRATED.
> > + */
> > + if (clock_avnu_ap(p->clock)) {
> > + return EV_SYNCHRONIZATION_FAULT;
> > + } else {
> > + return
> > EV_ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES;
> > + }
> Oh man. Just make a proper FSM please.
Will probably be taken care of if I decide to use the slaveOnly FSM for
slaves. Else will include it in the new FSM which will set the BMCA
states which you mentioned before.
Thanks,
Vedang
>
> Thanks,
> Richard |
|
From: Patel, V. <ved...@in...> - 2018-07-19 21:23:52
|
On Thu, 2018-07-19 at 10:19 -0700, Richard Cochran wrote: > BTW, that CC: Patel is not an address to which we can reply. Please > remove it from future mails. > Looks like a weird setting in my git config. Will fix it. Thanks, Vedang > Thanks, > Richard |
|
From: Cliff S. <csp...@wa...> - 2018-07-19 21:42:33
|
On Thu, Jul 19, 2018 at 2:24 PM Patel, Vedang <ved...@in...> wrote: > On Thu, 2018-07-19 at 08:01 -0700, Richard Cochran wrote: >> For the Announce messages, a simple 'inhibit_announce' option will >> do. > > Ok Will add it. There's no harm, but this doesn't seem necessary. Won't a master be compliant to the automotive spec even if it sends Announce messages? Seems like a micro-optimization to suppress them. |
|
From: Richard C. <ric...@gm...> - 2018-07-21 05:25:54
|
On Thu, Jul 19, 2018 at 02:41:56PM -0700, Cliff Spradlin wrote: > On Thu, Jul 19, 2018 at 2:24 PM Patel, Vedang <ved...@in...> wrote: > > On Thu, 2018-07-19 at 08:01 -0700, Richard Cochran wrote: > >> For the Announce messages, a simple 'inhibit_announce' option will > >> do. > > > > Ok Will add it. > > There's no harm, but this doesn't seem necessary. Won't a master be > compliant to the automotive spec even if it sends Announce messages? > Seems like a micro-optimization to suppress them. You can bet that AVnu will invent a conformance test for this. Never mind that the message is harmless. Also, if I am right, the overhead will be almost zero, since you only have to avoid the setting the announce timer the first time. Thanks, Richard |
|
From: Patel, V. <ved...@in...> - 2018-07-24 17:38:45
|
On Thu, 2018-07-19 at 21:21 +0000, Patel, Vedang wrote: > Thanks for your inputs Richard. I will rework the patch as you > suggested. Some comments/questions for the patch inline. > > On Thu, 2018-07-19 at 08:01 -0700, Richard Cochran wrote: > > > > On Mon, Jul 16, 2018 at 02:34:47PM -0700, Vedang Patel wrote: > > > > > > > > > This adds a new config option "avnu_ap" for ptp4l. Setting this > > > option > > > to 1 will enable the AVnu Automotive Profile (AVnu AP) [1] for > > > the > > > device. > > This is not how we do things. > > > > I have said this more than once before. We don't add a single > > monolithic Boolean option for some random profile or extension. > > > > Instead, for each different behavior or attribute, we add a > > granular > > option. Then, the profile is simply a configuration file selecting > > the appropriate options. > > > Ok. Will split this patch out into different options. Will send a > follow-up email on what I think the best options are. So, following is what we think will do the job: - Add inhibit_announce option to stop announce messages as well as timeouts. (default: 0 - disabled) - Add source_port_identity_check option to disable checking for source port identities in sync and follow-up messages (default: 1 - enabled) - Add static_roles config which is a tristate - master, slave and disabled. When master or slave roles are selected, the FSM will directly assign those roles. (default: 'disabled') Following are the configs needed for each role: master: static_role = 'master', inhibit_announce = 1 slave: static_role = 'slave', source_port_identity_check = 0 We also looked into the slaveOnly FSM for slave. But, we cannot use that because it still expects the announce message from the master before transitioning to UNCALIBRATED state. We also looked into using masterOnly option. But, it will wait for announce receipt timeout before transitioning to MASTER. But, inhibit_announce will disable that. Let us know if this meets your expectations. Thanks, Vedang Patel |
|
From: Richard C. <ric...@gm...> - 2018-07-25 02:55:16
|
On Tue, Jul 24, 2018 at 05:38:32PM +0000, Patel, Vedang wrote:
> So, following is what we think will do the job:
> - Add inhibit_announce option to stop announce messages as well as
> timeouts. (default: 0 - disabled)
Sounds okay.
> - Add source_port_identity_check option to disable checking for source
> port identities in sync and follow-up messages (default: 1 - enabled)
Or keeping with the negative tone, "ignore_source_id". (Ignore and
inhibit sound good together.)
> - Add static_roles config which is a tristate - master, slave and
> disabled. When master or slave roles are selected, the FSM will
> directly assign those roles. (default: 'disabled')
We already have slaveOnly and masterOnly. All you need is a new
option for your different BCMA, say "BCMA = noop".
Then provide two functions for p->state_machine, something like the
following pseudo code.
enum port_state designated_master_fsm() {
return PS_GRAND_MASTER;
}
enum port_state designated_slave_fsm() {
return PS_SLAVE;
}
port_open() {
...
if (BMCA == noop) {
p->state_machine = clock_slave_only(clock) ?
designated_slave_fsm : designated_master_fsm;
}
}
> We also looked into the slaveOnly FSM for slave. But, we cannot use
> that because it still expects the announce message from the master
> before transitioning to UNCALIBRATED state.
You can surely use the slaveOnly option, but of course you wouldn't
use the ptp_slave_fsm function itself.
Thanks,
Richard
|
|
From: Patel, V. <ved...@in...> - 2018-07-25 17:13:11
|
Thanks Richard for the inputs.
On Tue, 2018-07-24 at 19:55 -0700, Richard Cochran wrote:
> On Tue, Jul 24, 2018 at 05:38:32PM +0000, Patel, Vedang wrote:
> >
> > So, following is what we think will do the job:
> > - Add inhibit_announce option to stop announce messages as well as
> > timeouts. (default: 0 - disabled)
> Sounds okay.
>
> >
> > - Add source_port_identity_check option to disable checking for
> > source
> > port identities in sync and follow-up messages (default: 1 -
> > enabled)
> Or keeping with the negative tone, "ignore_source_id". (Ignore and
> inhibit sound good together.)
>
yeah ignore_source_id seems better. will use that.
> >
> > - Add static_roles config which is a tristate - master, slave and
> > disabled. When master or slave roles are selected, the FSM will
> > directly assign those roles. (default: 'disabled')
> We already have slaveOnly and masterOnly. All you need is a new
> option for your different BCMA, say "BCMA = noop".
>
> Then provide two functions for p->state_machine, something like the
> following pseudo code.
>
> enum port_state designated_master_fsm() {
> return PS_GRAND_MASTER;
> }
> enum port_state designated_slave_fsm() {
> return PS_SLAVE;
> }
>
> port_open() {
> ...
> if (BMCA == noop) {
> p->state_machine = clock_slave_only(clock) ?
> designated_slave_fsm : designated_master_fsm;
> }
> }
>
In the description above, you mentioned that we should use masterOnly
and slaveOnly. But, from the pseudo code, it seems like you just want
to make decision based only on slaveOnly option. Which one do you
prefer?
In my opinion, we should use both the options to remove any ambiguity.
This would mean, if we decide to support brides (in the future), we
will have to change slaveOnly from global to per-port config option.
If we are just using a single option, I would prefer masterOnly since
it is a per-port variable and extending support to bridges will be
easy.
> >
> > We also looked into the slaveOnly FSM for slave. But, we cannot use
> > that because it still expects the announce message from the master
> > before transitioning to UNCALIBRATED state.
> You can surely use the slaveOnly option, but of course you wouldn't
> use the ptp_slave_fsm function itself.
>
> Thanks,
> Richard |
|
From: Richard C. <ric...@gm...> - 2018-07-26 00:37:44
|
On Wed, Jul 25, 2018 at 05:13:03PM +0000, Patel, Vedang wrote: > In the description above, you mentioned that we should use masterOnly > and slaveOnly. But, from the pseudo code, it seems like you just want > to make decision based only on slaveOnly option. Which one do you > prefer? The code should require that one of these is set when BMCA == noop. > If we are just using a single option, I would prefer masterOnly since > it is a per-port variable and extending support to bridges will be > easy. How about this? Leave slaveOnly global. When BMCA == noop then check port option masterOnly, then global slaveOnly, else fail. Later on, a bridge that has both port types can set slaveOnly as the global default and configure masterOnly per port as needed. Thanks, Richard |
|
From: Patel, V. <ved...@in...> - 2018-07-26 18:24:31
|
On Wed, 2018-07-25 at 17:37 -0700, Richard Cochran wrote: > On Wed, Jul 25, 2018 at 05:13:03PM +0000, Patel, Vedang wrote: > > > > In the description above, you mentioned that we should use > > masterOnly > > and slaveOnly. But, from the pseudo code, it seems like you just > > want > > to make decision based only on slaveOnly option. Which one do you > > prefer? > The code should require that one of these is set when BMCA == noop. > > > > > If we are just using a single option, I would prefer masterOnly > > since > > it is a per-port variable and extending support to bridges will be > > easy. > How about this? Leave slaveOnly global. When BMCA == noop then > check > port option masterOnly, then global slaveOnly, else fail. > > Later on, a bridge that has both port types can set slaveOnly as the > global default and configure masterOnly per port as needed. > Thanks for the inputs. I will send out the updated patches soon. -Vedang > Thanks, > Richard |
|
From: Vedang P. <ved...@in...> - 2018-08-16 17:42:34
|
Changes in V2: ~~~~~~~~~~~ Instead of using a single option (avnu_ap) which makes multiple changes to linuxptp, we are taking a more granular approach by adding multiple config options and a FSM to do the same thing. The highlights are the following: - The first patch is just a small fix to msg_source_equal(). - The second patch introduce BMCA config option to select the static role FSMs to skip BMCA. - The third patch introduces the inhibit_announce config option which disables announce messages on master and announce message timeouts on slaves. - The fourth patch introduces the config option to disable the source port identity checks done on the Slave. - The last patch adds an example configuration for the AVnu Automotive Profile. - In all the series adds functionality from Sections 6.2.1.1 and Section 6.3 (pts #1 and #2) of the AVnu Automotive Profile[1]. For further information, you can look at the cover-letter from the first version at: https://sourceforge.net/p/linuxptp/mailman/message/36369408/ Some Opens: - Currently, we are using masterOnly (a per-port config option) and slaveOnly (a global config option) to determine role of the devices. This configuration option might be a little confusing to a new comer. One idea is to change slaveOnly to per-port config option. Are there any other ideas for this or the current way is not as confusing as I think? - In port_p2p_transition(), we are setting up the delay timer when BMCA is set as ‘noop’. Usually it is initialized then the device transitions to PS_LISTENING. But, we are skipping the LISTENING state. Another alternative is to transition to PS_LISTENING and then unconditionally transfer to PS_MASTER/PS_SLAVE. But, that seems more of an hack than what is currently being done. Any other alternatives? - Is there a place where I can add tests relating to the new features I added? What about https://github.com/mlichvar/linuxptp-testsuite? Thanks, Vedang Patel [1] Automotive Ethernet AVB Functional and Interoperability Specification - http://avnu.org/wp-content/uploads/2014/05/ Automotive-Ethernet-AVB-Func-Interop-Spec-v1.5-Public.pdf Vedang Patel (5): port.c: Add condition to check fc. Add BMCA config option. Add inhibit_announce config option. Add ignore_source_id config option. Add example configuration for AVnu Automotive Profile. bmc.c | 11 ++++++ config.c | 9 +++++ configs/AVnu-master.cfg | 27 +++++++++++++ configs/AVnu-slave.cfg | 30 +++++++++++++++ configs/default.cfg | 3 ++ fsm.c | 100 ++++++++++++++++++++++++++++++++++++++++++++++++ fsm.h | 26 +++++++++++++ port.c | 80 +++++++++++++++++++++++++++++++++----- port.h | 8 ++++ port_private.h | 3 ++ ptp4l.8 | 31 +++++++++++++-- 11 files changed, 314 insertions(+), 14 deletions(-) create mode 100644 configs/AVnu-master.cfg create mode 100644 configs/AVnu-slave.cfg -- 2.7.3 |
|
From: Vedang P. <ved...@in...> - 2018-08-16 17:42:36
|
If foreign clock is NULL, both the clocks are obviously not equal. So,
return 0 in that case.
The above condition (fc == NULL) is not currently encountered. It will
be encoutered in the next few patches which implement static roles for
master and slave.
Signed-off-by: Vedang Patel <ved...@in...>
Change-Id: I195f32eee7500e96f6a4c1296c7dbc200908c943
---
port.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/port.c b/port.c
index 5e0aed7df3cc..1a0e910a1151 100644
--- a/port.c
+++ b/port.c
@@ -144,6 +144,11 @@ static int msg_current(struct ptp_message *m, struct timespec now)
static int msg_source_equal(struct ptp_message *m1, struct foreign_clock *fc)
{
struct PortIdentity *id1, *id2;
+
+ if (!fc) {
+ return 0;
+ }
+
id1 = &m1->header.sourcePortIdentity;
id2 = &fc->dataset.sender;
return 0 == memcmp(id1, id2, sizeof(*id1));
--
2.7.3
|
|
From: Vedang P. <ved...@in...> - 2018-08-16 17:42:41
|
This option will accomplish 2 things. On the master, it will stop the announce messages being sent (by disabling FD_MANNO_TIMER timer). On slave, it will not configure announce message timeouts (by disabling FD_ANNOUNCE_TIMEOUT timer). This config option is needed for the AVnu Automotive profile[1] as part of skipping the Best Master Clock Algorithm (BMCA) as described in Section 6.3 pt #1 (lines 191 to 195). [1] - http://avnu.org/wp-content/uploads/2014/05/ Automotive-Ethernet-AVB-Func-Interop-Spec-v1.5-Public.pdf Signed-off-by: Vedang Patel <ved...@in...> Change-Id: I6613ce54f7d37c942ea654e733fdb43c983d4f24 --- config.c | 1 + configs/default.cfg | 1 + port.c | 13 +++++++++++-- port_private.h | 1 + ptp4l.8 | 8 ++++++++ 5 files changed, 22 insertions(+), 2 deletions(-) diff --git a/config.c b/config.c index 47cad7ab6632..702ee1b4e52a 100644 --- a/config.c +++ b/config.c @@ -225,6 +225,7 @@ struct config_item config_tab[] = { PORT_ITEM_INT("hybrid_e2e", 0, 0, 1), PORT_ITEM_INT("ignore_transport_specific", 0, 0, 1), PORT_ITEM_INT("ingressLatency", 0, INT_MIN, INT_MAX), + PORT_ITEM_INT("inhibit_announce", 0, 0, 1), PORT_ITEM_INT("inhibit_multicast_service", 0, 0, 1), GLOB_ITEM_INT("initial_delay", 0, 0, INT_MAX), GLOB_ITEM_INT("kernel_leap", 1, 0, 1), diff --git a/configs/default.cfg b/configs/default.cfg index 02714150fbab..56dfbe4aace1 100644 --- a/configs/default.cfg +++ b/configs/default.cfg @@ -32,6 +32,7 @@ neighborPropDelayThresh 20000000 masterOnly 0 G.8275.portDS.localPriority 128 BMCA ptp +inhibit_announce 0 # # Run time options # diff --git a/port.c b/port.c index 6144b1a05de5..dacc8d383607 100644 --- a/port.c +++ b/port.c @@ -1035,6 +1035,10 @@ static void port_nrate_initialize(struct port *p) int port_set_announce_tmo(struct port *p) { + if (p->inhibit_announce) { + return 0; + } + return set_tmo_random(p->fda.fd[FD_ANNOUNCE_TIMER], p->announceReceiptTimeout, p->announce_span, p->logAnnounceInterval); @@ -1588,6 +1592,7 @@ int port_initialize(struct port *p) p->logMinDelayReqInterval = config_get_int(cfg, p->name, "logMinDelayReqInterval"); p->peerMeanPathDelay = 0; p->logAnnounceInterval = config_get_int(cfg, p->name, "logAnnounceInterval"); + p->inhibit_announce = config_get_int(cfg, p->name, "inhibit_announce"); p->announceReceiptTimeout = config_get_int(cfg, p->name, "announceReceiptTimeout"); p->syncReceiptTimeout = config_get_int(cfg, p->name, "syncReceiptTimeout"); p->transportSpecific = config_get_int(cfg, p->name, "transportSpecific"); @@ -2295,7 +2300,9 @@ static void port_e2e_transition(struct port *p, enum port_state next) break; case PS_MASTER: case PS_GRAND_MASTER: - set_tmo_log(p->fda.fd[FD_MANNO_TIMER], 1, -10); /*~1ms*/ + if (!p->inhibit_announce) { + set_tmo_log(p->fda.fd[FD_MANNO_TIMER], 1, -10); /*~1ms*/ + } port_set_sync_tx_tmo(p); break; case PS_PASSIVE: @@ -2346,7 +2353,9 @@ static void port_p2p_transition(struct port *p, enum port_state next) if (p->bmca == BMCA_NOOP) { port_set_delay_tmo(p); } - set_tmo_log(p->fda.fd[FD_MANNO_TIMER], 1, -10); /*~1ms*/ + if (!p->inhibit_announce) { + set_tmo_log(p->fda.fd[FD_MANNO_TIMER], 1, -10); /*~1ms*/ + } port_set_sync_tx_tmo(p); break; case PS_PASSIVE: diff --git a/port_private.h b/port_private.h index 8b5525a2122a..b454901f208d 100644 --- a/port_private.h +++ b/port_private.h @@ -97,6 +97,7 @@ struct port { enum port_state (*state_machine)(enum port_state state, enum fsm_event event, int mdiff); int bmca; + int inhibit_announce; /* portDS */ struct PortIdentity portIdentity; enum port_state state; /*portState*/ diff --git a/ptp4l.8 b/ptp4l.8 index 8c19d1d276ee..24ba45342460 100644 --- a/ptp4l.8 +++ b/ptp4l.8 @@ -670,6 +670,14 @@ assume the slave role. masterOnly (which is a per-port config option) can then be used to set individual ports to take master role. BMCA is used in the AVnu Automotive profile to speed up the start time for grand master and slaves. The default value is 'ptp' which runs the BMCA related state machines. +.TP +.B inhibit_announce +This will disable the timer for announce messages (i.e. FD_MANNO_TIMER) and +also the announce message timeout timer (i.e. FD_ANNOUNCE_TIMER). This is used +by the AVnu Automotive profile as part of switching over to a static BMCA. if +this option is enabled, ignore_source_id has to be enabled in the slave because +it has no way to identify master identity in Sync and Follow_Up messages. The +default is 0 (disabled). .SH UNICAST DISCOVERY OPTIONS -- 2.7.3 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X