5.1. Test Conditions

The tests in this report were conducted under the following conditions:

1. The target machine is always rebooted between each test sequence.

2. In order to try not to artificially load the target machine the test sequence should only occur once or twice every second and not continuously as fast as possible.

3. The user-space applications that are under investigation form part of the critical path; it is the latency of the critical path that this project records. The critical path includes the driver for the serial device under investigation, the latency-client, and the drones which are spawned from this latency-client (if any). All elements along the critical path have their niceness value set to maximum priority (-20, which is probably irrelevant). The drone applications (if any) form a chain; each drone copies data from one FIFO to another FIFO. The real-time SCHED_FIFO priority for the first process is set to 98 (chrt -pf 98 pid), the next one in the chain has a priority of 97, and so forth. Elements which are not in the critical path do not have their niceness levels or real-time priorities adjusted in any way. If the actual application follows the format of this test investigation, any latencies recorded in the final product above what this test reveals will be a function only of the application logic itself and not of Linux or its mechanisms.

4. The process responsible for handling the serial interrupt has been raised to the highest priority, 99.

5. The target boards being tested were on a network connected to the host by a switch that was isolated from the rest of the network and therefore only contained traffic between the host and the target.