On Wed, Mar 16, 2022 at 04:18:22PM +0100, Martin Pecka wrote: > > > The s3 doesn't mean "the clock of the current device is successfully > > synchronized" > > > > It only means that it converged during the first twenty seconds. > > After that, the state doesn't tell you anything. The actual condition > > could well reflect s2. > > I understand that. For us, knowing about the initial sync success would be > enough.
Then the notification would have to be just that, and not "servo locked" which is misleading at best. > As said earlier, our system assumes that once the sync is good, it > is good for the rest of operational time of our robot. In general, this is not a wise assumption. My job is protect the interests of the larger user base. Telling them "sync is good" when it really is uncertain is not user friendly. > But we can't start > operation before the sync is good. > > If you (Richard) are reluctant to publishing the internal servo status, > would you be inclined to implementing a "parallel" public servo status? That > would not be used in the state machine for any kind of decisions, but would > just be the flag at which users can look and say "yay, we're synced". People naively want a simple Boolean flag. However, the reality is that there is no simple answer to the question, is my computer synchronized. I will NOT provide any kind of simple minded and misleading status. > It > would be very similar to the internal servo status, but would have the jumps > from s3 to lower states allowed (someone already asked about this earlier). > This could cause no side effects (compared to when the jumps were allowed > for the internal servo status), but could be a pretty useful feature for > users. You can compute s0,1,2,3 trivially using the offsets from PMC. Maybe a real controls engineer would like to correct me (please!), but to my knowledge there is no simple, general method of looking at a series of estimated offsets and concluding whether the servo is stable and locked. Thanks, Richard _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
