doc: Add plan for socketcan gw testing
authorMichal Sojka <sojkam1@fel.cvut.cz>
Thu, 30 Sep 2010 20:07:10 +0000 (22:07 +0200)
committerMichal Sojka <sojkam1@fel.cvut.cz>
Thu, 30 Sep 2010 20:07:10 +0000 (22:07 +0200)
doc/configuration1.png [new file with mode: 0644]
doc/configuration2.png [new file with mode: 0644]
doc/ethflood.pdf [new file with mode: 0644]
doc/plan.tex [new file with mode: 0644]
doc/plan.txt [new file with mode: 0644]

diff --git a/doc/configuration1.png b/doc/configuration1.png
new file mode 100644 (file)
index 0000000..5730237
Binary files /dev/null and b/doc/configuration1.png differ
diff --git a/doc/configuration2.png b/doc/configuration2.png
new file mode 100644 (file)
index 0000000..fb29a48
Binary files /dev/null and b/doc/configuration2.png differ
diff --git a/doc/ethflood.pdf b/doc/ethflood.pdf
new file mode 100644 (file)
index 0000000..4f6d8ee
Binary files /dev/null and b/doc/ethflood.pdf differ
diff --git a/doc/plan.tex b/doc/plan.tex
new file mode 100644 (file)
index 0000000..99f7f14
--- /dev/null
@@ -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}
diff --git a/doc/plan.txt b/doc/plan.txt
new file mode 100644 (file)
index 0000000..4b0453e
--- /dev/null
@@ -0,0 +1,119 @@
+#+TITLE: Plan of SocketCAN GW tests
+
+* Hardware setup
+
+We will use two hardware configurations for our experiments.
+
+1) A single PC with Kvaser PCI quad-CAN card.
+
+2) A single PC with Kvaser PCI quad-CAN card plus CAN gateway running
+   on MPC5200 system.
+
+The first configuration will be used to measure the timing properties
+of communication between two CAN interfaces in a single computer
+connected to the same CAN bus, i.e. we will send messages from can0
+and receive them on can1. These results be used later to determine
+which part of latency is contributed by the PC, which will serve as
+load generator and measure system.
+
+#+begin_ditaa configuration1.png -r
+    CAN bus 0
+ -------*---------*--------
+        ^         |
+        |         v
+    +------+  +------+  +------+  +------+
+ +--+ can0 +--+ can1 +--+ can2 +--+ can3 +--+
+ |  |      |  |      |  |      |  |      |  |
+ |  |      |  |      |  |      |  |      |  |
+ |  +------+  +------+  +------+  +------+  |
+ |                                          |
+ | PC                                       |
+ |                                         |
+ +--------------------------------+---------+
+#+end_ditaa
+
+In the second configuration 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 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 of when the message appeared on the bus.
+
+#+begin_ditaa configuration2.png -r
+                    +-------+
+                    |  GW   |
+                    |MPC5200|
+                    +-------+
+                      ^   |
+      CAN bus 0       |   v  CAN bus 1
+  -------*---------*--*- -*-*---------*-------
+         ^         |        |        |
+         |         v        v        |
+    +------+  +------+  +------+  +---+--+
+ +--+ can0 +--+ can1 +--+ can2 +--+ can3 +--+
+ |  |      |  |      |  |      |  |      |  |
+ |  |      |  |      |  |      |  |      |  |
+ |  +------+  +------+  +------+  +------+  |
+ |                                          |
+ | PC                                       |
+ |                                         |
+ +--------------------------------+---------+
+#+end_ditaa
+
+
+* Measurement software
+
+We intend to develop an application that will run at the PC and will
+be responsible for test traffic generation and measuring of the
+communication latencies. The traffic will be generated on one
+interface and received on the other(s) in the same compoter.
+Therefore, the TX and RX timestamps will be measured by the same clock
+(TSC/HPET) which allows precise measurement latencies.
+
+** Traffic generator
+
+We plan to generate traffic in several possible modes:
+1) 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.
+2) 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.
+3) (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.
+
+The generator will be able to generate different ID/length/data
+patterns similarly as =cangen=.
+
+* Gateway configuration
+
+We plan to test the following gateway configurations (and maybe even
+combinations of these configurations):
+1) Routing of all frames, without modifications
+2) Routing of selected frames only, without modifications
+3) Routing of all/selected frames with modifications
+   - different type of modifications (and/or/xor/set/crc)
+   - different number of modifications per "job"
+4) Routing of either SFF or EFF frames only (there should be
+   difference because of how =can_rcv_filter()= is implemented.
+
+* What we plan to measure
+
+The measured latencies of individual messages will be statistically
+processed and histograms will be generated from the data. Similarly as
+the graphs at http://rtime.felk.cvut.cz/can/benchmark/1/.
+
+[[ethflood.pdf][Example graph]]
+
+* Questions
+1) Are the hardware configurations sufficient for you or are you
+   interested in different setups too?
+2) In case of loosing messages, are you interested in detailed
+   statistics of which packets are lost, etc?
+3) Do you have interests in measuring any other gateway
+   configurations?