X-Git-Url: http://rtime.felk.cvut.cz/gitweb/can-benchmark.git/blobdiff_plain/83652d8bb1c9ba1486909395264e729bb043e26c..1957e8a71018c7edd78304f08a37b799b308ae8e:/doc/plan.tex

diff --git a/doc/plan.tex b/doc/plan.tex
index 99f7f14..0cbde98 100644
--- a/doc/plan.tex
+++ b/doc/plan.tex
@@ -32,7 +32,7 @@
 \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}
 
@@ -61,6 +61,9 @@ We will use two hardware configurations for our experiments.
    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
@@ -75,9 +78,13 @@ is contributed by the PC and not by the measured gateway.
 \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
@@ -90,9 +97,13 @@ interface to determine the time when the message appeared on the bus
 \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}
 
@@ -105,7 +116,6 @@ Therefore, the TX and RX timestamps will be measured by the same clock
 \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
@@ -113,7 +123,7 @@ We plan to generate traffic in several possible modes:
    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
@@ -131,15 +141,15 @@ patterns similarly as \texttt{cangen}.
 
 \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
@@ -149,10 +159,18 @@ combinations of these configurations):
 \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}
 
@@ -163,6 +181,49 @@ some messages must definitely be dropped at some point. We expect that
 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
@@ -176,21 +237,8 @@ that the worst-case behavior (bottom right part of the graph) is
 \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}
