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

diff --git a/doc/plan.tex b/doc/plan.tex
new file mode 100644
index 0000000..99f7f14
--- /dev/null
+++ b/doc/plan.tex
@@ -0,0 +1,196 @@
+% 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{September 30, 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}
+
+
+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}
+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}
+\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.
+\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 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.
+
+\subsection{One-way traffic}
+\label{sec:one-way-traffic}
+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 ELF frames only (there should be
+   difference because of how \texttt{can\_rcv\_filter()} is implemented.
+\end{enumerate}
+
+\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.
+
+\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}
+\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}