Hi,
> No, in a correctly configured gPTP network, all of the nodes have the same
> settings.
Hmm, I don't agree ... The purpose of Signaling messages was to
communicate/request rates that are needed by the slave/requester device and
each slave device can have different "needs". What is more, as
Currently servo state stays in S3 (SERVO_LOCKED_STABLE) even though
clock offset increases above servo_offset_threshold value (but is still
below step_threshold value). With this change servo will switch to S2
(SERVO_LOCKED) every time clock offset is bigger than servo_offset_threshold.
It will sti
Currently servo state stays in S3 (SERVO_LOCKED_STABLE) even though
clock offset increases above servo_offset_threshold value (but is still
below step_threshold value). With this change servo will switch to S2
(SERVO_LOCKED) every time clock offset is bigger than servo_offset_threshold.
It will sti
717
>>>> S2 -> S3 (clock offset < servo_offset_threshold) x servo_num_offset_values
ptp4l[384.734]: master offset886 s3 freq +72980 path delay 717
ptp4l[385.484]: master offset705 s3 freq +72909 path delay 722
...
Cheers,
Pawel
> -----Original Me
Hi Guys,
I'm pretty sure I'm not catching all dependencies here, so if you say it might
break something, I'll take that :-) On the other hand, servo state transitions
S2->S3 (and also S3->S0 for example) is done based on clock offset value, so
for me (in my setup I'm tracking it either via logs
> The servo state is an internal variable has no relevance to outside
> observers.
> Apparently, me and Dale Smith are not the only ones interested in PTP servo
> state. See
> https://docs.baslerweb.com/precision-time-protocol#additional-parameters
> (Basler GigE cameras).
> PtpServoStatus: I
