starlingx
/
docs
Code Issues Proposed changes

Added double ticks in the ts2phc parameter (dsr8mr3) 

Original review: https://review.opendev.org/c/starlingx/docs/+/916374

Change-Id: Ic082f56810fe7142f6f89374c07d45c8e0f560a7
Signed-off-by: Ngairangbam Mili <ngairangbam.mili@windriver.com>
This commit is contained in:
Ngairangbam Mili 2024-04-29 03:28:04 +00:00
parent dcd23abd66
commit 3ae3f9140a
1 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
doc/source/system_configuration/kubernetes/advanced-ptp-configuration-334a08dc50fb.rst
View File

@ -208,26 +208,26 @@ The log output for dynamically updated values can be found in
Ts2phc Offset Spike Mitigation
------------------------------
Ts2phc can be configured to detect and ignore intermittent offset spikes that
``ts2phc`` can be configured to detect and ignore intermittent offset spikes that
may result in incorrect clock adjustments. This behaviour is controlled using
the global instance parameter ``max_phc_update_skip_cnt``. The
``max_phc_update_skip_cnt`` parameter is the number of consecutive offset
spikes in a row that will be ignored. For example, setting
``max_phc_update_skip_cnt`` to 120 would allow ts2phc to ignore 120 consecutive
``max_phc_update_skip_cnt`` to 120 would allow ``ts2phc`` to ignore 120 consecutive
offset spike incidents before adjusting the clock.
Offset Spike Characterization
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The |prod| systems using the realtime kernel may experience an intermittent
offset spike behaviour in ts2phc. This intermittent offset spike behaviour
results from |GNSS| messages that take time to arrive at the userspace ts2phc
application. The delayed |GNSS| messages can cause ts2phc application to
calculate an incorrect adjustment value for the |PHCs|. This results in ts2phc
offset spike behaviour in ``ts2phc``. This intermittent offset spike behaviour
results from |GNSS| messages that take time to arrive at the userspace ``ts2phc``
application. The delayed |GNSS| messages can cause ``ts2phc`` application to
calculate an incorrect adjustment value for the |PHCs|. This results in ``ts2phc``
making large adjustments to its |PHCs| and can cause unstable system time. An
example of this behaviour can be seen in the log snippet below. If log events
similar to the given example are observed, configuring offset spike mitigation
in ts2phc can improve timing stability by detecting and ignoring these large
in ``ts2phc`` can improve timing stability by detecting and ignoring these large
offset calculations.
Example:
@ -266,10 +266,10 @@ Example:
Configure Offset Spike Mitigation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The offset spike mitigation behaviour is enabled in ts2phc by default with a
The offset spike mitigation behaviour is enabled in ``ts2phc`` by default with a
value of ``max_phc_update_skip_cnt`` = 120.
To configure the number of consecutive offset spikes that will be ignored by ts2phc, use the
To configure the number of consecutive offset spikes that will be ignored by ``ts2phc``, use the
following |PTP| instance parameter:
.. code-block:: none
@ -279,7 +279,7 @@ following |PTP| instance parameter:
# Apply the configuration. This will restart all PTP services.
system ptp-instance-apply
The value 120 will allow ts2phc to ignore up to 120 consecutive offset spikes.
The value 120 will allow ``ts2phc`` to ignore up to 120 consecutive offset spikes.
This value may need to be adjusted based on testing and observation in your environment.
Consecutive occurrences are not observed often, with subsequent updates
arriving in a timely manner.