Generate thumbnails with appripriate gamma value
[can-benchmark.git] / 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}