\title{Planning of SocketCAN gateway evaluation}
\author{M. Sojka, P. Píša, Z. Hanzáelk\\
Czech Technical University in Prague}
-\date{September 30, 2010}
+\date{Version 1.1\\October 27, 2010}
\begin{document}
on MPC5200 system.
\end{enumerate}
+\subsection{PC-only configuration}
+\label{sec:pc-only-conf}
+
The first HW configuration, depicted in Figure \ref{fig:c1}, will be
used to measure the timing properties of communication between two CAN
\begin{figure}[h!]
\centering
\includegraphics[scale=.5]{configuration1.png}
- \caption{PC-only configuration}
+ \caption{PC-only configuration.}
\label{fig:c1}
\end{figure}
+
+\subsection{PC and gateway in MPC5200}
+\label{sec:pc-gateway-mpc5200}
+
In the second HW configuration (Fig. \ref{fig:c2}) messages will be
send from one interface on the PC (can0) and the gateway will route
them to the second bus connected to another interface on the same PC
\begin{figure}[h!]
\centering
\includegraphics[scale=.5]{configuration2.png}
- \caption{Configuration with PC and the gateway}
+ \caption{Configuration with PC and the gateway.}
\label{fig:c2}
\end{figure}
+
+Gateway will be connected via a dedicated Ethernet network to the PC
+which will contain root filesystem mounted by gateway via NFS.
+
\section{Measurement software}
\label{sec-2}
\subsection{Traffic generator}
\label{sec-2_1}
-
We plan to generate traffic in several possible modes:
\begin{enumerate}
\item Send the messages as fast as possible to fully utilize the bus and
the PC will be almost always full. For that reason the time when
the message is put into the queue will be different from the time
the message appears on the bus. The later time will be determined
- by receiving the message on can1.
+ by receiving the message on can1 (see Fig. \ref{fig:c2}).
\item Send the message only after the corresponding message is received
on the second interface. In this case there will be at most one
message in the TX queue and time between sending on can0 and
\subsection{Kernel versions}
\label{sec:kernel-versions}
-We want to run the gateway with vanilla and rt\_preempt kernels.
-Currently we run 2.6.31 kernels on our board but we want to upgrade to
-2.6.33 (so far -rt is available only for .33) and run the experiments
-on these newer kernel. We do not expect major problems with upgrading.
+We will run the gateway with vanilla and rt\_preempt kernels (2.6.33.7
+and 2.6.33.7-rt29). Not that rt\_preempt patch is not available for a
+more recent kernel version as of this writing.
\subsection{One-way traffic}
\label{sec:one-way-traffic}
-We plan to test the following gateway configurations (and maybe even
-combinations of these configurations):
+In this test we will use a single kernel gateway as depicted in Figure
+\ref{fig:gw-single}. We plan to test the following gateway
+configurations (and maybe even combinations of these configurations):
\begin{enumerate}
\item Routing of all frames, without modifications
\item Routing of selected frames only, without modifications
\item different number of modifications per ``job''
\end{itemize}
-\item Routing of either SFF or ELF frames only (there should be
+\item Routing of either SFF or EFF frames only (there should be
difference because of how \texttt{can\_rcv\_filter()} is implemented.
\end{enumerate}
+\begin{figure}[h!]
+ \centering
+ \includegraphics[scale=.5]{gw-signle}
+ \caption{Simple gateway configuration.}
+ \label{fig:gw-single}
+\end{figure}
+
+
\subsection{Bi-directional traffic}
\label{sec:bi-direct-gatew}
the low priority messages will be dropped and it will be seen whether
this is true in reality.
+\subsection{Multiple gateways}
+\label{sec:multiple-gateways}
+
+We will also test properties of multiple gateways. In the first case
+(Figure \ref{fig:multi}) there will be multiple (variable number)
+gateways interconnected by multiple virtual CAN busses. In the second
+case (Figure \ref{fig:multi2}), a single virtual bus will be used and
+multiple gateways will route the messages. The gateways will also
+modify the frames to avoid CAN-ID clashes on vcan0.
+
+
+\begin{figure}
+ \centering
+ \includegraphics[scale=.8]{gw-multi}
+ \caption{Multiple gateways with multiple virtual CAN buses.}
+ \label{fig:multi}
+\end{figure}
+
+\begin{figure}
+ \centering
+ \includegraphics[scale=.8]{gw-multi-mod}
+ \caption{Multiple gateways with a single virtual CAN bus.}
+ \label{fig:multi2}
+\end{figure}
+
+\subsection{Userspace gateway}
+\label{sec:userspace-gateway}
+
+We will also compare kernel-based gateway (considered above) with the
+usespace gateway created by \texttt{candump -s2 -b can1 can0}.
+
+\subsection{Gateway load}
+\label{sec:gateway-load}
+
+The experiments will be repeated for each of the following loads
+imposed on MPC5200:
+\begin{itemize}
+\item No load,
+\item CPU load,
+\item Ethernet load.
+\end{itemize}
+
+
\section{Presentation of results}
\label{sec-4}
The measured latencies of individual messages will be statistically
\begin{figure}
\centering
\includegraphics{ethflood.pdf}
- \caption{Latency profile from our previous benchmark}
+ \caption{Latency profile from our previous benchmark.}
\label{fig:lp}
\end{figure}
-\section{Questions}
-\label{sec-5}
-
-\begin{enumerate}
-\item Are the hardware configurations sufficient for you or are you
- interested in different setups?
-\item In the case of lost messages, are you interested in detailed
- statistics of which messages are lost, etc?
-\item Are you interested in measuring any other gateway
- configurations?
- \item Are you also interested in what happens when the gateway is
- loaded by other activities (CPU, Ethernet, etc.)?
-\end{enumerate}
\end{document}
projects / can-benchmark.git / blobdiff