Hard Real-Time with Venturcom RTX on Microsoft Windows XP and Windows XP Embedded

 

Venturcom, Inc.

September 2003

Applies to:
    Microsoft® Windows® XP
    Microsoft Windows XP Embedded

Contents

Abstract
Introduction
The Windows XP Platform and the Real-Time World
So, You Want to Create a Hard Real-Time Windows XP Environment?
RTX in Depth
Performance
Future Directions
Conclusion
Availability
References

Abstract

For a variety of business and technical reasons, Microsoft® Windows NT®, Microsoft Windows 2000, Windows XP, and Windows XP Embedded operating systems are increasingly being considered as a platform for deployment of real-time systems. In order to meet the stringent latency requirements of hard real-time systems, it is necessary to augment the capabilities of Windows XP. This white paper examines Venturcom RTX, which provides a real-time subsystem that runs with the Windows XP platform (defined for the purposes of this paper as Windows XP and Windows XP Embedded). It implements deterministic scheduling of real-time threads, inter-process communication mechanisms between the real-time environment and the native Windows XP environment, and other extensions to Windows XP which are often found in specialized real-time operating systems. This paper describes how the components of RTX provide these features, explores current results and experiences, and points out possible future directions for enhancement. (15 printed pages)

Introduction

The popularity and market share of Microsoft Windows XP have been growing. The reasons include:

• The increasing power and declining price of Windows XP platforms.
• The many applications available on the platform.
• The variety of development tools available on the platform.
• The richness of the Microsoft Win32® application programming interface (API).
• The large number of developers, support personnel, and end users who are familiar with the system.

Because of the added complexity and cost of maintaining a heterogeneous computing environment, more companies are striving to use Windows XP as their operating system (OS) at all levels of an organization and its equipment. Its use as a network server system or as a desktop system is easy to understand since these are the very environments for which Windows XP was designed. However, there is also an impetus to use Windows XP in other environments, such as the factory floor, medical devices, simulation equipment, test equipment, and communications equipment. A common characteristic of these environments is that they often require hard real-time system behavior.

Can Windows XP fulfill this need? The answer is, not as delivered. However, with additional software, it is possible to realize hard real-time performance on the Windows XP platform. Otherwise, developers must resort to adding a second real-time computer to their system; adding expense and complexity. The remainder of this paper justifies these statements and describes Venturcom's RTX environment including RTSS, a Real-Time Sub-System, for the Windows XP platform running on the PC architecture (that is, Intel Pentium and compatible systems).

An earlier paper [Carpenter 97] discussed this effort during its development. This paper offers a closer look at the actual implementation as delivered, including performance numbers and enhancements made in the meantime, in addition to a look at future areas for development.

The Windows XP Platform and the Real-Time World

What It Means for a System To Be Real-Time

A real-time system is one in which the correct operation of the system depends not only on the results that are delivered, but when they are delivered. It is important to note that "real-time" does not necessarily mean "fast;" rather, it refers to how deterministic the response time characteristics of the system are. That is, the important measure is not average response time but worst-case response time. Real-time systems are sometimes further classified as hard or soft real-time systems. A hard real-time system is one in which the response time determinism requirement is absolute; for a soft real-time system, some small deviations are tolerated. A fundamentalist viewpoint would consider "soft real-time" to be an oxymoron, and for the remainder of this paper, when we say "real-time" we mean hard real-time.

An example of a real-time system is a system controlling a piece of capping machinery over a conveyer belt transporting bottles to be capped. It is not enough for the system to correctly position the cap dispenser; it must do so when a bottle is in position to be capped. All the accuracy in positioning is worthless if the dispenser arrives in position after a bottle has passed.

In addition to this determinism, there are a number of other requirements that real-time systems have typically come to provide:

• A multithreaded, preemptive scheduler with a large number (typically 64-256) of thread-priorities.
• Predictable thread synchronization mechanisms.
• A system of priority inheritance.
• Fast clocks and timers.

Why Is the Windows XP Platform Not Real-Time?

