Commit aef29c3c authored by Adam Wujek's avatar Adam Wujek 💬 Committed by Grzegorz Daniluk

docs/specifications/management: rename ppsi to ptp in wrs_failures

PTP related objects should be called WR-SWITCH-MIB::ptp* instead of
WR-SWITCH-MIB::ppsi*. People need to know it's PTP related, not necessary that
the running PTP engine is PPSi.
Signed-off-by: Adam Wujek's avatarAdam Wujek <adam.wujek@cern.ch>
parent d82153e7
......@@ -5,21 +5,21 @@ WR network.\\
\noindent Faults leading to a timing error:
\begin{enumerate}
\item {\bf \emph{PPSi} went out of \texttt{TRACK\_PHASE}}
\item {\bf \emph{PTP/PPSi} went out of \texttt{TRACK\_PHASE}}
\label{fail:timing:ppsi_track_phase}
\begin{packed_enum}
\item [] \underline{Status}: TODO \emph{(depends on ppsi shm)}
\item [] \underline{Severity}: ERROR
\item [] \underline{Mode}: \emph{Slave}
\item [] \underline{Description}:\\
If \emph{PPSi} WR servo goes out of the \texttt{TRACK\_PHASE} state,
If \emph{PTP/PPSi} WR servo goes out of the \texttt{TRACK\_PHASE} state,
that means something bad has happened and switch has lost the
synchronization to its Master.
\item [] \underline{SNMP objects}:\\
\texttt{WR-SWITCH-MIB::ppsiServoState} \emph{(implemented as string)}\\
\texttt{WR-SWITCH-MIB::ppsiServoStateN} \emph{(not implemented, as integer)}
\texttt{WR-SWITCH-MIB::ptpServoState} \emph{(implemented as string)}\\
\texttt{WR-SWITCH-MIB::ptpServoStateN} \emph{(not implemented, as integer)}
%ppsiServoStateN shall contain state as a integer taken from ppsi shm
\item [] \underline{Note}: we should also monitor PPSi state inside the
\item [] \underline{Note}: we should also monitor PTP/PPSi state inside the
switch to build up the general WRS status word.
\end{packed_enum}
......@@ -34,12 +34,12 @@ WR network.\\
lost the link to its Master higher in the hierarchy or to external
clock), but Slave switch does not follow the jump.
\item [] \underline{SNMP objects}:\\
\texttt{WR-SWITCH-MIB::ppsiClockOffsetPs}\\
\texttt{WR-SWITCH-MIB::ppsiClockOffsetPsHR}
\texttt{WR-SWITCH-MIB::ptpClockOffsetPs}\\
\texttt{WR-SWITCH-MIB::ptpClockOffsetPsHR}
\item [] \underline{Note}: HR version is 32-bit signed value of the offset. With saturation on overflow and underflow.
\end{packed_enum}
\item {\bf Detected jump in the RTT value calculated by \emph{PPSI}}
\item {\bf Detected jump in the RTT value calculated by \emph{PTP/PPSi}}
\label{fail:timing:rtt_jump}
\begin{packed_enum}
\item [] \underline{Status}: DONE
......@@ -51,28 +51,28 @@ WR network.\\
means erroneous timestamp was generated either on Master or Slave side.
One cause of that could be the wrong value of the t24p transition point.
\item [] \underline{SNMP objects}:\\
\texttt{WR-SWITCH-MIB::ppsiRTT}
\texttt{WR-SWITCH-MIB::ptpRTT}
\item [] \underline{Note}: we should also monitor RTT variations inside
the switch to build up the general WRS status word.
\end{packed_enum}
\item {\bf Wrong $\Delta_{TXM}$, $\Delta_{RXM}$, $\Delta_{TXS}$,
$\Delta_{RXS}$ values are reported to the \emph{PPSi} daemon}
$\Delta_{RXS}$ values are reported to the \emph{PTP/PPSi} daemon}
\label{fail:timing:deltas_report}
\begin{packed_enum}
\item [] \underline{Status}: DONE
\item [] \underline{Severity}: ERROR
\item [] \underline{Mode}: \emph{all}
\item [] \underline{Description}:\\
If \emph{PPSi} doesn't get the correct values of fixed hardware delays,
If \emph{PTP/PPSi} doesn't get the correct values of fixed hardware delays,
it won't be able to calculate a proper Master-to-Slave delay. Although
the estimated offset in \emph{PPSi} is close to 0, WRS won't be
the estimated offset in \emph{PTP/PPSi} is close to 0, WRS won't be
synchronized to Master with the sub-nanosecond accuracy.
\item [] \underline{SNMP objects}:\\
\texttt{WR-SWITCH-MIB::ppsiDeltaTxM.<n>}\\
\texttt{WR-SWITCH-MIB::ppsiDeltaRxM.<n>}\\
\texttt{WR-SWITCH-MIB::ppsiDeltaTxS.<n>}\\
\texttt{WR-SWITCH-MIB::ppsiDeltaRxS.<n>}
\texttt{WR-SWITCH-MIB::ptpDeltaTxM.<n>}\\
\texttt{WR-SWITCH-MIB::ptpDeltaRxM.<n>}\\
\texttt{WR-SWITCH-MIB::ptpDeltaTxS.<n>}\\
\texttt{WR-SWITCH-MIB::ptpDeltaRxS.<n>}
\end{packed_enum}
\item {\bf \emph{SoftPLL} became unlocked}
......@@ -146,7 +146,7 @@ WR network.\\
\item [] \underline{Severity}: ERROR
\item [] \underline{Mode}: \emph{all}
\item [] \underline{Description}:\\
In this case, \emph{PPSi} will fail to stay synchronized and provide
In this case, \emph{PTP/PPSi} will fail to stay synchronized and provide
synchronization. Even if WR servo is in the \texttt{TRACK\_PHASE} state,
it calculates new phase shift based on the Master-to-Slave delay
variations. To calculate these variations, it still needs timestamped
......@@ -181,8 +181,8 @@ WR network.\\
By not supported SFP for WR timing we mean a transceiver that doesn't
have the \emph{alpha} parameter and fixed hardware delays defined in the
SFP database (\emph{/wr/etc/sfp\_database.conf}). The consequence is
\emph{PPSi} not having the right values to estimate link asymmetry.
Despite \emph{PPSi} offset being close to 0 \emph{ps}, the device won't
\emph{PTP/PPSi} not having the right values to estimate link asymmetry.
Despite \emph{PTP/PPSi} offset being close to 0 \emph{ps}, the device won't
be properly synchronized.
\item [] \underline{SNMP objects}:\\
\texttt{WR-SWITCH-MIB::portSfpVN.<n>}\\
......@@ -199,34 +199,34 @@ WR network.\\
\ref{fail:other:sfp} in section \ref{sec:other_fail}.
\end{packed_enum}
\item {\bf \emph{PPSi} process has crashed/restarted}
\item {\bf \emph{PTP/PPSi} process has crashed/restarted}
\label{fail:timing:ppsi_crash}
\begin{packed_enum}
\item [] \underline{Status}: TODO \emph{(depends on monit)}
\item [] \underline{Severity}: ERROR
\item [] \underline{Mode}: \emph{all}
\item [] \underline{Description}:\\
If the \emph{PPSi} daemon crashes we lose any synchronization
If the \emph{PTP/PPSi} daemon crashes we lose any synchronization
capabilities. If, in the future, we will have another process that could
bring \emph{PPSi} back to live, such a restart would still create a time
bring \emph{PTP/PPSi} back to live, such a restart would still create a time
jump and has to be reported.
\item [] \underline{SNMP objects}:\\
\texttt{WR-SWITCH-MIB::ppsiRunCnt} \emph{(not implemented)}\\
\texttt{WR-SWITCH-MIB::ptpRunCnt} \emph{(not implemented)}\\
\texttt{HOST-RESOURCES-MIB::hrSWRunName.<x>} \emph{(implemented)}
\item [] \underline{Note}: list of the processes has to be monitored, if
\emph{PPSi} is there and if its PID has changed (it was restarted).
\emph{PTP/PPSi} is there and if its PID has changed (it was restarted).
\end{packed_enum}
\item {\bf \emph{HAL} process has crashed/restarted}
\label{fail:timing:hal_crash}
\begin{packed_enum}
\item [] \underline{Status}: TODO \emph{(depends on monit)}
\item [] \underline{Severity}: WARNING (but only after we modify PPSi so
\item [] \underline{Severity}: WARNING (but only after we modify PTP/PPSi so
it reconnects to HAL, and HAL does not re-initialize SoftPLL after
crash)
\item [] \underline{Mode}: \emph{all}
\item [] \underline{Description}:\\
If \emph{HAL} crashes, \emph{PPSi} is not able to communicate with
If \emph{HAL} crashes, \emph{PTP/PPSi} is not able to communicate with
hardware i.e. read phase shift, get timestamps, phase shift the clock
etc.
\item [] \underline{SNMP objects}:\\
......@@ -243,7 +243,7 @@ WR network.\\
\item [] \underline{Severity}: WARNING
\item [] \underline{Mode}: \emph{all}
\item [] \underline{Description}:\\
If there is a wrong configuration applied to the \emph{PPSi} or HAL
If there is a wrong configuration applied to the \emph{PTP/PPSi} or HAL
(i.e. wrong fixed delays, mode of operation etc.) there is not much we
can do. The responsibility of WR experts (or person deploying the
system) is to make sure that all the devices have correct initial
......@@ -514,14 +514,14 @@ between devices connected to the ports.\\
\item [] \underline{Description}:
\item [] \underline{SNMP objects}:\\
\texttt{HOST-RESOURCES-MIB::hrSWRunName.<x>}\\
\texttt{WR-SWITCH-MIB:ppsiRunCnt}\\
\texttt{WR-SWITCH-MIB:halRunCnt}\\
\texttt{WR-SWITCH-MIB:rtuRunCnt}\\
\texttt{WR-SWITCH-MIB:sshRunCnt}\\
\texttt{WR-SWITCH-MIB:udhcpdRunCnt}\\
\texttt{WR-SWITCH-MIB:rsyslogRunCnt}\\
\texttt{WR-SWITCH-MIB:snmpdRunCnt}\\
\texttt{WR-SWITCH-MIB:httpdRunCnt}
\texttt{WR-SWITCH-MIB::ptpRunCnt}\\
\texttt{WR-SWITCH-MIB::halRunCnt}\\
\texttt{WR-SWITCH-MIB::rtuRunCnt}\\
\texttt{WR-SWITCH-MIB::sshRunCnt}\\
\texttt{WR-SWITCH-MIB::udhcpdRunCnt}\\
\texttt{WR-SWITCH-MIB::rsyslogRunCnt}\\
\texttt{WR-SWITCH-MIB::snmpdRunCnt}\\
\texttt{WR-SWITCH-MIB::httpdRunCnt}
\item [] \underline{Note}: We have to monitor the list of running
processes and their PIDs. We shall distinguish between crucial
processes - error should be reported if one of them crashes; and less
......@@ -532,7 +532,7 @@ between devices connected to the ports.\\
Crucial processes (Error report if any of them crashes):
\begin{itemize}
\item \emph{PPSi}
\item \emph{PTP/PPSi}
\item \emph{WRSW\_RTUd} - after adding configuration preserving code
on restart, RTUd could be crossed out from this list
\item \emph{WRSW\_HAL}
......
......@@ -37,7 +37,7 @@ let NMS to decide when it's bad.\\
\hline
\end{tabular}
\item [] \texttt{WR-SWITCH-MIB::ppsiMode}\\
\item [] \texttt{WR-SWITCH-MIB::ptpMode}\\
Synchronization mode: Grand Master / Free-running Master / Slave
\item [] \texttt{WR-SWITCH-MIB::spllState}\\
\begin{packed_items}
......@@ -51,8 +51,8 @@ let NMS to decide when it's bad.\\
backup link (true / false)
\end{packed_items}
\item [] \texttt{WR-SWITCH-MIB::ppsiClockOffsetPs}\\
Clock offset calculated by PPSi
\item [] \texttt{WR-SWITCH-MIB::ptpClockOffsetPs}\\
Clock offset calculated by PTP/PPSi
\item [] \texttt{WR-SWITCH-MIB::tempFPGA}\\ - SCB temperature below the FPGA
\item [] \texttt{WR-SWITCH-MIB::tempScbPsu.1}\\ - SCB temperature near the
......@@ -87,36 +87,32 @@ the switch failures. These values are verbose and should not be used by
operators.
\subsubsection{PTP/WR parameters}
{\bf Note}: PTP related objects should be called \texttt{WR-SWITCH-MIB::ptp*}
instead of\\
\texttt{WR-SWITCH-MIB::ppsi*}. People need to know it's PTP related,
not necessary that the running PTP engine is PPSi.
\begin{itemize}[leftmargin=0pt]
\item [] \texttt{WR-SWITCH-MIB::ppsiGrandmasterID}\\ - is it really Grand
\item [] \texttt{WR-SWITCH-MIB::ptpGrandmasterID}\\ - is it really Grand
Master, so the same ID for the whole network ? or is it a Master higher in
the sync hierarchy for a given device ?
\item [] \texttt{WR-SWITCH-MIB::ppsiOwnID}
\item [] \texttt{WR-SWITCH-MIB::ppsiMode}
\item [] \texttt{WR-SWITCH-MIB::ppsiSyncSource}\\ - port number
\item [] \texttt{WR-SWITCH-MIB::ptpOwnID}
\item [] \texttt{WR-SWITCH-MIB::ptpMode}
\item [] \texttt{WR-SWITCH-MIB::ptpSyncSource}\\ - port number
\emph{wr0}/\emph{wr1}/... for Slave mode or \emph{ext} for Grand Master mode
\item [] \texttt{WR-SWITCH-MIB::ppsiServoState}\\ - string, WR servo state
\item [] \texttt{WR-SWITCH-MIB::ptpServoState}\\ - string, WR servo state
(\emph{SYNC\_IDLE}, \emph{SYNC\_SEC}, \emph{SYNC\_NSEC}, \emph{SYNC\_PHASE},
\emph{OFFSET\_STABLE}, \emph{TRACK\_PHASE}) (timing:
\ref{fail:timing:ppsi_track_phase})
\item [] \texttt{WR-SWITCH-MIB::ppsiServoStateN}\\ - would it be usefull to
report also ppsiServoState in a numeric form ? (timing:
\item [] \texttt{WR-SWITCH-MIB::ptpServoStateN}\\ - would it be usefull to
report also ptpServoState in a numeric form ? (timing:
\ref{fail:timing:ppsi_track_phase})
\item [] \texttt{WR-SWITCH-MIB::ppsiRTT}\\ - Round-trip delay ($delay_{MM}$)
\item [] \texttt{WR-SWITCH-MIB::ptpRTT}\\ - Round-trip delay ($delay_{MM}$)
(timing: \ref{fail:timing:rtt_jump})
\item [] \texttt{WR-SWITCH-MIB::ppsiDelayMS}\\ - one-way M-S delay
\item [] \texttt{WR-SWITCH-MIB::ptpDelayMS}\\ - one-way M-S delay
($delay_{MS}$)
\item [] \texttt{WR-SWITCH-MIB::ppsiLinkLength}
\item [] \texttt{WR-SWITCH-MIB::ppsiPhaseTracking}\\ - if phase tracking is
\item [] \texttt{WR-SWITCH-MIB::ptpLinkLength}
\item [] \texttt{WR-SWITCH-MIB::ptpPhaseTracking}\\ - if phase tracking is
enabled (only for WR-demo purposes I think)
\item [] \texttt{WR-SWITCH-MIB::ppsiClockOffsetPs}\\ (timing:
\item [] \texttt{WR-SWITCH-MIB::ptpClockOffsetPs}\\ (timing:
\ref{fail:timing:offset_jump})
\item [] \texttt{WR-SWITCH-MIB::ppsiSkew}
\item [] \texttt{WR-SWITCH-MIB::ppsiPhSetpoint}
\item [] \texttt{WR-SWITCH-MIB::ptpSkew}
\item [] \texttt{WR-SWITCH-MIB::ptpPhSetpoint}
\item [] \texttt{WR-SWITCH-MIB::ServoUpdates}
\item [] \texttt{WR-SWITCH-MIB::portLink.<n>}\\ (timing:
\ref{fail:timing:master_down}, \ref{fail:timing:no_frames}; data:
......@@ -128,10 +124,10 @@ not necessary that the running PTP engine is PPSi.
\item [] \texttt{WR-SWITCH-MIB::portPtpState.<n>}\\ - does it make sense to
report PTP state for each port ? (regular PTP, not WR state)
\item [] \texttt{WR-SWITCH-MIB::portPtpTxFrames.<n>}\\ - how many PTP frames
were sent from the port (counted by PPSi) (timing:
were sent from the port (counted by PTP/PPSi) (timing:
\ref{fail:timing:no_frames})
\item [] \texttt{WR-SWITCH-MIB::portPtpRxFrames.<n>}\\ - how many PTP frames
were received on the port (counted by PPSi) (timing:
were received on the port (counted by PTP/PPSi) (timing:
\ref{fail:timing:no_frames})
\item [] \texttt{WR-SWITCH-MIB::portActiveSlave.<n>}\\ - 0/1 to mark which one
is the active Slave (if there are also Backups and timing switchover)
......@@ -300,7 +296,7 @@ not necessary that the running PTP engine is PPSi.
\vspace{12pt}
(timing: \ref{fail:timing:ppsi_crash}, \ref{fail:timing:hal_crash}; data:
\ref{fail:data:rtu_crash}; other: \ref{fail:other:daemon_crash})
\item [] \texttt{WR-SWITCH-MIB::ppsiRunCnt}\\ - how many times PPSi daemon
\item [] \texttt{WR-SWITCH-MIB::ptpRunCnt}\\ - how many times PTP/PPSi daemon
has crashed (timing: \ref{fail:timing:ppsi_crash})
\item [] \texttt{WR-SWITCH-MIB::halRunCnt}\\ - how many times HAL daemon
has crashed (timing: \ref{fail:timing:hal_crash})
......@@ -322,7 +318,7 @@ not necessary that the running PTP engine is PPSi.
the critical configuration options was modified during the last
reconfiguration. Critical configuration options:
\begin{packed_items}
\item PPSi timing mode
\item PTP/PPSi timing mode
\item fixed hardware delays
\end{packed_items}
(timing: \ref{fail:timing:wrong_config})
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment