]> rtime.felk.cvut.cz Git - can-benchmark.git/blob - doc/plan.txt
run.pl redirects stdout rather than stderr in order to not loose error messages
[can-benchmark.git] / doc / plan.txt
1 #+TITLE: Plan of SocketCAN GW tests
2
3 * Hardware setup
4
5 We will use two hardware configurations for our experiments.
6
7 1) A single PC with Kvaser PCI quad-CAN card.
8
9 2) A single PC with Kvaser PCI quad-CAN card plus CAN gateway running
10    on MPC5200 system.
11
12 The first configuration will be used to measure the timing properties
13 of communication between two CAN interfaces in a single computer
14 connected to the same CAN bus, i.e. we will send messages from can0
15 and receive them on can1. These results be used later to determine
16 which part of latency is contributed by the PC, which will serve as
17 load generator and measure system.
18
19 #+begin_ditaa configuration1.png -r
20     CAN bus 0
21  -------*---------*--------
22         ^         |
23         |         v
24     +------+  +------+  +------+  +------+
25  +--+ can0 +--+ can1 +--+ can2 +--+ can3 +--+
26  |  |      |  |      |  |      |  |      |  |
27  |  |      |  |      |  |      |  |      |  |
28  |  +------+  +------+  +------+  +------+  |
29  |                                          |
30  | PC                                       |
31  |                                          |
32  +--------------------------------+---------+
33 #+end_ditaa
34
35 In the second configuration messages will be send from one interface
36 on the PC (can0) and the gateway will route them to the second bus
37 connected to another interface on the PC (can2). Optionally,
38 additional interface (can1) will be connected to the same bus as can0
39 and we will use the reception timestamp on this interface to determine
40 the time of when the message appeared on the bus.
41
42 #+begin_ditaa configuration2.png -r
43                     +-------+
44                     |  GW   |
45                     |MPC5200|
46                     +-------+
47                       ^   |
48       CAN bus 0       |   v  CAN bus 1
49   -------*---------*--*- -*-*---------*-------
50          ^         |        |         |
51          |         v        v         |
52     +------+  +------+  +------+  +---+--+
53  +--+ can0 +--+ can1 +--+ can2 +--+ can3 +--+
54  |  |      |  |      |  |      |  |      |  |
55  |  |      |  |      |  |      |  |      |  |
56  |  +------+  +------+  +------+  +------+  |
57  |                                          |
58  | PC                                       |
59  |                                          |
60  +--------------------------------+---------+
61 #+end_ditaa
62
63
64 * Measurement software
65
66 We intend to develop an application that will run at the PC and will
67 be responsible for test traffic generation and measuring of the
68 communication latencies. The traffic will be generated on one
69 interface and received on the other(s) in the same compoter.
70 Therefore, the TX and RX timestamps will be measured by the same clock
71 (TSC/HPET) which allows precise measurement latencies.
72
73 ** Traffic generator
74
75 We plan to generate traffic in several possible modes:
76 1) Send the messages as fast as possible to fully utilize the bus and
77    to check that gateway/driver does not drop messages. TX queue on
78    the PC will be almost always full. For that reason the time when
79    the message is put into the queue will be different from the time
80    the message appears on the bus. The later time will be determined
81    by receiving the message on can1.
82 2) Send the message only after the corresponding message is received
83    on the second interface. In this case there will be at most one
84    message in the TX queue and time between sending on can0 and
85    receiving on can1 should be short.
86 3) (Optional) Burst sequences, but not continuous bus load. This mode
87    will be used if the GW does not survive continuous traffic to find
88    the maximum burst size that can be safely handled.
89
90 The generator will be able to generate different ID/length/data
91 patterns similarly as =cangen=.
92
93 * Gateway configuration
94
95 We plan to test the following gateway configurations (and maybe even
96 combinations of these configurations):
97 1) Routing of all frames, without modifications
98 2) Routing of selected frames only, without modifications
99 3) Routing of all/selected frames with modifications
100    - different type of modifications (and/or/xor/set/crc)
101    - different number of modifications per "job"
102 4) Routing of either SFF or EFF frames only (there should be
103    difference because of how =can_rcv_filter()= is implemented.
104
105 * What we plan to measure
106
107 The measured latencies of individual messages will be statistically
108 processed and histograms will be generated from the data. Similarly as
109 the graphs at http://rtime.felk.cvut.cz/can/benchmark/1/.
110
111 [[ethflood.pdf][Example graph]]
112
113 * Questions
114 1) Are the hardware configurations sufficient for you or are you
115    interested in different setups too?
116 2) In case of loosing messages, are you interested in detailed
117    statistics of which packets are lost, etc?
118 3) Do you have interests in measuring any other gateway
119    configurations?