The Microsoft Windows XP platform has been designed as a general-purpose operating system, suitable for use both as an interactive system on the desktop and as a server system on a network [Solomon 98]. The shortcomings of Windows XP (and therefore, Windows XP Embedded) in real-time applications have been thoroughly researched [Ramamritham 98] [Timmerman & Monfret 96]:

• Too few thread priorities.
• Opaque and nondeterministic scheduling decisions.
• Priority inversion, particularly in interrupt processing.

Although faster processors do dramatically increase processing throughput and average response times and thus may lead one to speculate that the system may become real-time, they cannot make a nondeterministic system deterministic or even always improve worst-case response times. So newer hardware platforms will not make the Windows XP platform real-time.

Some developers have resorted to using two computers—one to run Windows XP and another to run a real-time OS. However, this adds significant hardware costs and complicates the development and integration effort, and is not a general or cost-effective solution.

Why a Real-Time Extension for the Windows XP Platform?

The logic of RTX design is dictated by several factors. The stock Windows XP operating system is a mass-market product, which is not readily tweaked for niche applications like real-time. Although Microsoft-sponsored research into real-time Windows XP has produced some interesting results [Sommer 96]—especially for cases when applications advertise their resource requirements in advance [Sommer 97][Sommer & Potter 96]—it is doubtful that this operating system that aims for a very broad market should absorb the overhead and complexity of real-time functionality [Microsoft 95]. This factor suggests that the proper way to add real-time to Windows XP is through an extension, or a plug-in to the generic product [Jones 98].

At the same time, the Windows XP platform offers a very rich and sophisticated device driver model. That, and the customizable hardware abstraction layer (HAL), offer a developer great flexibility and control over system behavior, and scope for creativity in tackling technical challenges. Thus, real-time functionality can be implemented "by the book" following the Microsoft Windows XP Driver Development Kit (DDK) and HAL models [Baker 97].

Finally, for a writer of Windows XP kernel extensions who is not employed by Microsoft, the Windows XP kernel is akin to silicon, as its interfaces and behavior are fixed. Rather than lament the fact, one can make virtue of necessity and produce a compact design for the extension, a design which is easily portable between different versions of Windows XP. Figure 1 illustrates how RTX lives up to these portability goals.

So, You Want to Create a Hard Real-Time Windows XP Environment?

Why Extend the Windows XP Platform to a Real-Time System?

Given that many of the shortcomings of the Microsoft Windows XP platform just mentioned are due to its thread model and thread scheduler, it is logical that the extension has its own thread model with its own scheduler. Likewise, the Windows XP platform's synchronization objects such as events, semaphores and mutexes lack the necessary real-time semantics (in particular, they neither ready threads waiting on an object in priority order nor prevent priority inversion). For these reasons, the extension should implement its own synchronization objects [Bollella 95].

If, following the logic of the Windows XP environment, you have decided to implement a hard real-time subsystem; your real-time environment should be able to:

• Preempt Windows XP anywhere, at least outside critical Windows XP interrupt-processing code.
• Defer Windows XP interrupts and faults while running real-time tasks.
• Process real-time interrupts while running real-time tasks.

The notion of preempting high-level Interrupt Request Number (IRQ) activity of Windows XP and its drivers for unbounded periods of real-time activity may strike one as dangerous. Yet, such events are commonplace and Windows XP is designed to handle them: high-interrupt request level (IRQL) events intrude on lower-IRQL ones, bus-mastering by DMA peripherals and System Management Mode processing defer even the highest-level interrupt processing, and PCI devices may stall CPU accesses to the input/output (I/O) space. Thus, from the Windows XP platform point of view, RTSS activity that steals its cycles is equivalent to taking and coming back from an interrupt. Such an event is well handled by Windows XP, regardless of its duration.

Functional needs of the real-time subsystem would include interprocess communication (IPC) with the Microsoft Win32 subsystem, access to the Windows XP kernel functionality (interrupt management, port I/O, shutdown/crash handlers), and—importantly—compatibility with Win32 at the source code level.

RTX Structure

