1. The user satisfaction

The result of a run can be qualified along several dimensions. For instance, the result of a simulation may be more or less precise and the run may take more or less time. There is no absolute way to decide what is better from the user's point of view.  A user may prefer a fast and broad simulation in tunning stage, and a long and precise one in final stage. The framework must provide a way to handle the user's preferences.

The result of a run is qualified by a set of qualities Q.Each quality (qi)i has a value inside its definition domain. For each vector q, the user provides a level of satisfaction, a real value between 0 and 1. The improving system will try continuously to find actions that maximizes this level of satisfaction.

The goal of the system is thus to choose the sequence (TODO : evolution ?) of configurations the leads  to the best user's satisfaction.[TODO : trans] Choice elements being not perfectly known at implementation time, there is a difference between the model of what is supposed to be and what really happens. Let us assume that the uncertainty can be modeled as a probability. This is an example of modelization, but it will be used widely because of its expressivity and generality.

 In large scale application, the event of failure must e taken into account due to its relative frequency of occurrence. This event may occur at anytime and must be modeled to handle the uncertainty. A probabilistic modem is often used to manage fault tolerance : for each CPU, a probability that a failure occurs between T and T+?T is given. Fault tolerance being a major part of large scale (multi-agent) systems, the probabilistic component of the MAS will be handled throw the particular case of fault tolerance. Let us keep in mind that it is an example.

 The fact that the quality is probabilised increases the complexity of satisfying the user "as best as possible". Indeed, a higher quality (think about run duration) implies ahigh probability of fault. This is not acceptable due to the large amount of involved CPU and the lack of redundancy that could lower the impact of a failure. The user, who must previously weight the dimensions of the quality, must now make a choice about the probability of this quality. He may prefer a low process with a high probability of succes, or a quick run without protection against failure. To a first approximation, the user does not want a quality at a given probability ; he wants at least this quality, with at least this probability.

Let us given an example to explain.

We suppose that we have two processes P1 and P2 that run independently (far for MAS, but it is only of demonstration purpose). The hardware is compound by two CPUs C1 and C2. Each CPU is able to process 4032 instructions per second. They dispatch fairly their resources among processes they are in charge of. Each CPU is already in charge of 62 processes ; each of them is computed at the same number of instructions per second. Each CPU as a probability eps to fail each second ; a single failure of each CPU is assumed. In this case, all the computation must restart.

Let the quality q be the number of instructions per second with which P1 and P2 are processed. Let N be the number of instructions to process to achieve the computation.

Configuration 1 : P1 on C1 and P2 on C2, no fault tolerance.

Each CPU executes 63 processes, at 4032 / 63 = 64 ips.

P ( no fault ) = 1 - eps * N / 64 : 64 ips

P ( fault ) = eps * N / 64 : 48 ips on average (64 ips if the fault occurs at the begining, 32 ips if it occurs at the end).

Configuration 2 : P1 on C1 and P2 on C2, fault tolerance by P1' on C2 and P2' on C1.

Each CPU executes 6 processes, at  4032 / 64 = 63 ips.

P ( no fault ) = 1 - eps * N / 63 : 63 ips

P ( fault ) = eps * N / 63 : 63 ips on average (a fault does not change anything).

There is no best choice ; it depends on the behavior against risk.

- Risk-neutral = on average :

E ( Q1 ) = 64 ( 1 - eps * N / 64 ) + 48 * eps * N / 64 = 64 - 16 * eps * N / 64 = 64 - eps * N / 4

E ( Q2 ) = 63

64 - eps * N / 4 > 63

<=> eps * N < 4

On average,  C1 (64 - eps * N / 4 ips) is better thant C2 (63 ips) iff eps * N < 4

- Risk-seeking = optimistic = best case only :

When no fault occurs, C1 (64 ips) is better thant C2 (63 ips)

- Risky-averse = pessimistic = worst case only :

When no fault occurs, C1 (48 ips) is worst thant C2 (63 ips)

Configuration comparison

There is no best configuration :

 TODO : criticity = gravity * frequency

TODO : criticity = gravity * frequency * detection