From: Michal Sojka Date: Thu, 30 Sep 2010 20:07:10 +0000 (+0200) Subject: doc: Add plan for socketcan gw testing X-Git-Tag: fix-allnoconfig~343 X-Git-Url: http://rtime.felk.cvut.cz/gitweb/can-benchmark.git/commitdiff_plain/83652d8bb1c9ba1486909395264e729bb043e26c?hp=b956e1250c768b06becee662df687d7d2f6a8cc1 doc: Add plan for socketcan gw testing --- diff --git a/doc/configuration1.png b/doc/configuration1.png new file mode 100644 index 0000000..5730237 Binary files /dev/null and b/doc/configuration1.png differ diff --git a/doc/configuration2.png b/doc/configuration2.png new file mode 100644 index 0000000..fb29a48 Binary files /dev/null and b/doc/configuration2.png differ diff --git a/doc/ethflood.pdf b/doc/ethflood.pdf new file mode 100644 index 0000000..4f6d8ee Binary files /dev/null and b/doc/ethflood.pdf differ diff --git a/doc/plan.tex b/doc/plan.tex new file mode 100644 index 0000000..99f7f14 --- /dev/null +++ b/doc/plan.tex @@ -0,0 +1,196 @@ +% Created 2010-09-30 Čt 12:40 +\documentclass[11pt]{scrartcl} +\usepackage[utf8]{inputenc} +% \usepackage[T1]{fontenc} +\usepackage{fixltx2e} +\usepackage{graphicx} +\usepackage{longtable} +\usepackage{float} +\usepackage{wrapfig} +\usepackage{soul} +% \usepackage{t1enc} +\usepackage{textcomp} +\usepackage{marvosym} +\usepackage{wasysym} +\usepackage{latexsym} +\usepackage{amssymb} +\usepackage{hyperref} +\hypersetup{ + breaklinks = true, %allow links to break over lines + pdffitwindow = true, %resize document window to fit document size + colorlinks = true, +% linkcolor = darkblue, +% citecolor = darkblue, +% urlcolor = darkblue, + linkcolor = black, + citecolor = black, + urlcolor = black, + plainpages=false, + } +\providecommand{\alert}[1]{\textbf{#1}} + +\title{Planning of SocketCAN gateway evaluation} +\author{M. Sojka, P. Píša, Z. Hanzáelk\\ +Czech Technical University in Prague} +\date{September 30, 2010} + +\begin{document} + +\maketitle + +% \setcounter{tocdepth}{1} +% \tableofcontents +% \vspace*{1cm} + +% \section{Introduction} +% \label{sec:introduction} + +\begin{abstract} + This document specifies how the (mostly) temporal properties of + SocketCAN-based CAN gateway will be evaluated. +\end{abstract} +\section{Hardware setup} +\label{sec-1} + + +We will use two hardware configurations for our experiments. + +\begin{enumerate} +\item A single PC with Kvaser PCI quad-CAN card. +\item A single PC with Kvaser PCI quad-CAN card plus CAN gateway running + on MPC5200 system. +\end{enumerate} + + +The first HW configuration, depicted in Figure \ref{fig:c1}, will be +used to measure the timing properties of communication between two CAN +interfaces in a single computer (PC) connected to the same CAN bus, +i.e. we will send messages from can0 and receive them on can1. The PC +will serve in further experiments as a load generator and measuring +system. These results be used later to determine which part of latency +is contributed by the PC and not by the measured gateway. + + + +\begin{figure}[h!] + \centering + \includegraphics[scale=.5]{configuration1.png} + \caption{PC-only configuration} +\label{fig:c1} +\end{figure} +In the second HW configuration (Fig. \ref{fig:c2}) messages will be +send from one interface on the PC (can0) and the gateway will route +them to the second bus connected to another interface on the same PC +(can2). Optionally, additional interface (can1) will be connected to +the same bus as can0 and we will use the reception timestamp on this +interface to determine the time when the message appeared on the bus +0. + + +\begin{figure}[h!] + \centering + \includegraphics[scale=.5]{configuration2.png} + \caption{Configuration with PC and the gateway} +\label{fig:c2} +\end{figure} +\section{Measurement software} +\label{sec-2} + +We intend to develop an application that will run on the PC and will +be responsible for test traffic generation and measurement of the +communication latencies. The traffic will be generated on one +interface and received on the other(s) in the same computer. +Therefore, the TX and RX timestamps will be measured by the same clock +(TSC/HPET) which allows precise measurement of the latencies. +\subsection{Traffic generator} +\label{sec-2_1} + + +We plan to generate traffic in several possible modes: +\begin{enumerate} +\item Send the messages as fast as possible to fully utilize the bus and + to check that gateway/driver does not drop messages. TX queue on + the PC will be almost always full. For that reason the time when + the message is put into the queue will be different from the time + the message appears on the bus. The later time will be determined + by receiving the message on can1. +\item Send the message only after the corresponding message is received + on the second interface. In this case there will be at most one + message in the TX queue and time between sending on can0 and + receiving on can1 should be short. +\item (Optional) Burst sequences, but not continuous bus load. This mode + will be used if the GW does not survive continuous traffic to find + the maximum burst size that can be safely handled. +\end{enumerate} + + +The generator will be able to generate different ID/length/data +patterns similarly as \texttt{cangen}. +\section{Gateway configuration} +\label{sec-3} + +\subsection{Kernel versions} +\label{sec:kernel-versions} +We want to run the gateway with vanilla and rt\_preempt kernels. +Currently we run 2.6.31 kernels on our board but we want to upgrade to +2.6.33 (so far -rt is available only for .33) and run the experiments +on these newer kernel. We do not expect major problems with upgrading. + +\subsection{One-way traffic} +\label{sec:one-way-traffic} +We plan to test the following gateway configurations (and maybe even +combinations of these configurations): +\begin{enumerate} +\item Routing of all frames, without modifications +\item Routing of selected frames only, without modifications +\item Routing of all/selected frames with modifications +\begin{itemize} +\item different type of modifications (and/or/xor/set/crc) +\item different number of modifications per ``job'' +\end{itemize} + +\item Routing of either SFF or ELF frames only (there should be + difference because of how \texttt{can\_rcv\_filter()} is implemented. +\end{enumerate} + +\subsection{Bi-directional traffic} +\label{sec:bi-direct-gatew} + +It will be interesting to investigate the behavior of the gateway with +bi-directional traffic, i.e. the PC will generate traffic on both can0 +and can3. If both busses are fully utilized by the traffic generator, +some messages must definitely be dropped at some point. We expect that +the low priority messages will be dropped and it will be seen whether +this is true in reality. + +\section{Presentation of results} +\label{sec-4} +The measured latencies of individual messages will be statistically +processed and histograms (latency profiles) will be generated from the +data. Latency profile (see the example from our previous benchmark in +Figure \ref{fig:lp}) is a sort of reverse-cumulative histogram with +logarithmic vertical axis. The advantage of using latency profiles is +that the worst-case behavior (bottom right part of the graph) is +``magnified'' by the logarithmic scale. + +\begin{figure} + \centering + \includegraphics{ethflood.pdf} + \caption{Latency profile from our previous benchmark} +\label{fig:lp} +\end{figure} +\section{Questions} +\label{sec-5} + +\begin{enumerate} +\item Are the hardware configurations sufficient for you or are you + interested in different setups? +\item In the case of lost messages, are you interested in detailed + statistics of which messages are lost, etc? +\item Are you interested in measuring any other gateway + configurations? + \item Are you also interested in what happens when the gateway is + loaded by other activities (CPU, Ethernet, etc.)? +\end{enumerate} + +\end{document} diff --git a/doc/plan.txt b/doc/plan.txt new file mode 100644 index 0000000..4b0453e --- /dev/null +++ b/doc/plan.txt @@ -0,0 +1,119 @@ +#+TITLE: Plan of SocketCAN GW tests + +* Hardware setup + +We will use two hardware configurations for our experiments. + +1) A single PC with Kvaser PCI quad-CAN card. + +2) A single PC with Kvaser PCI quad-CAN card plus CAN gateway running + on MPC5200 system. + +The first configuration will be used to measure the timing properties +of communication between two CAN interfaces in a single computer +connected to the same CAN bus, i.e. we will send messages from can0 +and receive them on can1. These results be used later to determine +which part of latency is contributed by the PC, which will serve as +load generator and measure system. + +#+begin_ditaa configuration1.png -r + CAN bus 0 + -------*---------*-------- + ^ | + | v + +------+ +------+ +------+ +------+ + +--+ can0 +--+ can1 +--+ can2 +--+ can3 +--+ + | | | | | | | | | | + | | | | | | | | | | + | +------+ +------+ +------+ +------+ | + | | + | PC | + | | + +--------------------------------+---------+ +#+end_ditaa + +In the second configuration messages will be send from one interface +on the PC (can0) and the gateway will route them to the second bus +connected to another interface on the PC (can2). Optionally, +additional interface (can1) will be connected to the same bus as can0 +and we will use the reception timestamp on this interface to determine +the time of when the message appeared on the bus. + +#+begin_ditaa configuration2.png -r + +-------+ + | GW | + |MPC5200| + +-------+ + ^ | + CAN bus 0 | v CAN bus 1 + -------*---------*--*- -*-*---------*------- + ^ | | | + | v v | + +------+ +------+ +------+ +---+--+ + +--+ can0 +--+ can1 +--+ can2 +--+ can3 +--+ + | | | | | | | | | | + | | | | | | | | | | + | +------+ +------+ +------+ +------+ | + | | + | PC | + | | + +--------------------------------+---------+ +#+end_ditaa + + +* Measurement software + +We intend to develop an application that will run at the PC and will +be responsible for test traffic generation and measuring of the +communication latencies. The traffic will be generated on one +interface and received on the other(s) in the same compoter. +Therefore, the TX and RX timestamps will be measured by the same clock +(TSC/HPET) which allows precise measurement latencies. + +** Traffic generator + +We plan to generate traffic in several possible modes: +1) Send the messages as fast as possible to fully utilize the bus and + to check that gateway/driver does not drop messages. TX queue on + the PC will be almost always full. For that reason the time when + the message is put into the queue will be different from the time + the message appears on the bus. The later time will be determined + by receiving the message on can1. +2) Send the message only after the corresponding message is received + on the second interface. In this case there will be at most one + message in the TX queue and time between sending on can0 and + receiving on can1 should be short. +3) (Optional) Burst sequences, but not continuous bus load. This mode + will be used if the GW does not survive continuous traffic to find + the maximum burst size that can be safely handled. + +The generator will be able to generate different ID/length/data +patterns similarly as =cangen=. + +* Gateway configuration + +We plan to test the following gateway configurations (and maybe even +combinations of these configurations): +1) Routing of all frames, without modifications +2) Routing of selected frames only, without modifications +3) Routing of all/selected frames with modifications + - different type of modifications (and/or/xor/set/crc) + - different number of modifications per "job" +4) Routing of either SFF or EFF frames only (there should be + difference because of how =can_rcv_filter()= is implemented. + +* What we plan to measure + +The measured latencies of individual messages will be statistically +processed and histograms will be generated from the data. Similarly as +the graphs at http://rtime.felk.cvut.cz/can/benchmark/1/. + +[[ethflood.pdf][Example graph]] + +* Questions +1) Are the hardware configurations sufficient for you or are you + interested in different setups too? +2) In case of loosing messages, are you interested in detailed + statistics of which packets are lost, etc? +3) Do you have interests in measuring any other gateway + configurations?