RTX is implemented as a collection of libraries (both static and dynamic), a real-time subsystem (RTSS) realized as a Windows XP kernel device driver, and an extended HAL (see Figure 1) [Carpenter 97]. The subsystem implements the real-time objects and scheduler previously mentioned. The libraries provide access to the subsystem through a real-time API, known as RtWinAPI (RtWinAPI is also supported on Microsoft Windows CE and Phar Lap ETS). RtWinAPI provides access to these objects. Note that the RtWinAPI is callable from the standard Win32 environment and from within RTSS. Although using RtWinAPI from Win32 does not provide the determinism available within RTSS, it does allow much of the application development to be done in the more user-friendly Win32 programming environment rather than that provided by the DDK [Anschuetz 98]. All that is necessary to convert a Win32 program to an RTSS program is to relink with a different set of libraries.

Figure 1. RTX Architecture

The Windows XP Service Control Manager directly loads RTX process and dynamic-link library (DLL) executable images—into kernel nonpaged memory.

RTX in Depth

The Real-Time Hardware Extraction Layer (HAL)

The HAL is the one piece of the Microsoft Windows XP platform system whose source is available for modification and extension. RTX has modified the HAL for three purposes:

• To add interrupt isolation between Windows XP and RTSS threads.
• To implement high-speed clocks and timers.
• To implement shutdown handlers.

Interrupt isolation means that it is impossible for a Windows XP thread or a Windows XP-managed device to interrupt RTSS. It is also impossible for a Windows XP thread to mask an RTSS-managed device. The HAL ensures that these conditions are met by controlling the processor's interrupt mask. When running an RTSS thread, all Windows XP-controlled interrupts are masked out. When a Windows XP thread calls to set the interrupt mask, the HAL, which is the software that actually manipulates the mask, ensures that no RTSS-controlled interrupt is masked out.

The Windows XP platform provides timers with a minimum period resolution of 1000 s (1 millisecond). The RT-HAL lowers this to 100 s and provides a synchronized (with the timer) clock with a granularity of .8 s or better.

Protection from Windows XP Stops

In addition to interrupt management and fast-timer services, the real-time HAL also provides Windows XP shutdown management. An RTSS application can attach a Windows XP shutdown handler for cases where Windows XP performs an orderly shutdown, or crashes with the so-called Blue (Stop) screen. An orderly shutdown allows RTSS to continue unimpaired and resumes when all RTSS shutdown handlers return. In a blue-screen stop, RTSS shutdown handlers run with certain limitations, unable to call Windows XP services (for example, new memory allocation). In practice, it means that a shutdown handler should clean up and reset any hardware state, possibly alert an operator, or switch to a hot spare when the system stops, due to either a normal shutdown or a crash.

Figure 2. RTSS Detailed Architecture

Extending the HAL

Since the implementation of RTX version 4.3, the HAL was extended instead of replaced. The HAL extension driver, starting at OS initialization time (SERVICE_SYSTEM_START), performs dynamic HAL detection in memory, intercept interrupt, timer, and shutdown-related calls, and redirect them to their RTX counterparts. This binary-hooking technique has a number of advantages over HAL replacement:

• RTX handles broad range of OEM platforms, as call redirection is limited to calls that vary little among different OEMs and service providers.
• RTX is compatible with a greater range of Windows XP platform Service Pack (SP) releases, as we do not need to merge RTX changes with the latest SP HAL sources.
• Installation becomes more robust, as the on-disk copy of the HAL is untouched; therefore RTX is unaffected by SP upgrades.
• Upgrades to newer versions of Windows become easier, if not effort-free.

The benefits of the HAL extension were demonstrated when RTX has successfully installed on subsequent Service Packs of Windows NT and Windows 2000 without modification.

RTX and Interrupt Latency

Software causes of latency

A switch from Windows XP to RTSS happens on an interrupt, either from the RTX high-speed clock or from another device generating RTX interrupts. Therefore, achieving RTX ISR determinism requires reducing Windows XP interrupt latency. Let us examine the sources of Windows XP platform ISR latencies without RTX present.

The most significant latency is IRQ masking by the Windows XP kernel and drivers, routinely done for periods up to several milliseconds through Windows XP KeRaise/LowerIrql calls. The Windows XP kernel, HAL, and certain special drivers also perform processor-level masking of all interrupts through x86 STI/CLI instructions, for periods of up to several microseconds.

