Agreed. That's why I'm proposing a new value that would be properly discussed and explained in the user manual (forget about the original patch in the discussion subject for now, this would need to be a completely different change).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.
Well, that is actually what people expect from a time sync daemon. Chrony has it (* or + in `chronyc sources`), systemd has it ("System clock synchronized: yes" in timedatectl) etc.People naively want a simple Boolean flag. However, the reality is that there is no simple answer to the question, is my computer synchronized.
What are then servo_num_offset_values and servo_offset_threshold config options? These are two parameters that configure when an (almost) boolean flag is flipped from SERVO_LOCKED to SERVO_LOCKED_STABLE.I will NOT provide any kind of simple minded and misleading status.
I agree that the definition of stable and locked servo may differ case-by-case. But the algorithm used for the current internal servo status doesn't seem too bad to me (it is simple, understandable and useful). If the public servo status were added and it would be explained that it just reports whether the last X offsets were under Y ns, there is nothing misleading. Users would understand what the reported status means, and they could configure what level of delay they consider acceptable. The public servo status does not need to be named SERVO_LOCKED_STABLE to lower even more the potential for confusion.
If I haven't convinced you with this reasoning, I think we can end this discussion (unless someone else jumps in).
Thank you, Martin
smime.p7s
Description: Elektronicky podpis S/MIME
_______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
