doc: Add plan for socketcan gw testing
[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{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}