--- /dev/null
+#+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?
projects / can-benchmark.git / blobdiff