ts2phc offset spike results in degraded system timing

[Cole Walker]

Brief Description
-----------------
On stx systems using the realtime linux kernel, timestamp messaged arriving to the ts2phc application can be delayed, resulting in a large master offset calculation that causes ts2phc to adjust the NIC clock incorrectly.

Severity
--------
Provide the severity of the defect.
<Major: System/Feature is usable but degraded>

Steps to Reproduce
------------------
Natural reproduction of the behaviour is inconsistent, as it appears to be related to CPU load. The behaviour can be artificially replicated with these steps:

Locate the PID for the ice-gnss thread:
ps aux | grep ice-gnss

Affine the process to a single platform cpu
taskset -p -c 0 $PID

Generate a burst of CPU load on that core
sudo chrt -f 1 taskset -c 32 timeout 1s taskset -c 0 /bin/bash -c 'date -Is; while : ; do : ; done'; date -Is

Expected Behavior
------------------
When ts2phc is synced, it should continue making only small incremental adjustments to the clock

Actual Behavior
----------------
ts2phc calculates that the clock is over 1 second out of sync and begins making large adjustments to compensate

Reproducibility
---------------
Intermittent, but can be reliably reproduced using above procedure

System Configuration
--------------------
AIO-SX and AIO-DX

Branch/Pull Time/Commit
-----------------------
Master

Last Pass
---------
Unknown

Timestamp/Logs
--------------
Attach the logs for debugging (use attachments in Launchpad or for large collect files use: https://files.starlingx.kube.cengn.ca/)
Provide a snippet of logs here and the timestamp when issue was seen.
Please indicate the unique identifier in the logs to highlight the problem

Test Activity
-------------
Developer testing

Workaround
----------
Unknown

[Ghada Khalil (gkhalil)]

Fixed by: https://review.opendev.org/c/starlingx/integ/+/914821
Merged on April 2

Note: The LP was not updated automatically because the Closes-Bug syntax was incorrect