Windows XP and RTX interrupt processing naturally, masks interrupts, thereby adding to ISR latency. Although Windows XP relies very heavily on interrupts in many situations (for example, raising software exceptions or unwinding a thread's stack), the Windows XP interrupt sequence is reasonably compact in its contribution to the worst-case ISR latency.

Hardware causes of ISR latency

The most obvious hardware-related problem is cache dirtying and flushing by applications and the operating system. This category also includes refilling of the TLBs. Video drivers are particularly aggressive users of caches, causing contention-related flushes when an RTX interrupts starts running. Histograms of ISR behavior in the presence of cache-dirtying applications would typically have a double-hump profile, with most samples near the best-case band, and another large number of samples in the flushing-related band (see Figure 3).

Power management, especially on portable devices, creates occasional long-latency events when the CPU is put in a low-power-consumption state after a period of inactivity. Such problems are usually quite easy to detect. A typical system can disable those features through basic input/output system (BIOS) setup.

Some systems, again typically notebooks, use the Pentium processor's System Management Mode (SMM) to perform specialized keystroke or other processing in BIOS firmware. While in SMM, the processor does not field interrupts that adds to ISR latencies.

Fortunately, new generations of system platforms, starting with Advanced Configuration and Power Interface (ACPI) platforms and Windows 2000, use the operating system and not BIOS to provide power management. As a result, these sources of latency are now minimal.

Bus mastering events can cause long-latency CPU stalls. Such cases include high-performance DMA small computer system interface (SCSI) devices, causing CPU stalls for periods of many microseconds, or video cards that insert wait cycles on the bus in response to a CPU access. Sometimes the behavior of such peripherals can be controlled from the driver, trading off throughput for lower latency.

Although no operating system can protect an application against such hardware factors, RTX offers tools to diagnose platform-related latencies, and to identify the misbehaving peripherals. Being mindful of such factors and using RTX tools to qualify one's development platform are essential for a system's overall performance.

RTX Interrupt Latency Reduction Techniques

RTSS entirely eliminates latencies from IRQL masking by the Windows XP platform and Windows XP drivers. The RT HAL performs interrupt isolation, reprogramming the programmable interrupt controller (PIC) when switching between the Windows XP platform and RTSS. The result is that RTX interrupts can always interrupt Windows XP, while RTX masks all Windows XP interrupts while RTSS is running.

Processor-level interrupt masking, on the other hand, cannot be defeated, other than through the perilous use of x86 NMIs (non-maskable interrupts). RTX adopts a static solution by hooking gratuitous cases of interrupt preemption to use IRQ locks instead. The RTX Dynamic Hook functionality scans the HAL for signatures of such operations, hooking them to use spin locks (or IRQ-based synchronization on a uniprocessor) instead.

These techniques provide worst-case interrupt latencies of less than 30 microseconds on typical 800-megahertz (MHz) PC platforms.

RTX Objects

The RTSS Environment has a fast streamlined object manager (see Figure 2). The objects it supports satisfy the following criteria: 1) Usefulness for real-time programming, and 2) Compatibility with Win32. The IPC objects are also available to Microsoft Win32 applications and device drivers, allowing programmers to harness the full power of Windows XP. The IPC set includes mutexes, events, semaphores, and shared memory objects.

The RTSS object manager uses the Windows XP nonpaged memory pool for its storage requirements. Using Windows XP-provided mechanisms decreases RTX resource consumption; however, object allocation is nondeterministic.

RTSS Scheduler

The RTSS scheduler implements a priority based preemptive policy with priority promotion to prevent priority inversion. The RTSS environment provides for 128 priority levels, numbered from 0 to 127, with 0 the lowest priority. The RTSS scheduler will always run the highest priority thread that is ready to run (in the case of multiple ready threads with the same priority, the thread which has been ready the longest will run first). An RTSS thread will run until a higher priority ready thread preempts it, or until it voluntarily relinquishes the processor by waiting, or the time quantum (default is infinite) specified for the thread has expired and another thread at the same priority is ready.

