1 % Created 2010-09-30 Čt 12:40
2 \documentclass[11pt]{scrartcl}
3 \usepackage[utf8]{inputenc}
4 % \usepackage[T1]{fontenc}
19 breaklinks = true, %allow links to break over lines
20 pdffitwindow = true, %resize document window to fit document size
22 % linkcolor = darkblue,
23 % citecolor = darkblue,
24 % urlcolor = darkblue,
30 \providecommand{\alert}[1]{\textbf{#1}}
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}
41 % \setcounter{tocdepth}{1}
45 % \section{Introduction}
46 % \label{sec:introduction}
49 This document specifies how the (mostly) temporal properties of
50 SocketCAN-based CAN gateway will be evaluated.
52 \section{Hardware setup}
56 We will use two hardware configurations for our experiments.
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
64 \subsection{PC-only configuration}
65 \label{sec:pc-only-conf}
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.
80 \includegraphics[scale=.5]{configuration1.png}
81 \caption{PC-only configuration.}
85 \subsection{PC and gateway in MPC5200}
86 \label{sec:pc-gateway-mpc5200}
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
99 \includegraphics[scale=.5]{configuration2.png}
100 \caption{Configuration with PC and the gateway.}
104 Gateway will be connected via a dedicated Ethernet network to the PC
105 which will contain root filesystem mounted by gateway via NFS.
107 \section{Measurement software}
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}
119 We plan to generate traffic in several possible modes:
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.
137 The generator will be able to generate different ID/length/data
138 patterns similarly as \texttt{cangen}.
139 \section{Gateway configuration}
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.
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):
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
158 \item different type of modifications (and/or/xor/set/crc)
159 \item different number of modifications per ``job''
162 \item Routing of either SFF or EFF frames only (there should be
163 difference because of how \texttt{can\_rcv\_filter()} is implemented.
168 \includegraphics[scale=.5]{gw-signle}
169 \caption{Simple gateway configuration.}
170 \label{fig:gw-single}
174 \subsection{Bi-directional traffic}
175 \label{sec:bi-direct-gatew}
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.
184 \subsection{Multiple gateways}
185 \label{sec:multiple-gateways}
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.
197 \includegraphics[scale=.8]{gw-multi}
198 \caption{Multiple gateways with multiple virtual CAN buses.}
204 \includegraphics[scale=.8]{gw-multi-mod}
205 \caption{Multiple gateways with a single virtual CAN bus.}
209 \subsection{Userspace gateway}
210 \label{sec:userspace-gateway}
212 We will also compare kernel-based gateway (considered above) with the
213 usespace gateway created by \texttt{candump -s2 -b can1 can0}.
215 \subsection{Gateway load}
216 \label{sec:gateway-load}
218 The experiments will be repeated for each of the following loads
227 \section{Presentation of results}
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.
239 \includegraphics{ethflood.pdf}
240 \caption{Latency profile from our previous benchmark.}