X-Git-Url: http://rtime.felk.cvut.cz/gitweb/can-benchmark.git/blobdiff_plain/b956e1250c768b06becee662df687d7d2f6a8cc1..83652d8bb1c9ba1486909395264e729bb043e26c:/doc/plan.txt

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?