diff options
| -rw-r--r-- | systemenvironments.tex | 72 |
1 files changed, 35 insertions, 37 deletions
diff --git a/systemenvironments.tex b/systemenvironments.tex index b319c30..9421070 100644 --- a/systemenvironments.tex +++ b/systemenvironments.tex @@ -1,9 +1,9 @@ \section{System Environment} -In this section, we describe the system configuration requirements for the -continuous operation of the tools. The production environment differs in some +In this section, we describe the system configuration requirements for the +continuous operation of the tools. The production environment differs in some respects to those used for experimentation and in laboratory testing. Monitoring, -automatic recovery (in case of errors) and resiliance are crucial in 24/7 +automatic recovery (in case of errors) and resilience are crucial in 24/7 operations. The term \emph{production environment} will be used here to refer to such use. @@ -11,35 +11,34 @@ such use. Services running in a production environment are usually administered remotely, and must be able to run without user intervention, or connection. Traditionally, -such services are implemented (in UNIX terminology) as 'daemons'. These are -started and stopped using the init system contained within the distribution. +such services are implemented (in UNIX terminology) as `daemons'. These are +started and stopped using the init system contained within the distribution. The ODR-mmbTools cannot daemonise themselves, so this requires another approach: \paragraph{Screen multiplexer} A simple approach is to use a screen multiplexer such as \emph{GNU Screen} or -\emph{tmux} - either of these can be used to launch a session from which the -user can detach, and later re-attach at will - leaving the tools running within +\emph{tmux} - either of these can be used to launch a session from which the +user can detach, and later re-attach at will - leaving the tools running within it. Please see the relevant manpages for more information. -Although a screen multiplexer alone permits the tools to run without a user +Although a screen multiplexer alone permits the tools to run without a user being connected, it alone cannot automatically restart failed processes, and it -is unable to provide warnings in the case of a problem. +is unable to provide warnings in the case of a problem. -The dab-scripts \footnote{The dab-scripts are available on the Opendigitalradio -github.} ,already mentioned in \ref{usingexistingwebstreams}, can be employed to -monitor the processes and (if necessary) restart them, and send an alert via -email. +The dab-scripts, already mentioned in \ref{usingexistingwebstreams}, can be +employed to monitor the processes and (if necessary) restart them, and send an +alert via email. \paragraph{supervisord} -As an alternative to using the scripts, the execution of the tools can also be +As an alternative to using the scripts, the execution of the tools can also be carried out by a dedicated tool. \texttt{supervisor}\footnote{\url{http://supervisord.org}} is (as the name implies) such a tool. Once installed, supervisor reads its configuration file in \texttt{/etc/supervisor.conf} -and launches the processes that are to be monitored. Each process is described +and launches the processes that are to be monitored. Each process is described by a file. The following example assumes the tools are run as user \texttt{odr}, -and that the multiplex configuration is in \texttt{/home/odr/config.mux}, and -that ODR-DabMux is to be launched.The logs of ODR-DabMux is written to the +and that the multiplex configuration is in \texttt{/home/odr/config.mux}, and +that ODR-DabMux is to be launched.The logs of ODR-DabMux is written to the specified log files. \begin{lstlisting} @@ -66,9 +65,9 @@ be added: supervisorctl add ODR-DabMux \end{lstlisting} -Setting up more processes (such as any of the other tools) can be easily +Setting up more processes (such as any of the other tools) can be easily achieved by customising the configuration template above. Examples are provided -in the \texttt{mmbtools-aux} repository, under the \texttt{supervisor} folder - +in the \texttt{mmbtools-aux} repository, under the \texttt{supervisor} folder - these need to be changed to reflect the paths that are in use on your system. supervisor also includes a small web-server that can display the state of the @@ -78,36 +77,36 @@ the configuration file. \subsection{Logging} Collecting information about events is essential within a production environment. This information is essential forensic analysis, and tracing sources of trouble. -This is achieved through the logging of important messages that can be sent by +This is achieved through the logging of important messages that can be sent by the tools. ODR-DabMux and ODR-DabMod both support logging to standard error, to a file and to the system logger \texttt{syslog}. Logging to syslog is the most flexible approach; log information can be forwarded over the network to a -centralised logging server - where logs can then be filtered according to the -priority of each message. Both tools log to the LOCAL0 facility which in turn +centralised logging server - where logs can then be filtered according to the +priority of each message. Both tools log to the LOCAL0 facility which in turn can be redirected into an ODR-mmbtools specific log file. \sidenote{Describe rsyslog configuration} In order to avoid the log files from becomming undesirably large, \texttt{logrotate} -should be set to rotate the files automatically. +should be set to rotate the files automatically. \sidenote{Describe logrotate configuration} \subsection{Timing} -The ODR-mmbTools require the system time to be accurate in order for them to -function correctly - this is especially important when running a SFN, but is +The ODR-mmbTools require the system time to be accurate in order for them to +function correctly - this is especially important when running a SFN, but is also important for standalone transmitters when in a production environment. It -is also important to remember that most receivers have a clock that is -synchronised to the clock time which is being transmitted by the multiplex to +is also important to remember that most receivers have a clock that is +synchronised to the clock time which is being transmitted by the multiplex to which it has been tuned. The system needs to run a NTP client that synchronises the system time over the network. Correct synchronisation can be checked using the \texttt{lpeers} -command of the \texttt{ntpq} tool. The magnitude of the offset should be below -10 mS. +command of the \texttt{ntpq} tool. The magnitude of the offset should be below +$10$\ms. The performance of the NTP synchronisation should also be monitored permanently during operation. @@ -125,8 +124,8 @@ synchronisation, disk and network performance (and much more besides), there are also custom data sources for ODR-DabMux; These data sources include ZMQ input buffer monitoring (buffer level, underruns -and overruns) and the peak audio input levels (mono, or stereo). This data -source can be installed by copying \verb+doc/stats_dabmux_multi.py+ to +and overruns) and the peak audio input levels (mono, or stereo). It +can be installed by copying \verb+doc/stats_dabmux_multi.py+ to \texttt{/etc/munin/plugins.d}. They require that the ODR-DabMux management server is enabled in the configuration, and will automatically generate the graphs for the subchannels used in the configuration. @@ -135,7 +134,7 @@ graphs for the subchannels used in the configuration. \subsection{Real-time Scheduling} As a general principle, it is prudent not to run tools (that do not need superuser -privileges) as the \texttt{root} user. The same principle also applies to the +privileges) as the \texttt{root} user. The same principle also applies to the ODR-mmbTools, but care has to be taken that the tools can still request real-time scheduling when it is needed. @@ -147,21 +146,20 @@ odr - rtprio 65 odr - nice -10 \end{lstlisting} -If you have installed JACK with real-time privileges, you may find this has -already been configured for the 'audio' group, written as \texttt{@audio}, which -should suffice providing your desired user is a member of the @audio group. +If you have installed JACK with real-time privileges, you may find this has +already been configured for the `audio' group, written as \texttt{@audio}, which +should suffice providing your desired user is a member of the `audio' group. \subsection{Accessing the USRP as Non-root} Superuser privileges are not required to access USB-connected USRP devices, but sometimes the system lacks the configuration to enable normal users to communicate with the device. - In that case, it is necessary to add a rule file for \texttt{udev}. This file is included in the UHD sources, but might not have been automatically installed. - The file is called \texttt{10-uhd-usrp.rules}, should be placed into \texttt{/etc/udev/rules.d/} and should contain + { \footnotesize \begin{verbatim} #USRP1 |