This paper makes a number of assumptions. Some of these regard knowledge or skills we expect you to have (ie, we won't cover those topics here). Other assumptions regard session environment configuration. These assumptions are sketched in the list below.
We assume you have access to the Tornado facilities and other equipment necessary for the collection of performance data into a WindView trace file. We assume you can operate Tornado to collect performance data into a WindView trace file. By convention, WindView trace files are distinguished by the wvr file extension. The RAPID RMA distribution contains some samples in the examples subdirectory.
For use in the RAPID RMA import, the Windview trace data should be collected at the "Additional Instrumentation Level" (AIL) and should include the default set of instrumented objects: tasks (taskLib), semaphores (SemLib), message queues (msgQLib), and watchdog timers (wdLib).
Import of WindView files in RAPID RMA relies on Wind River libraries to parse the WindView trace file. You must have Tornado and WindView installed so as to be available to the host where you run RAPID RMA. The environment must be setup so these libraries can be found, otherwise the import process will fail.
In Windows, we rely on the environment to allow the libraries to be found. If the environment is not setup at boot or login time, this may entail starting a DOS command prompt window so you can set the environment and run RAPID RMA in that environment. Specifically, you run the torVars.bat file in the host/%WIND_HOST_TYPE%/bin subdirectory of the Tornado installation in order to set the environment. Then run rma.bat in the RAPID RMA directory to start RAPID RMA.
In Unix, there are similar environment issues. An installation shell script, rma-systemsetup.sh, will create the application start shell script rma with the information about the Tornado installation path so that the RAPID RMA application will run with the appropriate environment. This requires the person who installs RAPID RMA provide the appropriate Tornado path information when RAPID RMA is installed.
In addition, Tornado 1 and Tornado 2 use different TCL libraries. So the import code is linked to a libtcl.so library and a symbolic link to the actual library must be created. The installation shell script, rma-systemsetup.sh, should set this up when provided with the appropriate information.
Starting an import is easy, as shown in Figure 02-A. From the menubar, get the File pulldown menu, follow the Import cascading menu, and select WindView. A file chooser dialog box appears where you can browse the filesystem and select a WindView file to import.
 |
On selecting the file to use, RAPID RMA will work away (duration proportional to filesize), identifying tasks, resources, and events. Eventually it presents a table that called the "selection spreadsheet" (Figure 03-A). There are a number of choices you can make here that affect what is included in the model and how task periods are determined. Click "OK" to continue.
Next RAPID RMA displays a set of histograms (Figure 04-A), one pair for each of the included tasks (for which period data was found). One histogram of the pair shows the distribution of the period duration and the other shows the distribution of the amount of work performed in a period. Outlying datapoints can be discarded, or specific distribution types can be specified. Click "OK" to continue.
Finally the system creates the candidate model and displays the components in the resource and task views. Optionally, you may decide to further edit the model at this time, using the resource and task editors. Now the model can be analyzed.
The selection spreadsheet consists of two parts. On the left side is a list of tasks and resources. You can select which tasks and resources are included in the model by using the checkbox on the left. A checkmark in the checkbox means the item is included. By default, all items are included.
 |
The right side is a list of tasks and their events, with one task-event pair per row. Often these events involve some action on a resource, for example, semaphore take, semaphore give, message queue send, or message queue receive. The "Event Type" column contains a pulldown menu in every cell. The options here are
Use the default interpretation for this event type. Most events are of the type "Ignore" or "Trigger"
TriggerSpecify that this event serves to demarcate a period. That is, the event serves as boundary between two periods.
IgnoreSpecify that this event does not demarcate a period.
Async (Asynchronous) and Sync (Synchronous)The Asynch and Synch attribute can be applied to message operations that can be treated as asynchronous (non-blocking) or synchronous (blocking) invocations by a task. The default is Asynch; that is, message operations are defaulted to non-blocking operations. Asynch operations are similar to triggers while Synch operations extend the execution time for the calling task.
Shared Res (Shared Resource)[Future Feature] Indicates a resource is a shared resource.
The default event types for some common events are shown in Figure 03-B.
Through this "Event Type" selection, one identifies an appropriate periodic event for each task so that the event serves as the demarcation point between two periods. Given such an event, the import process may compute the length of the period (the duration between successive occurrences) and the workload for the period (the amount of work done between successive occurrences). In addition, resource usage is tracked in terms of intervals relative to the beginning of a period and that information will be added to the model, too. Without some event serving as a trigger, the task parameters cannot be derived. We must find at least one period (two successive period demarcation points) to create the task in the model.
OBSERVATION: These displays are not currently shown as histograms, but as "density functions." The intent is to change to histograms in a later release. For the interim, we will treat then as histograms.
The histograms window displays a pair of histograms for each task. The tasks are itemized on tabs at the top of the canvas. For each task is shown a histogram for the period length (duration) and a histogram for the amount of work. Almost certainly there is some amount of jitter in actual data, so that there isn't a single value where all the observations occur. Usually the only time we find a single value is where the data includes only a single period.
 |
Along the left side of the window are enumerations of the numerical data. These have checkboxes associated with them. At the start all the checkboxes are shown as checked. It may be appropriate to eliminate some outlying. Click on the checkbox to remove the checkmark and eliminate that value (no matter how many observations that value had). If it is already removed, click on the checkbox to reinstate the checkmark and include the value in the distribution.
Along the top are several textboxes showing the distribution statistics.
Shows the minimum value required for including values in the distribution calculation. For example, setting this value to 2 means that values are included only if there are two or more observations with that value. Doing so, you will see that the boxes associated with values having only one count all become unchecked. The default is one.
MinimumShows the minimum included observation.
MaximumShows the maximum included observation.
AverageShows the average of the included observations.
DistributionShows the type of distribution that will be associated with the task or amount of work.
For tasks, this indicates the task will be regarded as periodic with a period equal to the average.
For amount of workload, the task will have a fixed amount of work on every execution and that amount is equal to the average.
UniformFor tasks, this indicates the task will be an periodic or sporadic task whose arrival times are uniformly distributed over the interval given by the minimum and the maximum.
For amount of work, this indicates the task will perform a variable amount of work on each execution, and the amount of work is uniformly distributed over the interval given by the minimum and the maximum.
ExponentialFor tasks, this indicates the task will be an periodic or sporadic task whose arrival times are exponentially distribed with the lambda parameter equal to the average.
For amount of work, this indicates the task will perform a variable amount of work on each execution and the amount of work is exponentially distributed with the lambda parameter equal to the average.
The default value for the distribution is "deterministic" if there is one observed value (ie, all the observations equal that one value). It is "uniform" if there are two or more observed values.Computing the resource usage raises some issues. Essentially, we need to be sure that no resource usage extends past the end of the task in the model. For example, if a task is chosen to have a deterministic amount of work, the amount of work is set to the average value. In the model the task must unlock its resources by that time. In the many runs that we see in the data, the longer runs may use resources beyond that selected cutoff time. Consequently, we use some ad hoc procedures to trim and ignore actual resource usage that is inconsistent with the model (idealized) task's workload parameters.
It is useful to make such decisions here, during the import process, rather than later when editing the model with the task and resource editors. If we wish a shorter workload in the model, then it is easiest to let the import procedures trim the resource usage accordingly, so as to get a consistent model. If we use the task editor and shorten the workload in the imported model, we may need to go through all the resource utilization records for that task and make sure there are no intervals of resource utilization that extend beyond the new, shorter endpoint. This could entail a consider editing effort.
Having developed a model through this import process, one should review the task parameters and resource usage data. We characterize the model at this stage as a "candidate" model. The collected timing data is subject to the jitter of the actual system. It is possible that this import process has collected considerable "noise" along with the desired "signal". It may be appropriate to smooth that out. Additionally, the timings that the model tends to select are averages rather than worst case instances. It may be appropriate to revise the numbers to reflect the worst case instances. There may be some system OS tasks or events or resources that should not be included in the model. This might include work done by the system to collect the trace data and to transfer it from the target to the host.
The point is, the person modeling the system needs to examine this candidate model with a critical mind and apply their knowledge of the system in order to understand how well the candidate model represents the system for the purposes at hand. Successfully importing a data file is not a guarantee that you have a good or adequate timing model of your system.