> On Mar 25, 2019, at 7:15 AM, Richard Cochran <richardcoch...@gmail.com> wrote:
>
> On Mon, Mar 18, 2019 at 03:51:30PM -0700, Vedang Patel wrote:
>> @@ -98,8 +114,21 @@ double servo_sample(struct servo *servo,
>>
>> r = servo->sample(servo, offset, local_ts, weight, state);
>>
>> - if (*state != SERVO_UNLOCKED)
>> + switch (*state) {
>> + case SERVO_UNLOCKED:
>> + servo->curr_offset_values = servo->num_offset_values;
>> + break;
>> + case SERVO_LOCKED:
>> + if (check_offset_threshold(servo, offset)) {
>> + *state = SERVO_LOCKED_STABLE;
>> + }
>> + /* fall through. */
>> + case SERVO_JUMP:
>> servo->first_update = 0;
>> + break;
>> + case SERVO_LOCKED_STABLE:
>
> Once you are in this state, and the offset exceeds the threshold,
> shouldn't the FSM transition back to SERVO_LOCKED?
>
> In this case I would expect the slave to request the higher Sync rate
> once again.
>
> Thoughts?
>
It might be a good idea to transition to the SERVO_LOCKED state. But, I am
wondering if it should be the same as initial interval because it assumes that
the clock offset will be huge in the beginning. If the rate is increased
suddenly because of a single spike in the offset, it might affect other
critical streams which are trying to transmit. The initial offset is probably
assuming that the clock offset is a huge and the system is still booting so
other critical processes have not started yet.
What do you think?
-Vedang
> Thanks,
> Richard
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