The scheduler has been coded with the requirements of real-time processing in mind. Most importantly, its operation is low latency, and is unaffected by the number of threads it is managing. Each priority has its own ready queue, maintained as a doubly linked list. This allows the execution time of insertion (at the end of the list) and removal (from anywhere in the list) to be independent of the number of threads on the list. A bit array keeps track of which lists are nonempty, and manipulating this bit array is done by high-speed, assembly-coded routines.

While an RTSS thread is running, all Windows XP-managed interrupts, in addition to any interrupts managed by threads of a lower priority than the current thread, are masked out. Conversely, all interrupts managed by higher priority threads are unmasked, allowing for a higher-priority thread to preempt the current thread. In addition to these device interrupts, other mechanisms that can cause the currently running thread to be preempted are the expiration of a timer that causes a higher priority thread to become ready, or the signaling of a synchronization object (by the currently running thread) for which a higher priority thread is waiting.

In order to deal with priority inversion, RTSS implements the classic solution [Nakajima 93] [Sha 90], priority promotion, to prevent this situation. For the duration of the time that a low priority thread owns an object for which a high priority thread is waiting, its effective priority is promoted to that of the high priority thread.

Service Request Interrupt (SRI)

An important architectural feature of RTX is its lockless interrupt-driven interface between Windows XP and RTSS that implements a Local Procedure Call (LPC) mechanism. This clean architectural separation has enabled ports of RTSS to various environments (for example, multiprocessor RTX product) ensuring a fast and robust implementation. The Windows XP side of the RTX driver and the RTSS environment communicate by inserting commands into one of the two buffer queues (one in each direction) and initiating a Service Request Interrupt (SRI) to request service by the other side. A server thread executes a request and a reply message is posted in the other buffer. A typical Windows XP-to-RTSS request is an IPC operation like WaitForSingleObject or a Release operation on an RTSS object. A typical RTSS-to-Windows XP operation is a memory allocation or a file I/O request. The SRI design favors lower response time over throughput, responding to an RTSS request as soon as possible.

Win32-RTSS IPC

Inter-environment IPC is a key feature of RTX, allowing tightly integrated applications where hard real-time processes run in the more resource-intensive RTSS environment. The remainder of the application runs in the Win32 subsystem. This section describes the IPC design.

RTSS proxy model

IPC, as other Windows XP-RTSS communication, uses the SRI channel. Given that the SRI channel prevents Windows XP threads from queuing directly for RTX objects, RTX uses proxy processes and threads to support blocking IPC from Win32. When a Win32 thread accesses an RTX object, RTSS uses a proxy thread on its behalf. This model is clean and economical, its advantages being:

• No state-keeping on the Windows XP side for blocking IPC requests.
• No special-casing in RTSS for external Win32 wait requests.
• Handle and object cleanup for Win32 process and thread termination is handled automatically by RTSS proxy process/thread cleanup.

Although proxies involve some memory and CPU overhead, the clean design and quick implementation were worth the tradeoff.

Taming the Windows XP I/O Manager

Preserving seamless Win32 semantics and achieving good performance for cross-environment IPC presents several challenges.

The Windows NT 4.0 DDK provides no exposed interfaces for driver thread notification in case a Win32 thread using that driver terminates (Windows 2000 and Windows XP introduced a global notification mechanism, but it has some limitations). Yet, Win32 mutex semantics require such a mechanism. An RTX mutex acquired, but not released, by a thread at the time of the thread's termination, must be marked as "abandoned," indicating that the shared data it protects may be inconsistent. To implement thread-termination cleanup, RTX takes advantage of I/O Manager's IRP (I/O Request Packet) cleanup: each thread attached to the RTX Win32 DLL sends a "death IRP" to the RTX driver. When the thread terminates, Windows XP calls this IRP's cancel routine, notifying the RTX driver and, thereby, the RTSS object layer. The I/O Manager presents a powerful, yet often challenging environment, as its event delivery is asynchronous. For example, calls to the MJ_CLEANUP driver dispatch routine and the cancel routine call can come in any order, requiring careful synchronization for the RTX driver's per-thread and per-process structures.

