WindView Import

Table of Contents

01. Introduction

02. Overview of Import

03. Selection Spreadsheet

04. Histogram Displays

05. Resource Usage

06. Candidate Model

01. Introduction

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 RapidRMA distribution contains some samples in the examples subdirectory.

  For use in the RapidRMA 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 RapidRMA 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 RapidRMA. 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 RapidRMA 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 RapidRMA directory to start RapidRMA.

  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 RapidRMA application will run with the appropriate environment. This requires the person who installs RapidRMA provide the appropriate Tornado path information when RapidRMA 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.

02. Overview of Import

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.

FIGURE 02-A. Requesting a WindView import.

On selecting the file to use, RapidRMA 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 RapidRMA 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.

03. Selection Spreadsheet

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.

FIGURE 03-A. Selection spreadsheet from WindView import process.

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

Normal

Use the default interpretation for this event type. Most events are of the type “Ignore” or “Trigger”

Trigger

Specify that this event serves to demarcate a period. That is, the event serves as boundary between two periods.

Ignore

Specify 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.

FIGURE 03-B. Default Event Types for Common Events.

Semaphore Take Ignore Semaphore operations can be used in a number of different ways. Since RapidRMA cannot discern the intent of the operation, each operation is presented here for further classification. The default interpretation is that "take" and "give" form a protect access to a shared resource. Another interpretation may be that a "take" operation is a synchronization point for a task with an external activity. In that case, the "take" should be treated as the beginning of a task period. You should change its Event Type to "trigger." Semaphore Give Ignore Message Queue Receive Trigger The default interpretation for Message Queue operations is that a "receive" is the beginning of a period. If this in not the case for your system, change the event type to "ignore." Message Queue Send Ignore Task Start Trigger The default interpretation for Start and Complete is that Start is a "trigger." Task Complete Ignore

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.

04. Histogram Displays

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.

FIGURE 04-A. Histograms from WindView import process.

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.

Count Threshold

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.

Minimum

Shows the minimum included observation.

Maximum

Shows the maximum included observation.

Average

Shows the average of the included observations.

Distribution

Shows the type of distribution that will be associated with the task or amount of work.

Deterministic

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.

Uniform

For tasks, this indicates the task will be an aperiodic 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.

Exponential

For tasks, this indicates the task will be an aperiodic 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.

05. Resource Usage

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 editting 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 extened beyond the new, shorter endpoint. This could entail a consider editting effort.

06. Candidate Model

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.