Hi Richard,

sorry again to continue this thread.

Inside port_synchronize() I noticed this:

case SERVO_LOCKED:
    port_dispatch(p, EV_MASTER_CLOCK_SELECTED, 0);
    break;
case SERVO_LOCKED_STABLE:
    message_interval_request(p, last_state, sync_interval);
    break;

Supposing to have the port X as SLAVE with "SERVO_LOCKED_STABLE" state,
after a while I disable the ingoing traffic (SYNC/ANNUNCE) to the port X,
switching to another port Y still keeping the SERVO_LOCKED_STABLE
condition. The check_offset_threshold(), called by sample_sample(), should
always return "1' (true) because the s->curr_offset_values == 0  (and it is
fixed to servo_num_offset_values only in SERV_UNLOCKED and SERVO_JUMP
conditions).

In these conditions the SERVO_LOCKED will not happen and the
port_dispatach(p, EV_MASTER_CLOCK_SELECTED, 0) should never be called,
resulting in a forever "UNCALIBRATED" condition.

Are my deductions right?

Thanks again for your support,

luigi


[global]
*...*
*servo_offset_threshold 100*
*servo_num_offset_values 64*
...

Il giorno dom 14 mar 2021 alle ore 19:37 Luigi 'Comio' Mantellini <
luigi.mantell...@gmail.com> ha scritto:

>
>
> Il giorno dom 14 mar 2021 alle ore 16:58 Richard Cochran <
> richardcoch...@gmail.com> ha scritto:
>
>> On Sun, Mar 14, 2021 at 10:30:31AM +0100, Luigi 'Comio' Mantellini wrote:
>> > The failures are part of the test and after the HW restoring I'm pretty
>> > sure that the protocol waltzer is running fine. I noticed that the ptp4l
>> > shows master offset and delay summaries. In order to have offset and
>> delay
>> > values, the Sync/DelayReq/DelayResp should be correctly exchanged, am I
>> > right?
>>
>> Right.
>>
>>
>
>> > Another observation is that Killing and restarting again the ptp4l I
>> reach
>> > the SLAVE state without servo jump.
>>
>> Probably because the offset is below the threshold.
>>
>> I knew, I remarked this only to say that the clock was attached.
>
> > Just now I placed the servo_reset() inside handle_state_decision_event()
>> > when we have a fresh new best master, after the clock_freq_est_reset()
>> > method.
>>
>> Don't do that.  That spoils your synchronization for nothing.
>>
>> I will better investigate.
>
> Thanks again
>
> luigi
>
> Thanks,
>> Richard
>>
>
>
> --
> *Luigi 'Comio' Mantellini*
> My Professional Profile <http://www.linkedin.com/in/comio>
>
> *"UNIX is very simple, it just needs a genius to understand its
> simplicity." [cit.]*
>
>

-- 
*Luigi 'Comio' Mantellini*
My Professional Profile <http://www.linkedin.com/in/comio>

*"UNIX is very simple, it just needs a genius to understand its
simplicity." [cit.]*
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Reply via email to