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{Version 1.1\\October 27, 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 \subsection{PC-only configuration}
  65 \label{sec:pc-only-conf}
  66
  67
  68 The first HW configuration, depicted in Figure \ref{fig:c1}, will be
  69 used to measure the timing properties of communication between two CAN
  70 interfaces in a single computer (PC) connected to the same CAN bus,
  71 i.e. we will send messages from can0 and receive them on can1. The PC
  72 will serve in further experiments as a load generator and measuring
  73 system. These results be used later to determine which part of latency
  74 is contributed by the PC and not by the measured gateway.
  75
  76
  77
  78 \begin{figure}[h!]
  79   \centering
  80   \includegraphics[scale=.5]{configuration1.png}
  81   \caption{PC-only configuration.}
  82 \label{fig:c1}
  83 \end{figure}
  84
  85 \subsection{PC and gateway in MPC5200}
  86 \label{sec:pc-gateway-mpc5200}
  87
  88 In the second HW configuration (Fig. \ref{fig:c2}) messages will be
  89 send from one interface on the PC (can0) and the gateway will route
  90 them to the second bus connected to another interface on the same PC
  91 (can2). Optionally, additional interface (can1) will be connected to
  92 the same bus as can0 and we will use the reception timestamp on this
  93 interface to determine the time when the message appeared on the bus
  94 0.
  95
  96
  97 \begin{figure}[h!]
  98   \centering
  99   \includegraphics[scale=.5]{configuration2.png}
 100   \caption{Configuration with PC and the gateway.}
 101 \label{fig:c2}
 102 \end{figure}
 103
 104 Gateway will be connected via a dedicated Ethernet network to the PC
 105 which will contain root filesystem mounted by gateway via NFS.
 106
 107 \section{Measurement software}
 108 \label{sec-2}
 109
 110 We intend to develop an application that will run on the PC and will
 111 be responsible for test traffic generation and measurement of the
 112 communication latencies. The traffic will be generated on one
 113 interface and received on the other(s) in the same computer.
 114 Therefore, the TX and RX timestamps will be measured by the same clock
 115 (TSC/HPET) which allows precise measurement of the latencies.
 116 \subsection{Traffic generator}
 117 \label{sec-2_1}
 118
 119 We plan to generate traffic in several possible modes:
 120 \begin{enumerate}
 121 \item Send the messages as fast as possible to fully utilize the bus and
 122    to check that gateway/driver does not drop messages. TX queue on
 123    the PC will be almost always full. For that reason the time when
 124    the message is put into the queue will be different from the time
 125    the message appears on the bus. The later time will be determined
 126    by receiving the message on can1 (see Fig. \ref{fig:c2}).
 127 \item Send the message only after the corresponding message is received
 128    on the second interface. In this case there will be at most one
 129    message in the TX queue and time between sending on can0 and
 130    receiving on can1 should be short.
 131 \item (Optional) Burst sequences, but not continuous bus load. This mode
 132    will be used if the GW does not survive continuous traffic to find
 133    the maximum burst size that can be safely handled.
 134 \end{enumerate}
 135
 136
 137 The generator will be able to generate different ID/length/data
 138 patterns similarly as \texttt{cangen}.
 139 \section{Gateway configuration}
 140 \label{sec-3}
 141
 142 \subsection{Kernel versions}
 143 \label{sec:kernel-versions}
 144 We will run the gateway with vanilla and rt\_preempt kernels (2.6.33.7
 145 and 2.6.33.7-rt29). Not that rt\_preempt patch is not available for a
 146 more recent kernel version as of this writing.
 147
 148 \subsection{One-way traffic}
 149 \label{sec:one-way-traffic}
 150 In this test we will use a single kernel gateway as depicted in Figure
 151 \ref{fig:gw-single}. We plan to test the following gateway
 152 configurations (and maybe even combinations of these configurations):
 153 \begin{enumerate}
 154 \item Routing of all frames, without modifications
 155 \item Routing of selected frames only, without modifications
 156 \item Routing of all/selected frames with modifications
 157 \begin{itemize}
 158 \item different type of modifications (and/or/xor/set/crc)
 159 \item different number of modifications per ``job''
 160 \end{itemize}
 161
 162 \item Routing of either SFF or EFF frames only (there should be
 163    difference because of how \texttt{can\_rcv\_filter()} is implemented.
 164 \end{enumerate}
 165
 166 \begin{figure}[h!]
 167   \centering
 168   \includegraphics[scale=.5]{gw-signle}
 169   \caption{Simple gateway configuration.}
 170   \label{fig:gw-single}
 171 \end{figure}
 172
 173
 174 \subsection{Bi-directional traffic}
 175 \label{sec:bi-direct-gatew}
 176
 177 It will be interesting to investigate the behavior of the gateway with
 178 bi-directional traffic, i.e. the PC will generate traffic on both can0
 179 and can3. If both busses are fully utilized by the traffic generator,
 180 some messages must definitely be dropped at some point. We expect that
 181 the low priority messages will be dropped and it will be seen whether
 182 this is true in reality.
 183
 184 \subsection{Multiple gateways}
 185 \label{sec:multiple-gateways}
 186
 187 We will also test properties of multiple gateways. In the first case
 188 (Figure \ref{fig:multi}) there will be multiple (variable number)
 189 gateways interconnected by multiple virtual CAN busses. In the second
 190 case (Figure \ref{fig:multi2}), a single virtual bus will be used and
 191 multiple gateways will route the messages. The gateways will also
 192 modify the frames to avoid CAN-ID clashes on vcan0.
 193
 194
 195 \begin{figure}
 196   \centering
 197   \includegraphics[scale=.8]{gw-multi}
 198   \caption{Multiple gateways with multiple virtual CAN buses.}
 199   \label{fig:multi}
 200 \end{figure}
 201
 202 \begin{figure}
 203   \centering
 204   \includegraphics[scale=.8]{gw-multi-mod}
 205   \caption{Multiple gateways with a single virtual CAN bus.}
 206   \label{fig:multi2}
 207 \end{figure}
 208
 209 \subsection{Userspace gateway}
 210 \label{sec:userspace-gateway}
 211
 212 We will also compare kernel-based gateway (considered above) with the
 213 usespace gateway created by \texttt{candump -s2 -b can1 can0}.
 214
 215 \subsection{Gateway load}
 216 \label{sec:gateway-load}
 217
 218 The experiments will be repeated for each of the following loads
 219 imposed on MPC5200:
 220 \begin{itemize}
 221 \item No load,
 222 \item CPU load,
 223 \item Ethernet load.
 224 \end{itemize}
 225
 226
 227 \section{Presentation of results}
 228 \label{sec-4}
 229 The measured latencies of individual messages will be statistically
 230 processed and histograms (latency profiles) will be generated from the
 231 data. Latency profile (see the example from our previous benchmark in
 232 Figure \ref{fig:lp}) is a sort of reverse-cumulative histogram with
 233 logarithmic vertical axis. The advantage of using latency profiles is
 234 that the worst-case behavior (bottom right part of the graph) is
 235 ``magnified'' by the logarithmic scale.
 236
 237 \begin{figure}
 238   \centering
 239   \includegraphics{ethflood.pdf}
 240   \caption{Latency profile from our previous benchmark.}
 241 \label{fig:lp}
 242 \end{figure}
 243
 244 \end{document}