doc/plan.tex

   1 % Created 2010-09-30 Čt 12:40
   2 \documentclass[11pt]{scrartcl}
   3 \usepackage[utf8]{inputenc}
   4 % \usepackage[T1]{fontenc}
   5 \usepackage{fixltx2e}
   6 \usepackage{graphicx}
   7 \usepackage{longtable}
   8 \usepackage{float}
   9 \usepackage{wrapfig}
  10 \usepackage{soul}
  11 % \usepackage{t1enc}
  12 \usepackage{textcomp}
  13 \usepackage{marvosym}
  14 \usepackage{wasysym}
  15 \usepackage{latexsym}
  16 \usepackage{amssymb}
  17 \usepackage{hyperref}
  18 \hypersetup{
  19         breaklinks = true, %allow links to break over lines
  20         pdffitwindow = true, %resize document window to fit document size
  21         colorlinks = true,
  22 %       linkcolor = darkblue,
  23 %       citecolor = darkblue,
  24 %       urlcolor = darkblue,
  25         linkcolor = black,
  26         citecolor = black,
  27         urlcolor = black,
  28         plainpages=false,
  29         }
  30 \providecommand{\alert}[1]{\textbf{#1}}
  31
  32 \title{Planning of SocketCAN gateway evaluation}
  33 \author{M. Sojka, P. Píša, Z. Hanzáelk\\
  34 Czech Technical University in Prague}
  35 \date{September 30, 2010}
  36
  37 \begin{document}
  38
  39 \maketitle
  40
  41 % \setcounter{tocdepth}{1}
  42 % \tableofcontents
  43 % \vspace*{1cm}
  44
  45 % \section{Introduction}
  46 % \label{sec:introduction}
  47
  48 \begin{abstract}
  49   This document specifies how the (mostly) temporal properties of
  50   SocketCAN-based CAN gateway will be evaluated.
  51 \end{abstract}
  52 \section{Hardware setup}
  53 \label{sec-1}
  54
  55
  56 We will use two hardware configurations for our experiments.
  57
  58 \begin{enumerate}
  59 \item A single PC with Kvaser PCI quad-CAN card.
  60 \item A single PC with Kvaser PCI quad-CAN card plus CAN gateway running
  61    on MPC5200 system.
  62 \end{enumerate}
  63
  64
  65 The first HW configuration, depicted in Figure \ref{fig:c1}, will be
  66 used to measure the timing properties of communication between two CAN
  67 interfaces in a single computer (PC) connected to the same CAN bus,
  68 i.e. we will send messages from can0 and receive them on can1. The PC
  69 will serve in further experiments as a load generator and measuring
  70 system. These results be used later to determine which part of latency
  71 is contributed by the PC and not by the measured gateway.
  72
  73
  74
  75 \begin{figure}[h!]
  76   \centering
  77   \includegraphics[scale=.5]{configuration1.png}
  78   \caption{PC-only configuration}
  79 \label{fig:c1}
  80 \end{figure}
  81 In the second HW configuration (Fig. \ref{fig:c2}) messages will be
  82 send from one interface on the PC (can0) and the gateway will route
  83 them to the second bus connected to another interface on the same PC
  84 (can2). Optionally, additional interface (can1) will be connected to
  85 the same bus as can0 and we will use the reception timestamp on this
  86 interface to determine the time when the message appeared on the bus
  87 0.
  88
  89
  90 \begin{figure}[h!]
  91   \centering
  92   \includegraphics[scale=.5]{configuration2.png}
  93   \caption{Configuration with PC and the gateway}
  94 \label{fig:c2}
  95 \end{figure}
  96 \section{Measurement software}
  97 \label{sec-2}
  98
  99 We intend to develop an application that will run on the PC and will
 100 be responsible for test traffic generation and measurement of the
 101 communication latencies. The traffic will be generated on one
 102 interface and received on the other(s) in the same computer.
 103 Therefore, the TX and RX timestamps will be measured by the same clock
 104 (TSC/HPET) which allows precise measurement of the latencies.
 105 \subsection{Traffic generator}
 106 \label{sec-2_1}
 107
 108
 109 We plan to generate traffic in several possible modes:
 110 \begin{enumerate}
 111 \item Send the messages as fast as possible to fully utilize the bus and
 112    to check that gateway/driver does not drop messages. TX queue on
 113    the PC will be almost always full. For that reason the time when
 114    the message is put into the queue will be different from the time
 115    the message appears on the bus. The later time will be determined
 116    by receiving the message on can1.
 117 \item Send the message only after the corresponding message is received
 118    on the second interface. In this case there will be at most one
 119    message in the TX queue and time between sending on can0 and
 120    receiving on can1 should be short.
 121 \item (Optional) Burst sequences, but not continuous bus load. This mode
 122    will be used if the GW does not survive continuous traffic to find
 123    the maximum burst size that can be safely handled.
 124 \end{enumerate}
 125
 126
 127 The generator will be able to generate different ID/length/data
 128 patterns similarly as \texttt{cangen}.
 129 \section{Gateway configuration}
 130 \label{sec-3}
 131
 132 \subsection{Kernel versions}
 133 \label{sec:kernel-versions}
 134 We want to run the gateway with vanilla and rt\_preempt kernels.
 135 Currently we run 2.6.31 kernels on our board but we want to upgrade to
 136 2.6.33 (so far -rt is available only for .33) and run the experiments
 137 on these newer kernel. We do not expect major problems with upgrading.
 138
 139 \subsection{One-way traffic}
 140 \label{sec:one-way-traffic}
 141 We plan to test the following gateway configurations (and maybe even
 142 combinations of these configurations):
 143 \begin{enumerate}
 144 \item Routing of all frames, without modifications
 145 \item Routing of selected frames only, without modifications
 146 \item Routing of all/selected frames with modifications
 147 \begin{itemize}
 148 \item different type of modifications (and/or/xor/set/crc)
 149 \item different number of modifications per ``job''
 150 \end{itemize}
 151
 152 \item Routing of either SFF or ELF frames only (there should be
 153    difference because of how \texttt{can\_rcv\_filter()} is implemented.
 154 \end{enumerate}
 155
 156 \subsection{Bi-directional traffic}
 157 \label{sec:bi-direct-gatew}
 158
 159 It will be interesting to investigate the behavior of the gateway with
 160 bi-directional traffic, i.e. the PC will generate traffic on both can0
 161 and can3. If both busses are fully utilized by the traffic generator,
 162 some messages must definitely be dropped at some point. We expect that
 163 the low priority messages will be dropped and it will be seen whether
 164 this is true in reality.
 165
 166 \section{Presentation of results}
 167 \label{sec-4}
 168 The measured latencies of individual messages will be statistically
 169 processed and histograms (latency profiles) will be generated from the
 170 data. Latency profile (see the example from our previous benchmark in
 171 Figure \ref{fig:lp}) is a sort of reverse-cumulative histogram with
 172 logarithmic vertical axis. The advantage of using latency profiles is
 173 that the worst-case behavior (bottom right part of the graph) is
 174 ``magnified'' by the logarithmic scale.
 175
 176 \begin{figure}
 177   \centering
 178   \includegraphics{ethflood.pdf}
 179   \caption{Latency profile from our previous benchmark}
 180 \label{fig:lp}
 181 \end{figure}
 182 \section{Questions}
 183 \label{sec-5}
 184
 185 \begin{enumerate}
 186 \item Are the hardware configurations sufficient for you or are you
 187   interested in different setups?
 188 \item In the case of lost messages, are you interested in detailed
 189   statistics of which messages are lost, etc?
 190 \item Are you interested in measuring any other gateway
 191   configurations?
 192  \item Are you also interested in what happens when the gateway is
 193    loaded by other activities (CPU, Ethernet, etc.)?
 194 \end{enumerate}
 195
 196 \end{document}