Performance of the Win32-RTSS IPC presented another concern. In early implementations, the total latency of an uncontested RtWaitForSingleObject call from Win32 averaged 130µ. Analysis has shown that about 40µsec of the total (over 30 percent) was spent in the Windows XP I/O Manager. Therefore, RTX 4.2 underwent a redesign of the IPC code, using direct signaling and shared memory between the RTX driver and the Win32 IPC client [Tomlinson 97]. RTX user and kernel threads share synchronization objects, signaling each other directly, thus shrinking the overhead and the latency of the Windows XP I/O manager by a factor of four.

Note that operations on RTX synchronization objects locked by Win32 applications become nondeterministic [Carpenter 97]: as any RTSS thread can preempt a Windows XP thread holding such a lock, causing an apparently unbounded case of priority inversion. This, however, is a matter of application design: locking an object shared from Win32 should be left to a noncritical RTSS thread. Furthermore, this issue is ameliorated when RTSS and Windows XP run on different dedicated processors, in a multiprocessor RTX system.

Fast Timer Support

On all PC platforms, real-time HAL provides clock resolution of 1sec or better, and timer period of 100sec or better. If no RTSS applications are executing, there are no timing differences between systems with RTX installed and systems without RTX installed.

Dynamically Linked Libraries

No tour of Win32 would be complete without a mention of DLLs. RTSS supports Win32 DLL API (LoadLibrary, GetProcAddress). Currently, all the static and global data in an RTSS DLL is shared between all RTSS processes attached to that DLL.

Structured Exception Handling in RTSS

Structured Exception Handling (SEH) is a relatively little known but rather important feature of Win32 and Windows XP kernel environments. Its pedigree goes back to OS/2 and OSF UNIX implementation. SEH provides exception handling through try/except and try/finally constructs of the Microsoft C implementation. C++ exception handling is layered on top of SEH, as are libc signal/raise calls, making SEH a necessity for any Win32-compliant environment. The salient features of this model are:

• Compiler-specific exception handlers.
• Operating system-specific stack unwinder and exception dispatcher routines.
• User-supplied exception filters.
• Two-stage exception handling algorithm which first invokes the OS-specific dispatcher routine to scan the thread's stack backwards calling filters in search of a suitable handler, then the OS-specific unwinder to roll back the stack, if necessary.
• Last-chance default and user-supplied exception routines.
• A special mechanism for nested exceptions and "collided" unwinds.

The RTSS SEH implementation maintains compatibility with Microsoft structures, handler-calling conventions, SEH API behavior, and so forth. In addition, it is engineered for real time, to minimize processor-level interrupt masking and disruptions to RTSS threads:

• Win32 generates a software interrupt when raising a software exception through the Win32 RaiseException API; RTSS calls a user-mode exception dispatcher.
• Win32 SEH uses a special interrupt when it sets a new user context after unwinding the stack; RTSS restores context in user mode.
• Windows XP may "edit" (move) an exception trap frame with interrupts disabled; RTSS does this in user mode.

For hardware exceptions, the RTSS algorithm doctors the trap frame to call the RTSS exception dispatcher; then "returns" from the ISR to the dispatcher, and handles the exception. Thus, a software exception involves no ISR latency penalty for other threads; a hardware exception only adds the worst-case penalty of a single interrupt.

Performance

The following tables and figures present key performance metrics for Windows XP with RTX 5.5 running on an 800 MHz Pentium III processor with an ACPI-compliant chipset.

Operation	Windows XP	Windows CE .NET	RTX 5.5
ReleaseMutex>WFSO: min/max in usec	1.49 / 5000+	4.9 / 13.3	0.70 / 3.26
ReleaseSemaphore>WFSO: min/max in usec	1.39 / 5000+	3.9 / 8.4	0.61 / 3.43
Yield: min/max in usec	1.11 / 5000+	2.6 / 63.9	0.33 / 3.37
Interrupt service thread dispatch: min/max in usec	4.3 / 5000+	13 / 30.8	2.0 / 19
Win32-to-RTSS SetEvent call: min in usec	NA	NA	14

