• No results found

7.2 Case study I: sorting application

7.2.2 Execution time measurements

In this experiment, the execution times of the configurations described in the previous section were measured. A total execution time is defined as the time interval between sending a message with “unsorted” subject (by the Producer thread) and receiving the message with “sorted” subject (at the Consumer thread). A local

execution time is defined as the time interval between receiving a message with

“unsorted” subject (at a Sorter thread) and sending the message with “sorted” subject (by a Sorter or Voter thread). Consequently, local execution times exclude any communication overhead between the notebook computer and the PowerPC boards.

The execution times for several configurations and failure conditions are shown in Table 7.1 and Table 7.2. Table 7.1 presents local execution times, while Table 7.2 presents total execution times. The results shown in these tables consist of an average of 10 executions. Table 7.3 presents the time settings used in this case study for the several configurations, as they have effect in some measured execution times.

Table 7.1: Case study I - local execution time.

Failure conditions Configuration No failure Failure in variant 1 Failure in one node Failure in two nodes Insertion sort 1743 - - - Selection sort 3511 3511 - - Bubble sort 3123 3123 - - RB 4250 8249 - - DRB 4781 8701 20375 - NVP 9444 12716 10792 24175

Table 7.2: Case study I - total execution time. Failure conditions Configuration No failure Failure in variant 1 Failure in one node Failure in two nodes Insertion sort 9704 - - - Selection sort 12495 12495 - - Bubble sort 10918 10918 - - RB 12353 17105 - - DRB 12690 17339 27932 - NVP 18815 21345 19907 32504

Table 7.3: Case study I - time settings.

Setting Value (microseconds)

Clock tick interval 2,000

RB maximum response time 10,000 DRB maximum response time 20,000 NVP maximum response time 6,000 Voter maximum response time 20,000

For each configuration, four failure conditions were applied. The first one was a condition with no failures in any variant or node. The Insertion Sort algorithm presents the shortest execution time, and therefore it was selected to run as variant 1 (primary block in RB/DRB). As seen in these tables, the FT configurations have longer executions times because of the coordination with the MiddlewareScheduler thread, as described in Chapter 5. The clock tick interval definition, set in this case study to 2,000 microseconds, affects the execution time of all FT strategies. This setting also affects the communication times between nodes, as the distribution of external incoming messages to threads are performed with a period of two clock ticks (4,000 microseconds). In special, the NVP configuration is supposed to be the slowest, as additional time for results dissemination and voting is needed. Consequently, the maximum response time in a NVP configuration is bound to the sum of the maximum response time of NVP and Voter threads.

Figure 7.5 presents a graphical comparison of the several configurations for the no-failure condition. The left part of the graph is related to local execution times while the right part of the graph is related to total execution times. The lines above the bars represent the standard deviation in 10 measurements. Configurations that depend on message communications present the largest standard deviations.

Figure 7.5: Case study I - no-failure condition.

The second failure condition presented in Table 7.1 and Table 7.2 is related to the failure of variant 1. An error was simulated by introducing an out of order integer to the results of the Insertion Sort algorithm. The error is detected by the acceptance tests of the RB/DRB strategies, which triggers the execution of variant 2 (Selection Sort). This error is masked by the voting mechanism in NVP, as variants 2 and 3 generate identical results. Figure 7.6 shows a comparison of local execution times between the no-failure condition and the variant 1 failure condition. The extra time spent by RB/DRB configurations is due to the execution of the second variant, while the longer execution time for NVP is explained by the fact that local execution times are measured in the node that runs variant 1, and therefore the voting decision was taken only after receiving the results of the other two nodes.

Figure 7.6: Case study I – comparison between no-failure and variant 1 failure conditions.

The third failure condition presented in Table 7.1 and Table 7.2 is related to a silent failure of a node. In that case, non-FT configurations fail as well single node FT configurations as RB. This failure was simulated by switching off the first node (the one running variant 1). Before turning it off, this node is acting as a primary node in the DRB configuration. Measurements of local execution times were taken in the second node (running variant 2).

A comparison of local execution times between the no-failure condition and the one node failure condition is shown in Figure 7.7. The NVP execution time is not affected much, as the voter in the second node will get to a decision after receiving a message from the local NVP thread and the external message from the NVP thread of the third node. However, for the DRB configuration, the failure of the primary node has to be detected by the shadow node and consequently the DRB maximum response time of 20,000 microseconds is taken into account (see Table 7.3). This larger execution time for the DRB configuration only applies for the first activation after a primary node failure because the shadow node will change its role to primary and the execution time will drop to the same value of the no-failure condition. The RB configuration does not survive to a node failure and consequently its execution time is not represented in Figure 7.7 for this condition.

Figure 7.7: Case study I - comparison between no-failure and one node failure conditions.

Finally, the last failure condition presented in Table 7.1 and Table 7.2 is related to the silent failure of two nodes. If that situation occurs, only the NVP configuration succeeds. In that case, the NVP execution time depends on the deadline for voting, which is determined by the maximum response time of the Voter thread (see Table 7.3).