An Example: Trace Performance Statistics

It is astonishing that a tool for trace performance statistics could be implemented almost independently of the semantics of the trace data, because the word performance does not suggest this. The tool only has to know which record field contains the time stamp (for SIMPLE tools this is the time record field named ACQUISITION). In our numerous analyses which we performed with SIMPLE, we found that 95%of the values needed for performance statistics can be assigned to one of the following cases:

1. Determine the frequency of certain event records, e.g. for computing the relative frequency or branching probabilities of alternatives in the dynamic program flow.
2. Determine the distance in time between each occurrence of a certain event record, e.g. to compute the inter-arrival time between messages.
3. Determine the duration in time of an interval defined by a start and an end event record. This can be used to compute the transfer time of messages or the duration of procedures.
4. Count the occurrences of certain event records. Here we have to distinguish between event records which increase and decrease the corresponding counter, e.g. computing message queue lengths or the like.
5. Access values stored already in a record field such as message lengths.

When a certain performance value could not be computed with these functions, this was usually due to the fact that the events needed for this computation were not (or only partly) recorded. For the specification of the event records which have to be used for the computations, the modules of the filtering layer can be used. This has the additional advantage that the same syntax for expressions can be used for specifying filter rules and performance statistics commands. With the help of the graphics module of the tool support layer, the computed values should be displayed visually, e.g. as scatter plots, bar graphs or box plots.

The user often needs a short summary only. This could be the number of values, the minimum, maximum, and mean value, the sum, and the variance or standard deviation of the values. All these values can be computed within one run through the event trace. This is a big advantage especially for large event traces. There is even an algorithm which allows an almost exact estimation of the median and other quantiles without storing single values [12].

It would be an useful addition to the command language to not only allow the computation of frequency and time values in total for the whole event trace, but also separately for each value of a particular token record field. This enables the user to display the values e.g. for each process or node, if the appropriate information is stored in the event record.

The ideas presented in this subsection are implemented in the SIMPLE tool trcstat (TRaCe STATistics). As the main topic of this article is object-independence of trace monitoring and analysis systems, we do not describe other tools of SIMPLE here. The curious reader is referred to [19]. Examples can be found in [20] and in the detailed SIMPLE User's Guide [22].