Table—Key RTX Thread Switch Timings under heavy Microsoft Windows XP loading (maximum values include the overhead of timer interrupt processing). Windows XP without RTX and Microsoft Windows CE are shown for comparison. All times are in microseconds µ**.**

Figure 3. RTSS timer-interrupt latency histogram with a typical Windows workload: disk searches, video updates, network activity, screen saver, etc. The X-axis is in microseconds, and the Y-axis is the number of samples on a logarithmic scale. The lower and darker sections of the chart's bars represent activity during the last second only, while the top of the bar is the accumulation for the total run.

Figure 4. Histogram of Win32 timer-interrupt latencies with the same workload as Figure 3.

Copious performance results are available from independent evaluations of RTX 4.x and other real-time Microsoft Windows NT extensions [OMAC 98] [Real-Time 98] [Timmerman 98]. However keep in mind that RTX 5.x provides significantly faster thread switch times than RTX 4.x.

Building RTX Applications with Visual Studio

RTX applications are simply compiled and linked by using Microsoft Visual Studio® like any other Windows application using the RTX provided header files and libraries. An application wizard can be used to setup project settings and generate source code frameworks. Starting with RTX 5.1, the Visual Studio debugger can be used to directly start and debug RTSS processes just like Microsoft Win32 processes. It is process and thread aware and breakpoints can be set and managed. RTX also includes a number of utilities and tools, including the RTSS Object Viewer shown in Figure 5.

Figure 5. Snapshot of the RTSS Object Viewer utility showing a single process with two threads, a timer, and a shared memory object.

Performance Tools

RTX performance tools enable developers to qualify and tune performance on their platforms. Ksrtm is a driver and a Win32 utility for HAL-level, timer-interrupt latency measurement. Running in the kernel makes it relatively insensitive to cache jitter. Ksrtm also determines which Windows XP platform component or device driver is causing the greatest latency event: after such an event, the Ksrtm ISR obtains the address of the interrupted sequence from the stack, and then resolves it to a loaded Windows XP kernel module. The Srtm application is a simple RTX API timer latency measurement tool running either in RTSS or Win32, which produces a histogram, realistically reflecting timer latency observed by an application. The Lpt tool determines long-latency events due to bus mastering events. Finally, Platform Evaluator is a graphical user interface (GUI-based) tool to comprehensively measure the response time characteristics for a platform under various loads.

Target Designer SLD

In addition to supporting retail Windows XP versions, the RTX run-time environment is packaged as an SLD for use with the Windows XP Embedded Target Designer. Because RTX can be configured to auto-start RTSS processes at boot time, even the smallest footprint configurations of Windows XP Embedded can include RTSS applications and launch them earlier in the boot sequence (before the Win32 environment is even started).

Future Directions

Today, RTX addresses a variety of customer needs. However, there are a number of new scenarios that the product is looking to address.

Multiprocessing

The initial releases of RTX ran on single processor systems. The most recent release runs on multiprocessor systems that conform to the Intel Multiprocessor Specification Rev 1.4.

This specification provides for interrupts to be controlled by an Advanced Programmable Interrupt Controller (APIC), suitable for a multiprocessor system. Through the APIC, different interrupts can be steered to different sets of processors. RTSS dedicates one processor of the system to running RTSS threads, while the remaining processors run Windows XP threads. This dramatically lessens the latency of real-time threads while preventing the processor starvation of Windows XP threads possible on a single processor system. RTX 5.1 also allows the RTSS processor to be shared with Windows, similar to the single processor case.

Plug and Play Devices and Power Management

With RTX 5.0, RTX was fully integrated with the Plug and Play and Power Managers for Windows. RTX and Windows work together to manage device resources between Windows and RTX managed devices, so that on ACPI platforms, interrupts are dynamically assigned to PCI devices to minimize interrupt conflicts. While RTX applications are running, RTX prevents Windows from powering down to a lower-power state and interfering with real-time performance.

Ways to Grow

RTSS can serve as a basis for other real-time environments, such as Java [Nilsen 98] [Nilsen & Lee 98].

Conclusion

