The WindView program is a logic analyzer for real-time software. A real-time system—defined in this manual to consist of the IRIX operating system, your real-time application, and the target system—involves complex interactions among processes, IRIX system objects, and interrupts. These interactions must occur within certain time constraints, often characterized by resolutions of microseconds or finer. Traditional tools for debugging and benchmarking real-time systems have included source-level debuggers and profilers. These types of tools can provide much useful information about a system; however, they provide only a static picture of a very dynamic situation. What real-time developers have needed is a way to view these dynamic interactions in a visual way—a way to look “under the hood” of the real-time system. WindView provides such a view.
The interaction of the processes, objects, and interrupts in a real-time system can result in context switches. The term context switch refers to the operation performed by a multitasking operating system in which the current thread of execution is switched for another. WindView allows the user to examine information on the state of each process in the system and the events that lead to a context switch. This information is shown in a WindView View Graph window; for an example, see the sample WindView View Graph in Figure 1-1.
The View Graph provides manageable access to a wealth of information about the real-time system. With this window, you can scroll the information forward and backward in time and zoom it in and out to different time scales. Detailed information is displayed for each event (such as the action that occurred, the context in which the action occurred, and the object associated with the action). All events are tagged with high-resolution timestamps.
All of this occurs with minimal intrusion (less than 10 microseconds overhead per event) on the real-time system. The system is not halted when information is gathered, and the information-gathering activities have been highly optimized. Because it provides a view into the complex activities of a real-time system, WindView allows you to do the following:
detect race conditions, deadlocks, processor starvation, and other problems relating to process interaction
determine application responsiveness and performance
see cyclic patterns in application behavior
The rest of this chapter describes the events logged by WindView in more detail, the WindView architecture, and the resources that are available to WindView users.
In WindView, an event is any action undertaken by a process or an interrupt service routine (ISR) that can affect the state of the real-time system. Examples of events are process spawns and deletions, system clock ticks, and interrupts. IRIX has been instrumented to log this event information.
In the WindView View Graph window, time is represented on the horizontal axis, while the current system's contexts are represented on the vertical axis (see Figure 1-1):
Beginning at the top of the screen, the interrupts used in the system are listed.
Next, processes are listed.
The last context shown is an idle loop for each processor, with the highest-level processor listed first.
When an event occurs, an event icon is shown in the View Graph. It is placed at the point on the vertical axis that represents the context in which it occurred, and horizontally according to the time (or sequence number) at which it occurred.
You can drag an event icon into an Event Inspector window to see the icon's associated information. For example, when a hardware interrupt occurred for which there is an associated ISR, an IntEnt event icon (see Figure 1-2) is displayed. By dragging the icon into the Event Inspector, you see information on that event: its timestamp, its context, the event name; see Figure 1-3. (For information on using the Event Inspector, see Chapter 3, “Working with Event Data.” For information on what is displayed for each event, see Chapter 4, “Event Dictionary.”)
The following sections describe features of event logging. These descriptions include information on how the GUI looks by default; you can customize many of the GUI's attributes to meet your own needs; see Chapter 6, “X Resources and Tcl Configuration Commands.” In addition, you can choose which events and states to display; see “Examining Data”.
 | Note: In this manual, a kernel mode switch, such as the switch the processor makes from idle mode to resume execution of a user process, is referred to as a context switch. |
