|
|
|
|
REACT™ for IRIX®
General SGI REACT
Notes:
1) What is REACT? Is it an optional product for IRIX? REACT is the set of real-time features that comes standard with every IRIX installation (asynchronous i/o, schedctl, plock, itimers, nanosleep, etc). REACT is not an optional product but an integral part of IRIX. Many of the REACT extensions to IRIX benefit non-traditional, real-time applications such as multimedia and graphics. With multiprocessor systems, REACT also includes features such as processor control and isolation, multiprocessing control, and interrupt routing. With SGI Origin and Challenge systems, REACT also includes features that allow user-level interfacing to VME and PCI through interfaces such as usrvme and pciba. For more about the specific features of REACT, consult one of the documentation sources identified in Q3. REACT/Pro is an optional product for IRIX. It is a set of tools designed primarily for hard real-time applications (available for multiprocessor systems only). The tools include the following:
In addition to the aforementioned tools, REACT/Pro includes an online (Insight) copy of the REACT Real-time Programming Guide. 3) What documentation exists for REACT? The following documentation exits for REACT and real-time (given in order of increasing detail):
4) Is there an SGI real-time user's group? No, but there is a real-time mail alias for asking and answering questions about developing real-time solutions on SGI. Go here to subscribe. 5) What is real-time? What is a real-time system? What is hard real-time? Simple definition: Real-time systems are ones where a correct computation depends not only on obtaining the right result, but also obtaining the right result within a given time constraint. Academic definition: Real-time systems have completion time constraints which must be satisfied with acceptable predictability. Hard real-time systems are real-time systems where all time constraints are "hard deadlines" and the only acceptable predictability is that all deadlines must always be satisfied. Hint: If we're talking response times in seconds or hundreds of milliseconds, it is generally soft real-time. Hard real-time systems generally deal with response times and latencies that are under a millisecond. 6) In what different real-time applications are SGI systems currently being used? SGI systems are used in the following real-time application areas:
7) SGI systems do awesome graphics, but can they be used in hard real-time applications? YES! SGI systems are being used today in real-time applications that require guaranteed response times. There are SGI systems installed today that are performing hardware-in-the-loop (HWIL) simulations at frame rates >1000 Hz (receiving interrupts and scheduling processes within that timeframe). 8) What is the real-time model for IRIX? From the Real-time in IRIX 6.5 Technical Report: With IRIX 6.5, there are two models for achieving real-time determinism: the processor isolation model and the kernel preemption model. Briefly, here are the definitions for these two models:
Kernel preemption model.
Processor isolation model. 9) What about real-time applications on a single processor SGI system? Under versions of IRIX previous to 6.5, SGI does not make any interrupt response guarantee for single processor systems. Starting with IRIX 6.5, determinism can be achieved by executing real-time processes at high priority and relying upon preemption to ensure that the highest priority runable process is always executing. This requires user processes to preempt both kernel processes and interrupt service routines, The worst-case total interrupt response time for up to an eight processor Origin, Onyx2, Onyx 3000, or OCTANE system using the kernel preemption model is guaranteed not to exceed 1 millisecond. 10) What is the Interrupt Response Time for IRIX on a multiprocessor system? "The REACT extensions included in IRIX 6.5 provide guaranteed deterministic interrupt response on a properly configured Origin, Onyx2, Onyx 3000, or OCTANE system. Performance is specified in terms of total interrupt response, which is defined as the interval between the occurrence of an external interrupt and the start of execution of a user process that was enabled by that interrupt (full context switch included). The worst-case total interrupt response time for a properly configured Origin 3000 system is guaranteed not to exceed 50 microseconds and an Origin 2000 system will not exceed 100 microseconds." Further details on the IRIX interrupt response time is given in the REACT Technical Report. 11) What is the Context Switch Time for IRIX? There are ubiquitous context switch benchmarks available that demonstrate a wide variety of results over a wide variety of constraints, conditions and CPU speeds. One benchmark, for which code can be provided, produces the following results for context switches between two processes (NOT threads) on an Origin 2000 system running on an isolated 180MHz MIPS R10000 CPU under IRIX 6.5.10f:
NUMBER OF CONTEXT SWITCHES = 500000 On an Origin3000 system running on an isolated 400MHz MIPS R12000 CPU under IRIX 6.5.10f:
NUMBER OF CONTEXT SWITCHES = 500000
The basic algorithm is as follows: Please note that the numbers above are an example of the performance. These results were generated with a specific IRIX release and configuration. We do not guarantee context switch times for each IRIX release. Your results may vary as context switch times are susceptible to cache misses, etc. 12) What is POSIX 1003.1b or real-time POSIX? The POSIX 1003.1b standard contains the real-time extensions to the IEEE Portable Operating System Interface for UNIX (POSIX). It was formally adopted as an IEEE standard in September of 1993. From the standard itself: "This standard defines a standard operating system interface and environment to support application portability at the source code level. It is intended to be used by both application developers and system implementors." POSIX.1b does not add a whole lot of real-time functionality to IRIX. What it does do is provide the opportunity for our real-time customers to write code that is more portable between platforms. It is being required as criteria for purchase on more and more real-time programs/projects. 13) Where does IRIX stand on support for real-time POSIX (P1003.1b)? IRIX is now 100% conformant to POSIX 1003.1b. 14) Where does IRIX stand on support for POSIX threads (POSIX 1003.1c)? IRIX is now 100% conformant to POSIX 1003.1c. 15) Can IRIX "distribute" real-time capabilities to non-root users? Yes, IRIX 6.5 includes a feature known as capabilities that extends certain IRIX privileges (such as real-time capabilities) to specific non-root users. See capabilities (4) and capability (4) for more information. With IRIX operating systems up to and including IRIX 6.4, many REACT features (schedctl, plock, sysmp, etc.) are accessible only with root privileges. 16) What is the Frame Scheduler? How can I benefit from it?
From the Real-time in IRIX 6.5 Technical Report: Additionally, multiple non-synched frame schedulers may also exist on a single multiprocessor system. For example, 4 processors could be executing at 60Hz rates and 1 at a 50 Hz rate. There is no more deterministic way for users to schedule processes on their SGI system than through the frame scheduler. In many cases, if a customer's application is already frame based, the frame scheduler can be used as the application's executive, saving development time and effort. Additionally, the frame scheduler is an excellent rapid prototyping tool for executing models or simulations. 17) What is StethoScope? How can I benefit from it? Stethoscope is a real-time graphical monitoring and data collection tool for IRIX. Use it to watch any of your program variables evolve in real time; any value in memory can be monitored. StethoScope opens a window into your application; it shows you what's really happening. Stethoscope has flexible triggering modes to help you collect the data you really need, save it for later comparisons or export it to engineering analysis tools such as MATLAB and MatrixX. Each data set is time-stamped, labeled with signal names and units, and accompanied by any user notes. Other features include on-screen measurements and annotation, PostScript output, "X vs Y" plots, full configuration control, workspace save and restore, direct numeric display, multiple buffer management (continue to collect data while you view saved buffers), and derived signal calculations. You can also use StethoScope to modify variables in your running program. It provides a powerful way to experiment with your system. StethoScope can run completely non-intrusively, without changes to your code's source for execution timing (for real-time multiprocessors). StethoScope permits variables from C, C++, FORTRAN and Ada to be monitored. It will rapidly become your most important debugging, analysis, and performance enhancing tool. A demo copy of StethoScope is available upon request from Real-Time Innovations:
Stethoscope 18) What is real-time debugger? Does SGI have a real-time debugger? Generally, when the real-time community is referring to a real-time debugger they are talking about the capability to monitor and modify variables, non-intrusively, in their real-time application. This monitoring generally is done visually at rates that update at once a second or so. StethoScope (see above) provides this capability and more. It is capable of much higher update rates, graphical display, data storage, and run-time variable modification. StethoScope is currently in use at many IRIX sites (and has been a standard part of the VxWorks real-time platform for years). IRIXview is a logic analyzer for real-time software. 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. IRIXview provides such a view. IRIXview is a tool which enables real-time developers to observe the instantaneous timing of both an application and the IRIX kernel. IRIXview consists of two components linked by sockets: target and host. On the target, event points are inserted in the kernel. When an event point is reached, the event code and time (from the CC timer) are logged. The IRIXview host converts the stream of events into a graphical display. Each target context (i.e. process, interrupt handler, or idle loop) is displayed as a horizontal trace using stipples which indicate the state (eg. running, ready-to-run, sleeping). Other events are displayed as icons (e.g. signals, interrupt entries, etc.). 20) What is the difference between StethoScope and IRIXview? There are three "types" of visualization/analysis tools for REACT: a source-level debugger (Casevision/Workshop), a real-time data monitor (StethoScope), and a operating system visualization tool (IRIXview). A debugger can be thought of as similar to a voltmeter. It measures static values. It's nearly useless for finding peak values, occasional "glitches", or time-dependent quantities like durations of events or noise characteristics. StethoScope is like a digital oscilloscope; it displays all these with ease. IRIXview is like a logic analyzer. It doesn't show analog values (program variables), but it excels at displaying events, such as task switches, semaphore activity, interrupts, etc. In particular, StethoScope is a window into your application. You can view any variable or memory location in your system. For example, you can see how much overshoot your controller has, measure how long it took a change to occur, analyze noise in a sensor, or see how long a data queue is getting. StethoScope will graphically display your data, collect it for analysis, and save it to disk. StethoScope helps you understand what your program is doing. IRIXview, on the other hand, allows you to visualize the relationships and timing between operating system events. For example, you can measure how long it took for an interrupt to execute, how much later that interrupt was serviced, etc. It's also useful for watching and understanding task switching activity: which tasks are running, why tasks are preempted, how long the task switch took, etc. Issues like frame scheduler usage, lock-outs, and interrupt latency are easily revealed. So, StethoScope shows you what your IRIX/REACT application is doing, and IRIXview shows you how IRIX/REACT is running your application. There's a big difference. There's almost nothing IRIXview can show that could be viewed with StethoScope and vice-versa. 21) What are external interrupts? Standard on each Origin 2000, Origin 3000, Onyx2, and Onyx 3000 system are two external interrupt ports (one input and one output), which are designed to be connected to external equipment. The interface to these lines is provided by special device files found in /dev/external_int (see ei(7)). This interface allows separate machines to send and receive interrupts over a dedicated wire for inter-machine synchronization. Physically, the ports are female 3-conductor 1/8 inch audio jacks identical to those found on portable stereo headphones. 22) What are User-Level Interrupts? How can I benefit from them? The user level interrupt (ULI) facility allows a hardware interrupt to be handled by a user process. The ULI facility is intended to both simplify and streamline the response to external events. ULIs can be written to respond to interrupts initiated either from the VMEbus, the PCIbus (not all platforms) or from external interrupt ports. ULIs permit users to effectively provide the Interrupt Service Routine (ISR) for an interrupt - responding to events without taking a context switch. The ULI facility is both easy to use and very high performance - typical interrupt reponse times are under 20 usecs. | |
