On Fri, 18 Aug 2023 at 14:36, Luigi Mantellini <luigi.mantell...@gmail.com>
wrote:
> Dear All,
>
> Starting from IEEE 1588-2019 Annex J, I'm trying to introduce a Performace
> monitoring Counters.
>
> The standard asks to keep up 98 records (96 for 15min records and 2 for 24h
> records).
>
> I tried to follow a more general approach keeping different circular buffer
> for 15min and 24h (and adding also 1h for test purpose).
>
> The patch need to be split, of course, but it's a starting point to have
> any
> feedbacks.
>
> Starting from config, I introduced 3 port level parameters in order to
> configure the circular buffer sizes/history:
>
> performance_monitor.15m_history (default 0, disabled)
> performance_monitor.1h_history (default 0, disabled)
> performance_monitor.24h_history (default 0, disabled)
>
> The parameters can also be changed using the management TLV PM_CONF_NP.
>
> When at least a pm is enabled, a PM_TIMER is armed (TFD_TIMER_ABSTIME
> aligned
> to 15min).
>
> When the PM_TIMER expires the sample is stored into circolar buffer and a
> notification is sent (NOTIFY_{PM15Mm,PM1H,PM24H}_UPDATE).
>
> The notification generates a {PM15M,PM1H,PM24H}_LAST_NP management message.
>
> A monitor process can receive the update and manage the data model
> according
> the IEEE 1588-2019 Annex J.
>
> In addition to above {PM15M,PM1H,PM24H}_LAST_NP management message, I
> introduced also messages to retrive the CURRENT and the complete HISTORY:
>
> x_LAST_NP Get the last SAVED sample with the delta counters.
> x_CURRENT_NP Get the current (NOT saved yet) sample.
> x_HISTORY_NP Get the complete history of all records.
>
> (where x is PM15M, PM1H or PM24H)
>
> All mamagement messages use the same TLV format.
>
> I already known that the implementation is far to be accettable, and
> should be
> split in more patches.
>
> I ask for any feedbacks. My main issue is the x_HISTORY_NP messages. Using
> a
> 1500 bytes frame there is not enough space to keep an huge history,
> causing a
> frame corruption (bad message). Any idea to handle huge management
> messages?
>
> I also tried to imaginate a x_GET_NP to read a specific item. In this case
> I
> need to put an index vale into the GET message in order to handle the
> answer.
> Unfortunately sent GET messages are empty by construction and I cannot
> prefill with an index value. (WA: use SET?).
>
I think using 'SET' is OK.
On request you put the index as first value and leave the rest of the TLV
with zeroes.
Then respond with the same index and fill the TLV with statistics values.
As I remember, the response of a set can use the same TLV.
>From IEEE 1558-2019 "Table 57 - Values of the actionField"
"SET"
"The PTP management message shall carry a single management TLV.
The managementId field of the TLV indicates the specific information values
that need to be set.
If the data identified by the managementId consists of several fields, the
update shall be considered as an atomic action and the failure to update
any item shall be considered an error in the execution of the SET.
Attempts to set a static or nonconfigurable value shall return a management
error status TLV (see 15.5.4).
TLVs with data definitions that mix configurable and nonconfigurable data
are not permitted.
An addressed PTP Port or PTP Instance shall respond with a PTP management
message with the actionField value set to RESPONSE.
If no error occurs, the TLV in the PTP management message shall contain the
current values of the data identified by the managementId.
If an error occurs, the TLV shall be a management error status TLV."
I understand that the response should use the same TLV.
On both the SET and the RESPONSE, the index value is the same.
Although the standard forbids setting a static or nonconfigurable value.
It also forbids mixing, so what about using only nonconfigurable and
non-static values?
I think we can skip this rule for statistics.
And as the index and the statistics are both nonconfigurable and non
static data. I think we are on safe ground.
Erez
> I will appreciate any comments.
>
> Thanks agian and best regards,
>
> luigi
>
>
>
> Luigi Mantellini (1):
> Add Port Performance Monitor support
>
> config.c | 3 +
> ddt.h | 2 +
> e2e_tc.c | 36 +++++++
> fd.h | 1 +
> makefile | 2 +-
> msg.h | 2 +-
> notification.h | 3 +
> p2p_tc.c | 36 +++++++
> pmc.c | 123 +++++++++++++++++++++-
> pmc_common.c | 66 +++++++++++-
> port.c | 277 ++++++++++++++++++++++++++++++++++++++++++++++++-
> port_pm.c | 212 +++++++++++++++++++++++++++++++++++++
> port_pm.h | 141 +++++++++++++++++++++++++
> port_private.h | 7 ++
> tlv.c | 80 ++++++++++++++
> tlv.h | 35 +++++++
> 16 files changed, 1017 insertions(+), 9 deletions(-)
> create mode 100644 port_pm.c
> create mode 100644 port_pm.h
>
> --
> 2.41.0
>
>
>
> _______________________________________________
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
>
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
