% Created 2010-09-30 Čt 12:40
\documentclass[11pt]{scrartcl}
\usepackage[utf8]{inputenc}
% \usepackage[T1]{fontenc}
\usepackage{fixltx2e}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{float}
\usepackage{wrapfig}
\usepackage{soul}
% \usepackage{t1enc}
\usepackage{textcomp}
\usepackage{marvosym}
\usepackage{wasysym}
\usepackage{latexsym}
\usepackage{amssymb}
\usepackage{hyperref}
\hypersetup{
	breaklinks = true, %allow links to break over lines		
	pdffitwindow = true, %resize document window to fit document size			
	colorlinks = true,
% 	linkcolor = darkblue,
% 	citecolor = darkblue,
% 	urlcolor = darkblue,
	linkcolor = black,
	citecolor = black,
	urlcolor = black,
        plainpages=false,
	}
\providecommand{\alert}[1]{\textbf{#1}}

\title{Planning of SocketCAN gateway evaluation}
\author{M. Sojka, P. Píša, Z. Hanzáelk\\
Czech Technical University in Prague}
\date{Version 1.1\\October 27, 2010}

\begin{document}

\maketitle

% \setcounter{tocdepth}{1}
% \tableofcontents
% \vspace*{1cm}

% \section{Introduction}
% \label{sec:introduction}

\begin{abstract}
  This document specifies how the (mostly) temporal properties of
  SocketCAN-based CAN gateway will be evaluated.
\end{abstract}
\section{Hardware setup}
\label{sec-1}


We will use two hardware configurations for our experiments.

\begin{enumerate}
\item A single PC with Kvaser PCI quad-CAN card.
\item A single PC with Kvaser PCI quad-CAN card plus CAN gateway running
   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
interfaces in a single computer (PC) connected to the same CAN bus,
i.e. we will send messages from can0 and receive them on can1. The PC
will serve in further experiments as a load generator and measuring
system. These results be used later to determine which part of latency
is contributed by the PC and not by the measured gateway.



\begin{figure}[h!]
  \centering
  \includegraphics[scale=.5]{configuration1.png}
  \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
(can2). Optionally, additional interface (can1) will be connected to
the same bus as can0 and we will use the reception timestamp on this
interface to determine the time when the message appeared on the bus
0.


\begin{figure}[h!]
  \centering
  \includegraphics[scale=.5]{configuration2.png}
  \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}

We intend to develop an application that will run on the PC and will
be responsible for test traffic generation and measurement of the
communication latencies. The traffic will be generated on one
interface and received on the other(s) in the same computer.
Therefore, the TX and RX timestamps will be measured by the same clock
(TSC/HPET) which allows precise measurement of the latencies.
\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
   to check that gateway/driver does not drop messages. TX queue on
   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 (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
   receiving on can1 should be short.
\item (Optional) Burst sequences, but not continuous bus load. This mode
   will be used if the GW does not survive continuous traffic to find
   the maximum burst size that can be safely handled.
\end{enumerate}


The generator will be able to generate different ID/length/data
patterns similarly as \texttt{cangen}.
\section{Gateway configuration}
\label{sec-3}

\subsection{Kernel versions}
\label{sec:kernel-versions}
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}
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 Routing of all/selected frames with modifications
\begin{itemize}
\item different type of modifications (and/or/xor/set/crc)
\item different number of modifications per ``job''
\end{itemize}

\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}

It will be interesting to investigate the behavior of the gateway with
bi-directional traffic, i.e. the PC will generate traffic on both can0
and can3. If both busses are fully utilized by the traffic generator,
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
processed and histograms (latency profiles) will be generated from the
data. Latency profile (see the example from our previous benchmark in
Figure \ref{fig:lp}) is a sort of reverse-cumulative histogram with
logarithmic vertical axis. The advantage of using latency profiles is
that the worst-case behavior (bottom right part of the graph) is
``magnified'' by the logarithmic scale.

\begin{figure}
  \centering
  \includegraphics{ethflood.pdf}
  \caption{Latency profile from our previous benchmark.}
\label{fig:lp}
\end{figure}

\end{document}
