On 16/03/2023 09:37, Miroslav Lichvar wrote:
> On Wed, Mar 15, 2023 at 05:44:43PM +0100, Maciek Machnikowski wrote:
>> If you start the synchronization process and see that it doesn't work
>> correctly then, this cleanup will prevent leaving invalid timestamps in
>> memory.
>
> Ok, this would be a good reason to invalidate the sample. So, it's not
> about the data getting stale (which should be detected by the consumer),
> but rather about users expecting restart of the process to reset
> everything.
>>
>> If timestamps were correct, it doesn't matter only as long as no one
>> else touches the clocks.
>
> I think that is always the case. It's not related to the producer
> exiting.
>
>> If the NTP process restarts, gets the time from a different source, and
>> returns to the stale timestamp (which will sit in memory forever) it may
>> incorrectly interpret this value as the right one.
>
> This can happen even without stopping phc2sys>
>> It also may backfire on embedded systems that stop the clock when going
>> to sleep. After resuming, the value kept in there will be incorrect as well.
>
> Again, that's unrelated to the process exit. You could have a command
> to drop old measurements after resuming, but restarting everything is
> easier.
>
> If you reword the commit message, I'm ok with it.
Would that work better:
The SHM is not cleared upon servo release when exiting the tool. This
leaves the last update in the shared memory region marked as valid.
If the tool that writes to the shared memory fails it can leave
incorrect timestamps marked as valid upon exit.
To prevent such behavior - invalidate the SHM data when releasing the
SHM servo.
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