Venturcom's RTX has shown that, with a selected collection of extensions, it is possible to augment the Windows XP platform to provide the features of a real-time operating system at the same time it continues to be used as a general purpose platform. The resulting system meets the constraints of determinism that are a necessary part of the real-time world, while providing an environment more familiar to a wide body of users.

Availability

RTX is available from the Venturcom Web site.

References

[Anschuetz 98] E. Anschuetz, M. Biddle, S. Giambarberee, B. Riner, J. Dube, Real Time Flight Simulators Under NT, Proceedings of the 1998 Interservice/Industry Training, Simulation and Education Conference (I/ITSEC December 1998).

[Baker 97] Art Baker, The Windows NT Device Driver Book, Prentice Hall, 1997.

[Bollella 95] G. Bollella and K. Jeffay, Support For Real-Time Computing Within General Purpose Operating Systems: Supporting co-resident operating systems, Proc. IEEE Real-Time Technology and Applications Symposium Chicago, IL, May 1995.

[Carpenter 97] Bill Carpenter, Mark Roman, Nick Vasilatos, Myron Zimmerman, The RTX Real-Time Subsystem for Windows NT, Usenix Windows NT Symposium, 1997.

[Jones 98] C. Jones, M. Cherepov, Windows-based systems and the Win32 API, Real-Time Magazine 98/3.

[Microsoft 95] Microsoft, Real-Time Systems and Microsoft Windows NT.

[Nakajima 93] T.Nakajima, T.Kitayama, H.Arakawa, H.Tokuda, Integrated Management of Priority Inversion in Real-Time Mach, IEEE Real-Time Systems Symposium, December 1993.

[Nilsen 98] Kelvin Nilsen, Simanta Mitra, Sairam Sankaranarayananan, Venkatesh Thanuvan, Asynchronous Java Exception Handling in a Real-Time Context, Workshop on Programming Languages for Real-Time Industrial Applications '98, Madrid, Spain, December 1, 1998.

[Nilsen & Lee 98] Kelvin Nilsen, Steve Lee, Perk(TM) Real-Time API, July 1998, Newmonics, Inc.

[OMAC 98] Open Modular Architecture Controls (OMAC) Users Group, Hard Real-time Extensions of Windows NT Evaluation Report Test Plan and Phase 1 & 2.

[Ramamritham 98] Krithi Ramamritham, Chia Shen, Oscar Gonzalez, Shubo Sen, Shreedhar B Shirgurkar, Using Windows NT for Real-Time Applications: Experimental Observations and Recommendations Proceedings of IEEE RTAS'98 (the IEEE Real-Time Technology and Applications Symposium), June 3-5, 1998. Denver, Colorado.

[Real-Time 98] Real-Time Magazine, Windows NT RT Extensions - Evaluation Reports.

[Sha 90] L. Sha, R. Rajkumar, and J. P. Lehoczky, Priority Inheritance Protocols: An Approach to Real-Time Synchronization, IEEE Transactions on Computers, 39 (9):1175-1185, September 1990.

[Solomon 98] David A. Solomon, Inside Windows NT, Second Edition, Microsoft Press, 1988.

[Sommer 96] Sommer, S., Removing Priority Inversion from an Operating System, Proceedings of the Nineteenth Australasian Computer Science Conference (ACSC'96), Melbourne, Australia, January 31 - February 2, 1996.

[Sommer & Potter 96] S. Sommer and J Potter, An Overview of the Real-Time Dreams Extensions Proceedings of the Third Australasian Conference on Parallel and Real-Time Systems, September 1996.

[Sommer 97] Sommer, S., Dreams in a Nutshell, Proceedings of the USENIX Windows NT Workshop, Seattle, Washington, August 11-13, 1997.

[Timmerman & Monfret 96] M. Timmerman and J. Monfret, Windows NT as Real-Time OS? Real-Time Magazine.

[Timmerman 98] Martin Timmerman, Bart Van Beneden, Laurent Uhres, Windows NT Real-Time Extensions: better or worse? Real-Time Magazine - 98/3.

[Tomlinson 97] Paula Tomlinson, Understanding NT: Signaling Apps from Drivers, Windows Developer's Journal, March 1997.

© Microsoft Corporation. All rights reserved.