On Wed, Aug 18, 2021 at 03:31:13PM +0000, Karthikkumar V via Linuxptp-devel
wrote:
> This code changes brings in the ability to program delay response timeout
> within which, if the upstream master does not send a valid delay response
> within the configurable delay response timeout duration, device will move
> out of lock state.Default delay_response_timeout is 0 (disabled).
Of course, this is non-standard behavior. After all, once the delay
has been estimated, it usually does not change. But I can see how you
might want to have this option.
However...
> diff --git a/config.c b/config.c
> index eb8b988..55d9752 100644
> --- a/config.c
> +++ b/config.c
> @@ -239,6 +239,7 @@ struct config_item config_tab[] = {
> PORT_ITEM_ENU("delay_filter", FILTER_MOVING_MEDIAN, delay_filter_enu),
> PORT_ITEM_INT("delay_filter_length", 10, 1, INT_MAX),
> PORT_ITEM_ENU("delay_mechanism", DM_E2E, delay_mech_enu),
> + PORT_ITEM_INT("delay_response_timeout",0,0,UINT8_MAX),
space after , please
> GLOB_ITEM_INT("dscp_event", 0, 0, 63),
> GLOB_ITEM_INT("dscp_general", 0, 0, 63),
> GLOB_ITEM_INT("domainNumber", 0, 0, 127),
> diff --git a/fsm.c b/fsm.c
> index ce6efad..3720d96 100644
> --- a/fsm.c
> +++ b/fsm.c
> @@ -210,6 +210,9 @@ enum port_state ptp_fsm(enum port_state state, enum
> fsm_event event, int mdiff)
> case EV_RS_PASSIVE:
> next = PS_PASSIVE;
> break;
> + case EV_DELAY_RESPONSE_TIMEOUT_EXPIRES:
> + next = PS_LISTENING;
There is no point in entering LISTENING because the same GM will be
selected. Instead, the delay request/response timeout should throw
EV_SYNCHRONIZATION_FAULT. This would avoid needless hacking of the
core FSM with non-standard stuff.
> diff --git a/fsm.h b/fsm.h
> index 857af05..236ec60 100644
> --- a/fsm.h
> +++ b/fsm.h
> @@ -53,6 +53,7 @@ enum fsm_event {
> EV_RS_GRAND_MASTER,
> EV_RS_SLAVE,
> EV_RS_PASSIVE,
> + EV_DELAY_RESPONSE_TIMEOUT_EXPIRES,
The enumerated events all come straight from the standard, and I don't
want linuxptp to run a non-standard state machine.
> };
> @@ -2680,7 +2684,26 @@ static enum fsm_event bc_event(struct port *p, int
> fd_index)
> pr_debug("%s: delay timeout", p->log_name);
> port_set_delay_tmo(p);
> delay_req_prune(p);
> - return port_delay_request(p) ? EV_FAULT_DETECTED : EV_NONE;
> + if (port_delay_request(p)) {
> + return EV_FAULT_DETECTED;
> + }
> + /* Successfully send Delay Request,
> + * increment delay response counter
> + */
> + p->delay_response_counter++;
> +
> + if (p->delay_response_counter >= p->delay_response_timeout) {
> + p->delay_response_counter = 0;
> + if ( (p->delay_response_timeout != 0) &&
> + (p->state == PS_SLAVE)) {
> + if (p->best) {
> + fc_clear(p->best);
> + }
> + pr_err("%s: delay response timeout",
> p->log_name);
> + return EV_DELAY_RESPONSE_TIMEOUT_EXPIRES;
Returning EV_SYNCHRONIZATION_FAULT has a similar result, triggering
the UNCALIBRATED state (which I think is more logical than reverting
to LISTENING), and it avoids tinkering with the core FSM.
Thanks,
Richard
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