In real-time systems, the term current context usually refers to the current process and the information needed to restore the process' state, such as the state of the processor registers, operating system control information, and the stack. For WindView, the meaning of current context has been extended to include any thread of execution: a process, an ISR, or the kernel's idle loop. A context or mode switch, then, refers to a change in the current context, which can occur when one process preempts another, a process delays itself or pends on a resource, or a process is interrupted by an ISR.
When Context Switch events are logged, WindView shows the current context and where it is switched. The current context is shown as a solid, horizontal line (see Figure 1-4), with a different color being used for each processor (on multiprocessor systems). When a context or mode switch occurs, a dotted, vertical line connects the previous context's line to the current context's line.
The term process state transition refers to a process exiting from one state and entering into another; for example, from the pending state to the executing state. A process state transition may or may not result in a context switch, depending on the states of other processes in the system when the process in question makes a transition between states.
When Process State Transition events are logged, WindView shows the process state transitions and possibly the events that cause them. A process state is shown by the type of horizontal line (known as a state stipple) used to display it; see Table 1-1 for a listing of the state stipples. Note that if you are using a color monitor, these state stipples are further differentiated by color. In addition, the event that caused the process state transition is shown as an icon.
| Note: WindView does not provide information on events that do not result in process state transitions. |
As an optimization, events in the Process State Transition are not separately timestamped. However, such events receive the timestamp of the next exit from the IRIX kernel. This exit is typically only a few microseconds after the event that caused the process state transition, and marks the moment at which the process state transition truly takes effect.
Table 1-1. Process State Stipples
Type of Line | Process State | Description |
|---|---|---|
 | Executing | The process, ISR, or idle loop has control of the processor. |
 | Nondegrading,
real-time | A process that executes in the real-time band of priorities. The real-time priorities are those numerically less than or equal to the system-tuning parameter ndpri_lolim, which is normally 39. The kernel guarantees that one of these processes will never sit idle waiting for a process with a lower priority (for example, the network daemon, rtnetd, runs at a non-degrading priority). |
 | Suspended | The process attempted to gain access to a resource or event and the resource or event was not available (also referred to as a “blocked” process). (On multiprocessor systems, if not all processors are traced, a process may display as Suspended even after it has run, since process migration can occur.) |
 | Ready | The process is not waiting for any resource other than the processor; that is, it is ready to execute, but has not yet been executed by the scheduler. (On multiprocessor systems, if not all processors are traced, a process may display as Ready even after it has run, since process migration can occur.) |
When event logging has been started, WindView shows application-specific events. By default, these events are displayed by the User Event icon (see Figure 1-5) on the View Graph. Event numbers are taken from a parameter provided with the rtmon_log_user_tstamp() function call. User-generated events are described in detail in “defaultUser—Display user-specified event”.
WindView consists of two components: one resides on the target (the system for which events are being collected), and the other on the host (the system running the GUI display), as shown in Figure 1-6 (the target and the host can be the same system).
Events are logged to a buffer on the target system. When this buffer starts to fill up, the contents of the buffer are passed to the host by the rtmond daemon.
The kernel's instrumentation is highly optimized and operates with minimal intrusion on the real-time system.
When you start the event collection process under IRIX (either through the Target window “Start” command or through rtmon_client), the instrumented kernel tags certain events with a high-resolution timestamp. The events are then displayed in the WindView View Graph along a timeline showing when they occurred, based on these timestamps. You can see the exact timestamp for any particular event; for details, see “Selecting and Examining Event Data”.
The timestamp driver's resolution is hardware dependent, but is 21 nanoseconds for Challenge, Onyx, Power Challenge, and Power Onyx systems.
The WindView host component (that is, the GUI) is an X application that runs as a process under UNIX. It receives the event data from the target system, processes the data, and displays it in a graphical format. The default target-to-host communication mechanism is TCP/IP.
Normally, event data is displayed by the View Graph as it is received from the target system. WindView analyzes the information gathered from the target system, and then displays it in the View Graph in an easy-to-understand format. You can navigate the event information to see the relationships among system components and to better visualize the system's construction and behavior. For details on using the View Graph, see “Understanding the View Graph”.
In some situations, however, you may find it more convenient and less intrusive to collect the event data in a file on the host, for later analysis and display. For example, you may wish to collect data at a remote site for later analysis at a lab. This is accomplished with the rtmon-client tool, described in “Using the rtmon-client Tool and the Analyze Menu Option”.