|
# WR Streamer statistics
|
|
# WR Streamer statistics
|
|
|
|
|
|
The `xrtx_streamers_stats` module included in the
|
|
The `xrtx_streamers_stats` module included in the [`xwr_streamer`](/WR-Streamers) module produces performance-related data that can be used for advanced diagnostics and monitoring. The module generates information on streamer module function in terms of:
|
|
[`xwr_streamer`](/WR-Streamers) module produces performance-related data
|
|
|
|
that can be used for advanced diagnostics and monitoring.
|
|
|
|
The module generates information on streamer module function in terms
|
|
|
|
of:
|
|
|
|
|
|
|
|
- **Data integrity**: includes the number of frames sent, frames
|
|
- **Data integrity**: includes the number of frames sent, frames
|
|
received as well as information on the number of lost frames and
|
|
received as well as information on the number of lost frames and
|
|
lost blocks.
|
|
lost blocks.
|
|
- **Timing Performance**: includes information such as maximum and
|
|
- **Timing Performance**: includes information such as maximum and
|
|
minimum latency values and the accumulated latency.
|
|
minimum latency values and the accumulated latency.
|
|
|
|
- **Fixed-latency operation**: includes the number of frames that missed the latency deadline or were released because the intended latency required too much waiting (timeout)
|
|
|
|
|
|
This information can be read using wishbone interface and it is
|
|
This information can be read using wishbone interface and it is
|
|
available via WR PTP Core, WR PTP Core exposes this information via
|
|
available via WR PTP Core, WR PTP Core exposes this information via
|
|
shell command (diag) and SNMP agent.
|
|
shell command (diag) and SNMP agent.
|
|
|
|
|
|
The `xrtx_streamers_stats` module can be reset and one can take a
|
|
The `xrtx_streamers_stats` can be reset and one can take a
|
|
snapshot via any type of access (from wishbone interface and via WR PTP
|
|
snapshot via any type of access (from wishbone interface and via WR PTP
|
|
Core via diag command or SNMP set command):
|
|
Core via diag command or SNMP set command):
|
|
|
|
|
|
- reset - resets the **Data integrity** and **Timing Performance**
|
|
- reset - resets the **Data integrity**, **Timing Performance** and **Fixed-latency operation**
|
|
information and timestamps the reset time. The timestamp can be
|
|
information and timestamps the reset time. The timestamp can be
|
|
useful when reading the available information to know since when
|
|
useful when reading the available information to know since when
|
|
this information has been accumulated.
|
|
this information has been accumulated.
|
... | @@ -33,6 +30,10 @@ Core via diag command or SNMP set command): |
... | @@ -33,6 +30,10 @@ Core via diag command or SNMP set command): |
|
latency (`latency_acc_o `), and the count of the accumulated latency
|
|
latency (`latency_acc_o `), and the count of the accumulated latency
|
|
values (`latency_cnt_o `) must be read coherently.
|
|
values (`latency_cnt_o `) must be read coherently.
|
|
|
|
|
|
|
|
**NOTE:** The statistics are started from the beginning of design operation (as soon as the system reset is released). However, at the very beginning of system operation, there is no valid WR time, thus the
|
|
|
|
initial timestamp is meaningless (it is zero thus the epoch in 1970). Moreover, the latency statistics are taken
|
|
|
|
only when WR time is valid. Thus, the reset is performed automatically as soon as the WR time is available, the first time after the system reset/powerup.
|
|
|
|
|
|
-----
|
|
-----
|
|
|
|
|
|
## Module structure
|
|
## Module structure
|
... | @@ -116,6 +117,6 @@ Core via diag command or SNMP set command): |
... | @@ -116,6 +117,6 @@ Core via diag command or SNMP set command): |
|
|
|
|
|
-----
|
|
-----
|
|
|
|
|
|
6 July 2017
|
|
12 May 2020
|
|
|
|
|
|
|
|
|