On Thu, Jun 02, 2022 at 03:12:26PM +0200, Miroslav Lichvar wrote:
> On Thu, Jun 02, 2022 at 05:56:13AM -0700, Richard Cochran wrote:
> > As I mentioned in a response to your first post, we already have tons
> > of configuration options, and some of them can and should be used to
> > implement the new feature.
> >
> > NO MECHANISM can simply set inhibit_delay_request and initial_delay
> > appropriately.
>
> As I understand it, that would not be exactly the same. It would still
> respond to delay_requests. I'm not sure how important that is.
NO MECHANISM is all about the clients.
There is no harm in letting the server respond. In fact it makes
sense to allow the response, for example in a mixed network with some
clients doing E2E and others NO MECHANISM.
> initial_delay is currently not a port-specific option and it doesn't
> accept 0, which cannot be easily changed for compatibility reasons.
I meant doing what you suggested:
if (!tmv_is_zero(c->initial_delay) || best_dm == DM_NO_MECHANISM)
tsproc_set_delay(c->tsproc, c->initial_delay);
New option DM_NO_MECHANISM would set initial_delay to zero. (or throw
error when initial_delay is non-zero in config)
Thanks,
Richard
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
