RTX64 RTOS, Frequently Asked Questions for Real-Time Windows 10

Hard real-time requires that a response be logically correct and occur before a specific deadline. Otherwise, the result is incorrect and holds no value.

Soft real-time requires that a response be logically correct and occur before a specific deadline or the result becomes increasingly inaccurate. That is, the result can still hold some value even though it occurred after the required deadline.

Determinism is defined as the ability to rationally predict, with a degree of precision, when an event will happen. Determinism, combined with a real-time environment, guarantees that an event will happen within a small response time and that the performance of this event is repeatable.

A real-time operating system provides determinism and predictability when it responds to a given event through a specialized scheduler.

Windows is usually referred to as a general-purpose operating system because it does not allow applications or kernel-level drivers to completely mask interrupts and gain control over the operating system. Depending on hardware, interrupt latencies under Windows can exhibit very good values, averaging in microseconds. However, worst-case interrupt latencies are unbounded and can exceed hundreds of milliseconds. Because of these unbound latencies, deterministic response time is not guaranteed, making standard Windows Desktop and Server operating systems unacceptable for real-time use.

IntervalZero’s RTX64 software transforms Microsoft Windows into a Real-Time Operating System (RTOS).

For projects that demand a Windows user experience and require hard real-time or determinism, the RTX64 RTOS Platform enables OEMs and end users to capitalize on Windows, x64 multi-core multi-processor technology, symmetric multiprocessing (SMP) and real-time Ethernet – all in a single integrated development environment.

• Reduce bill of materials (BOM) costs by 25-50%
• Boost quality and performance
• Scale quickly and shorten product cycle times
• Significantly reduce reliance on proprietary hardware such as DSPs

RTX64 supports Symmetrical Multiprocessor Systems (SMP), a computer architecture that allows operating system tasks and user threads to be scheduled to run on any available processor. With this model, multiple processors can be configured for real-time activities. RTSS threads can be assigned to run on dedicated RTSS processors and can run concurrently.

When running RTX64 on an SMP-enabled system, you configure how many of the processors are dedicated to Windows and how many are dedicated to the RTX64 Real-time Subsystem (RTSS). RTX64 supports SMP systems that have as many as 64 processors. Of those 64, up to 63 can be dedicated to RTX64 (dependent upon the edition licensed).

The RTX64 Runtime enables general-purpose Windows processing and high-performance real-time processing and control on commercial-off-the-shelf (COTS) machines. The RTX64 Runtime can be configured to take part in Windows mini-dumps or to take control and safely shut down real-time processes if Windows encounters a failure.

The RTX64 SDK provides developers with a rich set of inter-process communication and synchronization capabilities, allowing RTSS applications to communicate and share data with Windows applications (32-bit and 64-bit). Additionally, RTX64 allows developers to directly access I/O port address space, physical memory, or hardware without forcing any driver model on the user.

RTX64 takes advantage of 64-bit registers and compilers, allowing real-time developers to do the same.

Using RTX64 on an SMP system provides significant benefits, including:

• Performance Boost – You can have multiple processors dedicated to critical, real-time tasks. You can concurrently run up to 63 real-time threads on a 64-processor system.
• Performance Scalability – Performance scaling doesn’t require code rewrites. You can adjust the real-time and non real-time performance balance by changing the number of RTSS processors and Windows processors.
• High Availability – Critical tasks can be scheduled to run on more than one RTSS processor.
• IRQ Affinity – You can specify a dedicated RTSS processor for processing the input and output of individual pieces of hardware.
• System Fault Handling – Real-time tasks survive over system crashes.

RTX64 Runtime is available in several editions, allowing you to license as many processors as are necessary for your solution. RTX64 Runtime is available in these editions:

You can assign available processors to Windows or RTX64 through the RTX64 Activation and Configuration utility. The utility automatically detects the total number of processors on your system. For more information, see Configuring your System in the RTX64 Help.

All RTX64 Runtime editions include the same features. Applications created with the SDK will be able to run on any edition running the same version of RTX64. This allows developers the freedom to develop applications that can be scalable.

The predecessor version to RTX64 was the 32-bit enabled RTX, which was first released in 1997 and has been deployed in over 1 million machines/devices that require a real-time scheduler.  RTX64 capitalized on capabilities found in the 64-bit x86 chips and Windows to deliver even better performance and less jitter because the addressable memory for RTOS operations grew from 2GB to 512GB. The RTX64 product was released in 2013 to provide a real-time subsystem for Windows 7. RTX64 has continued to evolve, and it now supports multi-processors running the following 64-bit operating systems:

Windows 11

• Windows 11 (up to General Availability Channel Version 23H2)
• Windows 11 IoT Enterprise

See RTX64 Support for Windows 11 Updates for up-to-date information on Windows 11 support.

Windows 10

• Windows 10 (up to Semi-Annual Channel Version 22H2)
• Windows 10 IoT Enterprise LTSC (Long Term Servicing Channel Version 22H2)

See RTX64 Support for Windows 10 Updates for up-to-date information on Windows 10 support.

The latest version is RTX64 4.5, released in 2024.

RTX64 is used in a wide variety of products and vertical markets. Anyone designing an application that requires system control, determinism, or real-time performance on Windows can benefit from incorporating RTX64 into their product design.

RTX64 is used in some of the following markets:

• Industrial Automation
• Digital Audio
• Test & Measurement
• Medical
• Military Aerospace

IntervalZero provides six editions of the RTX64 Runtime product:

RTX64 Runtime is available in these installer packages:

• RTX64 Runtime Install – RTX64 can be installed silently. The installation can be invoked from the command line or used within your own product installation to not require user interaction during the installation process.
• Merge Modules for RTX64 Runtime Features – The RTX64 components are available as merge modules that can be included in an OEM product installation. A separate installation places merge modules on the system for your use.

For more information, see the RTX64 Deployment Guide, available from the Customer Center.

RTX64 Runtime includes these features:

• Extends the Windows HAL to support real-time control and isolation of interrupts
• Scheduler that schedules across multiple cores in a dedicated configuration
• Deterministic local memory through configurable process MSpaces.
• Processing and networking capability through a Network Abstraction Layer (NAL) and an optional RT-TCP/IP protocol stack within the RTSS environment
• A Control Panel to configure the RTX64 Subsystem
• The ability to display RTSS process output to a console window that can be configured to display for each real-time application or as a single instance for all real-time applications.
• A Task Manager utility for viewing real-time processes (.rtss) and Windows processes linked to RTX64 (.exe). You can start new tasks and terminate running tasks using the Task Manager. You can also schedule tasks to start with the Subsystem, and view CPU Usage data for all processors assigned to either Windows or RTX64
• Monitoring infrastructure that allows developers to profile the behavior of RTSS applications across all RTSS processors. Also included is a simple utility that outputs a readable text file.
• Latency View tool to view timer latency on Windows and RTSS cores.
• Command line utilities to view CPU usage and object states.
• Comprehensive Help files and User Guides

See the RTX vs RTX64 Comparison Guide, available from the Customer Center, for information on the differences between RTX64 and RTX.

RTX64 SDK includes these components:

• Header files and libraries
• Support for Visual Studio 2022, 2019, 2017, and 2015 (deprecated)
• Microsoft C Runtime support
• Templates for creating applications and DLLs
• API code snippets
• RTX64 WinDbg Extension that extends Microsoft’s 64-bit version of WinDbg and provides a way to analyze and interpret the state of RTSS processes, as well as the RTX64 Subsystem.
• Tracealyzer for RTX64, a diagnostics tool from Percepio for viewing monitoring session data
• Symbols to key RTX64 Runtime components
• Comprehensive Help files and MiniTutorials
• Source code samples to help explain more advanced development topics

RTX64 components must be activated with a valid license before they can be used. You can use the RTX64 Activation and Configuration utility, which appears immediately after program installation, to activate and lock your product to a specific machine or to an IntervalZero-provided small form factor dongle. For information on first activation, see the RTX64 Install Guide for your product, or see the RTX64 Deployment Guide. Both are available from the Customer Center.

The method you use to activate your copy of RTX64 will depend on whether you are connected to the Internet. Videos are available that walk through the process of activating with an Internet connection and activating without an Internet connection. You can watch the videos at https://www.intervalzero.com/en-resources/en-videos/.

RTX64 can run on systems with up to 64 processors; up to 63 can be assigned to RTX64.

RTX64 can be used on mobile x86 processor systems. However, since mobile processors use power policy technology to lower processor speed during Windows idle time to conserve energy, long latencies can occur when the processor becomes unavailable during the speed change. RTX64 interacts with Windows Power Management options to disable this functionality which causes the processors to become unavailable. Users can re-enable Windows Idle detection if their application can work with the resulting latency.

No, x2APIC systems are not supported. Only systems that allow for x2APIC to be turned off are supported. The RTX64 installation will disable x2APIC when possible.

RTX64 can be used on hyper-threading systems. RTX64 treats the logical processor created by Intel Hyper-Threading as a separate processor. Because both logical processors share the same physical processor, one logical processor can adversely affect the performance of the other. It is recommended that you use even numbers of windows processes so a Windows logical processor and an RTSS logical processor do not share the same physical processor. You should also evaluate RTX64 performance to ensure that when hyper-threading is enabled, your real-time requirements are still achieved.

RTX64 Runtime can be run alongside 3rd party antivirus software if RTX64 is granted access to the system folders and directories it requires. If RTX64 does not work correctly on a system with a 3rd party antivirus, we recommend that you enter exceptions within the antivirus rules/policies. For instance, you can instruct the antivirus software to ignore the RTX64 components RTX_RTSS, RTX_HALEXT, etc., or to ignore the RTX64 install folder entirely. Sometimes, you may need to ignore the folder from which your binaries are being run.

See the TechNote RTX64 Compatibility with Microsoft Security Features, available from the Support Site, for information on which Microsoft Security Features can be run on the same system as RTX64 Runtime.

Virtual Machines (VMs) should not be used for deploying RTX64 Runtime products, since the Real-time Subsystem cannot guarantee determinism in a virtual environment. However, virtual machines can be used for development and testing. See the TechNote Virtual Machines Tested with RTX64/RTX, available from the Support Site, for information on Virtual Machines that have been used internally by IntervalZero and are known to work with RTX64.

To run RTX64 Runtime on a virtual machine in RTX64 4.4 and later, you must select Enable virtual machine support during installation. RTX64 does not support all virtualization functionality. Enabling this feature may cause your system to generate a Windows STOP error when the RTX64 Subsystem is started.

NOTE: A dongle is required when licensing RTX64 Runtime on a VM. In version 4.1 and previous, a dongle is required to license RTX64 SDK on a VM.  In version 4.2 and later, RTX64 SDK does not require dongle activation on a VM.

NOTE: There is a known issue where RTX64 Runtime and TCP/IP components fail to activate when Hyper-V or Intel Virtualization is enabled. For more information, see the TechNote RTX64 Runtime and TCP/IP Components Fail to Activate when Hyper-V or Intel Virtualization is Enabled, available from the Support Site.

IntervalZero provides the option of a silent command line installation for RTX64, which allows an OEM to wrap the RTX64 installation and hide it within another installation. The RTX64 Runtime components are also available as merge modules that can be included in the installation of an OEM product.

IntervalZero provides Managed Code and Native Frameworks that can be used to programmatically configure the RTX64 Subsystem. This allows customers to set up their software’s subsystem requirements without requiring anything from their end users.

RTX64 provides local and remote launch and attach debugging capabilities for RTSS applications with Visual Studio 2019, 2017, and 2015 (deprecated).

RTX64 also provides excellent flexibility for processing exceptions. You can configure RTX64 to handle exceptions with a structured exception handler; generate a debug break; or stop the process and dump memory.

RTX64 provides a WinDbg Extension that can be used for postmortem debugging of a Windows memory dump file.

RTX64 also provides monitoring functionality that allows you to trace application behavior without requiring code modifications to your real-time application. Tracealyzer, a graphical tool for analyzing monitor session data, is also provided.

Yes. Once RTX64 has been successfully installed, all authenticated users who log on to the system can control, configure, and run the RTX64 Subsystem and RTSS applications, even if they are not computer or domain administrators. System administrators can control access to the RTX64 resources by configuring members of the RTX64Administrators and RTX64Users groups. For more information, see the RTX64 Runtime Install Guide, available from the Customer Center.

No. RTSS applications are developed with Microsoft Visual Studio. The RTX64 SDK provides a wizard for easy project creation and templates to help you get started. Visual Studio Debugger support lets you debug RTSS applications in a familiar environment. RTX64 supports local and remote debugging through launch, and local attach in Visual Studio 2022, 2019, 2017, and 2015 (deprecated). A WinDbg Extension is also available for postmortem debugging of Windows memory dump files.

RTX64 also supports use of the Intel C++ Compiler within the Visual Studio IDE.

RTX64 supports a subset of over 50 Windows API calls that make sense in a real-time environment.

In addition, RTX64 provides a large selection of real-time API calls that developers use to access the RTSS and system resources. This real-time API (RTAPI) is composed of a set of unique API calls and Windows-based API calls.

The unique real-time API calls are Windows-modeled calls that provide essential programming capabilities required for real-time applications, along with access to the RTSS and system resources. These unique RTAPI calls have no equivalent Windows calls.

The Windows-based API calls that are supported by RTX64 are unlike the unique RTAPI calls in that there are similar functions in the Windows environment; however, these calls require a different implementation than their Windows counterparts to support the real-time requirements of the RTSS. All the Windows -based calls are compatible with Windows programming interface semantics, making it easy for developers already familiar with the Windows API.

RTX64 was designed so that developers could design and develop applications as RTSS or Windows applications. When built as a Windows application, developers can take advantage of features like user-mode memory protection and other third-party debugging tools specific to user mode applications. After an application is working as desired, recompile it as an RTSS application which runs in the real-time subsystem on dedicated processors with no code changes required.

Unlike other applications running in kernel mode, RTSS applications support structured exception handling. RTX64 lets developers call structured exception handling functions such as try, catch, and throw within their RTSS application. For example, if an application references a NULL pointer, the application can handle the error by terminating or freezing the application that caused the fault without bringing down the system.

RTX64 supports a subset of Microsoft C Runtime calls that you can call from your RTSS application. RTX64 provides Microsoft C Runtime Support for Microsoft Visual Studio 2022, 2019, 2017, and 2015 (deprecated).

Yes. RTX64 supports and saves state information for AVX/AVX2 (YMM0~YMM15), AVX-512, SSE (SSE/SSE2/SSE3/SSE4), and MMX registers, if the hardware supports it.

RTX64 SDK includes a complete API reference guide for all supported functions in addition to small code segments that explain more complex concepts.

RTX64 SDK also provides source code for several sample applications, some of which are the RTX64 measurement tools. These samples can be compiled and run and show essential concepts and application interaction. For customers with support, the IntervalZero Support Site contains several samples and tools for use with RTX64.

RTX64 provides these tools (available from the Support Site and/or Customer Center) and APIs that help Developers measure system response and timer latency:

• SRTM (System Response Timer Measurement) is a command-line application that measures timer latencies and displays results in reports and histograms.
• KSRTM (Kernel System Response Timer Measurement) is a measurement tool that measures HAL-level timer latencies to the Interrupt Service Routine (ISR) and provides reports and histograms of the results.
• Latency View is a tool that displays a visual comparison of latency between Windows and RTX64 cores.
• RtPerfMonitor is a command-line program that displays system information, including speed and type of processor running RTX64, HAL type, CPU utilization, and other information that can be used to help measure RTSS application load.
• Platform Evaluator is a standalone tool that tests a system’s readiness for running real-time applications. Platform Evaluator comes with pre-loaded test modules for Windows and real-time (RTSS) environments. You can also build, customize, and run your own tests.
• WinSmiTrace is a Windows utility that can be used to detect and quantify the presence of SMI activity. It runs a Windows driver and can be run with or without the Real-time Subsystem.
• Several APIs for profiling across processors, including the following:
  • RtGetThreadTimes retrieves the execution time of a given thread.
  • RtGetProcessTimes retrieves timing information for a given RTSS process.
  • QueryPerformanceCounter and QueryPerformanceFrequency provide accurate time tracing between multiple processors.

RTX64 lets Windows and RTSS applications communicate through several Inter-Process Communication (IPC) objects. Use the RTAPI functions to create objects that can be viewed and used by Windows processes (32 and 64-bit). Like Windows inter-process communication, RTSS, and Windows applications create or open handles to named objects or memory regions, allowing simple and standard communication and synchronization between real-time (RTSS) and non-real-time (Windows) applications. Shared memory regions allow Windows and RTSS applications to view the same physical memory without passing additional messages or data between environments.

Standard objects:

• Event – The event object is a synchronization object. It is useful in sending a signal to a thread, indicating that a particular action has occurred.
• Mutex – The mutex object is a synchronization object whose state is signaled when it is not owned by any thread and not signaled when the mutex is owned by a thread. The mutex object arbitrates exclusive access to a shared resource.
• Semaphore – The semaphore object is a synchronization object that maintains a count between zero and a specified maximum value. The count is decreased by one each time a thread completes a wait for the semaphore object; the count is increased by a variable amount at the semaphore release. When the count reaches zero, the semaphore object’s state is no longer signaled and no more threads can complete a wait on the semaphore object until some thread increases the count.
• Shared Memory – The shared memory object is a region of non-paged physical memory that can be mapped into the virtual address space of a process. When a shared memory object has a name, additional processes may map the region of memory. A shared memory object is accessed with both a handle and a virtual address. For a process to completely end its access to a shared memory object, it must close any open handles.

RTX64 acquires the resources the device needs from the Windows Plug and Play Manager. To make this possible, a device’s driver must be updated to point to the RTX64 plug and play stub driver. After the device is controlled by RTX64, the device’s resources must be updated to request a unique interrupt that is not already being used by Windows. (Sharing interrupts with Windows would cause determinism to be lost.) Note that a unique interrupt is only needed for devices that use line-based interrupts. Once the device is set up, any RTSS application can access and use the device.

RTX64 supports MSI and MSI-X-capable devices, providing an alternative to line-based interrupts. This functionality is available on all RTX64-supported operating systems.

Windows has a set of 64 priority levels, ranging from 0–63. They are further defined into 4 priority classes, of which the “real-time” priority class is the highest priority class.

The “real-time” priority class, in turn, has 7 levels within the class. RTX64 uses a flat priority scheme of 127 priority levels.

RTX64 provides the option to set one of two priority inversion protocols to handle cases where a higher priority thread is waiting on a mutex held by a lower priority thread:

• Priority Promotion with Tiered Demotion elevates a low priority thread to the level of the highest priority thread that is waiting for the shared mutex until it has released the mutex requested by a higher priority thread.
• Disable – Does not elevate priorities in cases where a higher priority thread is waiting on a mutex held by a lower priority thread.

RTX64 includes a real-time enabled Hardware Abstraction Layer (HAL) extension; this extension does not replace the existing Windows HAL. The extension maintains interrupt isolation between RTSS and Windows. Windows cannot mask (at the interrupt controller level) interrupts managed by RTSS. Windows interrupts are masked on RTSS processors/cores. The real-time HAL extension supports high-resolution clocks and timers for RTSS, while it also supports non real-time clocks and timers for Windows. Other real-time HAL extension features include a software interrupt mechanism between RTSS and Windows, basic exception management, and enhancements for determinism. The HAL timer values can be changed via a predefined value table to as little as 1µs, or can be assigned a custom value using the SDK.

RTX64 supports Intel^® Resource Director Technology (RDT), which provides a set of resource allocation (or control) capabilities that provide control over how shared resources such as last-level cache (LLC) and memory bandwidth are used by applications. These capabilities include Cache Allocation Technology (CAT) and Memory Bandwidth Allocation (MBA).

As a primary setup for Intel^® RDT, RTX64 separates L3/L2 caches space between Windows cores and RTSS cores, thereby removing cache contention from Windows or other system activities. RTX64 sets Windows cores with maximum memory throttle and RTSS cores with zero memory throttle. To further differentiate the performance among the parallel running RTSS threads, RTX64 introduces two RDT modes for CAT and MBA: Flat performance mode and Priority-based CLOS performance mode.

See the RTX64 Help for more information.

Windows STOPs, or Bug Checks, are the result of kernel level drivers or operating system components failing safety checks, bringing Windows to a controlled stop. These Windows STOPs are designed to keep data corruption to a minimum and help developers find out what went wrong.

Since the RTSS is able to continue running after Windows issues a STOP, developers can build safe shutdown handling into RTSS applications. RTX64 calls the shutdown handlers when Windows issues a STOP, allowing system real-time components to safely shut down. Once all shutdown handlers finish running, RTX64 lets the Windows shutdown process continue.

If the RTSS determines that Windows needs to be shut down, RTX64 issues a STOP, but instead of displaying the traditional Windows blue screen, RTX64 displays the RTX64 green screen, which contains information about the state of RTX64 at the time of the STOP.

No states are saved when Windows crashes.

The Internet of Things (IoT) is a system of interconnected physical devices that are embedded with sensors, software, and network connectivity to exchange data and communicate with each other.  The magic of RTX64 architecture is that it transforms the machine controller into a more valuable Smart Edge Device.  It achieves this by blending the hard real-time functionality required to control a machine with the general-purpose processing of Windows to enable analysis of data at the edge of the network, to provide insights and actionable intelligence, and to improve decision-making and operational efficiency. 

IntervalZero RTX64 is a real-time operating system (RTOS) built from the ground up to run on and take full advantage of the Windows general-purpose operating system and is designed for use in industrial automation, medical devices, and other critical applications.  The key features that set it apart from other RTOSs include: 

1. Windows compatibility: One of the key features of IntervalZero RTX64 is its compatibility with Windows. It allows developers to use the familiar Windows development environment to build real-time applications, which can help reduce development time and costs. 
2. Windows Application Ecosystem: RTX64 is uniquely designed to allow third-party Windows applications to run on the same Industrial PC that runs the RTX64 machine control real-time application.  This means that machines require only one PC whereas most RTOSs require one PC for the machine control and one PC for the Operator console or other local application. 
3. Support for multiple programming languages: IntervalZero RTX64 supports multiple programming languages, including C, C++, and .NET languages, such as C# and VB.NET. This makes it easier for developers to build real-time applications using the language they are most comfortable with.
4. Open standards-based: IntervalZero is committed to open standards and tools (Windows, Visual Studio, RTX64 RTOS, C++, EtherCAT,  TSN, OPC-UA)  which protects our customers’ investment and to IoT-readiness that ensure the machine builder can support any future cloud connectivity demands. The RTOS Platform serves as an integration environment. The modularity and customizability ease the burden of integrating multiple controllers.  Some forward-thinking machine builders are even consolidating multiple controllers onto a single PC.
5. Hard real-time capabilities: Like all RTOSs, RTX64 is a hard real-time operating system, which means it can guarantee a deterministic response time to events, even under heavy loads.  But the benefit of RTX64 is that it directly shares the same memory with the non-RTOS application which eases integration and shortens time to market. Advanced debugging capabilities: IntervalZero RTX64 provides advanced debugging capabilities using familiar Windows debugging techniques, including kernel-aware debugging, which allows developers to debug real-time applications at the kernel level. This makes it easier to identify and fix issues in real-time applications. 

Hard real-time requires that a response be logically correct and occur before a certain deadline or the result is incorrect, and holds no value.

Soft real-time requires that a response be logically correct and occur before a certain deadline or the result becomes increasingly inaccurate, meaning the result can still hold some value even though it occurred after the required deadline.

Determinism is defined as the ability to rationally predict, with a degree of precision, when an event will happen. Determinism, combined with a real-time environment, guarantees that an event will happen within a small response time and that the performance of this event is repeatable.

A real-time operating system provides determinism and predictability when it responds to a given event through a specialized scheduler.

Windows is usually referred to as a general-purpose operating system because it does not allow applications or kernel-level drivers to completely mask interrupts and gain control over the operating system. Depending on hardware, interrupt latencies under Windows can exhibit very good values, averaging in the microseconds. However, worst-case interrupt latencies are unbounded and can exceed hundreds of milliseconds. Because of these unbound latencies, deterministic response time is not guaranteed, making standard Windows Desktop and Server operating systems unacceptable for real-time use.

IntervalZero’s RTX software transforms Microsoft Windows into a Real-Time Operating System (RTOS).

For projects that demand a Windows user experience and require hard real-time or determinism, the RTX RTOS Platform enables OEMs and end users to capitalize on Windows, x86 multi-core multi-processor technology, symmetric multiprocessing (SMP) and real-time Ethernet – all in a single integrated development environment.

• Reduce bill of materials (BOM) costs by 25-50%
• Boost quality and performance
• Scale quickly and shorten product cycle times
• Significantly reduce reliance on proprietary hardware such as DSPs and MCUs

IntervalZero’s RTX is a proven, reliable technology that has achieved Safety Integrity Level 3 – SIL-3 – certifications in Industrial Automation and FDA Class II certification with numerous medical equipment manufacturers.

RTX supports Symmetrical Multiprocessor Systems (SMP); a computer architecture that allows operating system tasks and user threads to be scheduled to run on any available processor. With this model, multiple processors can be configured for real-time activities. RTSS threads can be assigned to run on dedicated RTSS processors and they can run concurrently.

When running RTX on an SMP-enabled system, you configure how many of the processors are dedicated to Windows and how many are dedicated to the RTSS. RTX supports SMP systems that have as many as 32 processors. Of those 32, a maximum of 4 can be dedicated to Windows and up to 31 can be dedicated to RTX (dependent upon the edition licensed).

The RTX Runtime enables general-purpose Windows processing and high performance real-time processing and control on commercial-off-the-shelf (COTS) machines. The RTX Runtime can be configured to take part in Windows mini-dumps or to take control and safely shutdown real-time processes if Windows encounters a failure.

The RTX SDK provides developers with a rich set of inter-process communication and synchronization capabilities, allowing RTSS applications to communicate with Windows applications and share data with them. Additionally, RTX provides developers with the ability to directly access I/O port address space, physical memory, or hardware without forcing any driver model on the user.

Using RTX on an SMP system provides significant benefits, including:

• Performance Boost – You can have multiple processors dedicated to critical, real-time tasks. You can concurrently run up to 31 real-time threads on a 32-processor system.
• Performance Scalability – Performance scaling doesn’t require code rewrites. You can adjust the real-time and non-real-time performance balance by changing the number of RTSS processors and Windows processors.
• High Availability – Critical tasks can be scheduled to run on more than one RTSS processor.
• IRQ Affinity – You can specify a dedicated RTSS processor for processing the input and output of individual pieces of hardware.
• System Fault Handling – Real-time tasks survive over system crashes.

The runtime is available in several editions, allowing you to license as many processors as are necessary for your solution. The editions of the RTX product are:

All editions of the runtime include the same features. Applications that are created with the SDK will be able to run on any edition running the same version of RTX. This allows developers the freedom to develop applications that can be scalable.

The RTX product was released in 1995 to provide a real-time subsystem for Windows NT. RTX has continued to evolve, providing real-time support for all Microsoft professional operating systems. RTX 2016 supports multi-processors running 32-bit Windows 7 and Windows Embedded Standard 7.

The current version of RTX is RTX 2016 with Update 3, released in 2019.

RTX is used in a wide variety of products and vertical markets. Anyone designing an application that requires system control, determinism, or real-time performance on Windows can benefit from incorporating RTX into their product design.

RTX is used in some of the following markets:

• Industrial Automation
• Digital Audio
• Test & Measurement
• Medical
• Military Aerospace

IntervalZero provides six editions of the RTX 2016 Runtime product:

The RTX 2016 Runtime installations come in several varieties:

• RTX Install – RTX 2016 can be installed silently. The installation can be invoked from the command line or used within your own product installation so as not to require user interaction during the installation process. The RTX Installer can also be added as a Distribution Share component using the Windows Embedded Standard 7 Image Configuration Editor (ICE). The silent installation is licensed through an OEM/Site license and is also available as an evaluation version.
• Merge Modules for RTX Runtime Features – The RTX 2016 components are available as merge modules that can be included in the installation of an OEM product and is licensed through an OEM/Site license. A separate installation places merge modules on the system for your use. The merge modules are also available as an evaluation version.

For more information, see the RTX Deployment Guide.

The RTX Runtime comes with the following functionality:

• Extends the Windows HAL to support real-time control and isolation of interrupts
• Scheduler that schedules all RTSS threads ahead of Windows threads in a shared configuration, or across multiple cores in a dedicated configuration
• Support for communication between Windows applications and RTSS applications
• Support for communication between Windows kernel drivers and RTSS applications
• Networking support for socket level communication to and from RTSS processes
• A control panel that allows you to configure the RTX Subsystem
• The ability to display RTSS process output to a console window
• Command-line utilities to control the starting and stopping of RTSS applications
• Useful tools that display objects and perform application profiling
• Comprehensive Help files and User Guides

See the RTX vs RTX64 Comparison Guide, available from the Customer Center, for information on the differences between RTX and RTX64.

The RTX SDK comes with the RTX Runtime environment plus the following components:

• Header files and libraries
• Visual Studio Support
• Supported Versions:
• Visual Studio 2015
• Visual Studio 2013
• Microsoft C Runtime support
• Wizards
• Real-Time debugger
• Debugger Data Extension for Microsoft WinDbg
• Comprehensive Help files and MiniTutorials
• Source code sample to help explain more advance development topic

RTX components must be activated with a valid license before they can be used. You can use the RTX Activation and Configuration utility, which appears immediately after program installation, to activate and lock your product to a specific machine or to an IntervalZero-provided dongle. For information on first activation, see the RTX Install Guide for your product, or see the RTX Deployment Guide.

The method you use to activate your copy of RTX will depend on whether you are connected to the Internet. Videos are available that walk through the process of activating with an Internet connection, and activating without an Internet connection. You can watch the videos at https://www.intervalzero.com/en-resources/en-videos/.

RTX can run on systems with up to 32 processors.

• Systems with eight or fewer processors, which do not have hardware enforced processor clustering, can run with one to seven processors assigned to Windows and the remaining to RTX.
• Systems with more than eight processors (but not more than 32) or systems with eight or fewer processors which have hardware enforced processor clusters can run in Dedicated (Cluster) mode only. On these systems, a maximum of four processors can be assigned to Windows and up to 31 can be assigned to RTX.

You can assign available processors to Windows or RTX64 through the RTX64 Activation and Configuration utility. The RTX64 Activation utility automatically detects the total number of processors on your system. For more information, see the topic Configuring your System in the RTX Help.

RTX can be used on mobile processor systems. However, since mobile processors use Intel’s SpeedStep® technology to lower processor speed during Windows idle time to conserve energy, long latencies can occur when the processor becomes unavailable during the speed change. RTX can eliminate these possible latencies by not allowing processor speed change.

RTX can be used on hyper-threading systems. RTX treats the logical processor created by Intel Hyper-Threading as a separate processor, so you can configure RTX for either shared or dedicated multiprocessor support. Because both logical processors share the same physical processor, one logical processor can adversely affect the performance of the other. It is recommended that you evaluate RTX performance to ensure that when hyper-threading is enabled, your real-time requirements are still achieved.

RTX supports PAE for all versions of Windows that support PAE. Prior to RTX 2009 SP1, PAE was only supported on shared configurations. Since RTX relies on Windows to manage memory paging (the translation from virtual address to physical address), RTX cannot access the physical memory ranges for which Windows does not have page table entries. In order to push for 64-bit Windows, 32-bit Windows limits the main physical memory range up to 4GB, even when the system is booted with PAE enabled.

For more information, see the Microsoft article on PAE at http://technet.microsoft.com/en-us/library/cc736309.

Yes. Data Execution Prevention (DEP) is supported.

The RTX SDK includes a tool called Platform Evaluator that allows you to run a number of latency-measuring tests to determine how well platforms meet your real-time and control needs.

IntervalZero provides the option of a silent command line installation for RTX, which allows an OEM to wrap the RTX installation and hide it within another installation. The RTX 2016 Runtime components are also available as merge modules that can be included in the installation of an OEM product. Evaluation versions are also available.

IntervalZero provides a Properties API that can be used to programmatically configure the RTX Subsystem. This allows customers to set up their software’s subsystem requirements without requiring anything of their end users.

In Visual Studio, RTX provides remote debugging capabilities for RTSS applications with Visual Studio 2015 and Visual Studio 2013.

RTX also provides excellent flexibility for processing exceptions. You can configure RTX to handle exceptions with a structured exception handler; generate a debug break; or stop the process and dump memory.

A tracing API allows developers to create custom trace events that can be included in subsystem traces to help pinpoint problem areas.

RTX can be configured to add active RTSS process information to the Windows minidump file, which can then be analyzed with Microsoft WinDbg. The RTX Debugger Data Extension for WinDbg helps you discover the state of the RTSS and all active RTSS processes at the point of crash, either with live kernel debugging or from a full kernel dump of a customer’s system.

Yes. Once RTX has been successfully installed, all authenticated users who log on to the system can control, configure, and run the RTX Subsystem and RTSS applications, even if they are not computer or domain administrators. System administrators can control access to the RTX resources by configuring members of the RTXAdministrators and RTXUsers groups. For more information, see the RTX Install Guide.

RTX 2016 is binary compatible with RTX 2012 with Update 1 and above.

No. RTSS applications are developed with Microsoft Visual Studio. The RTX SDK provides wizards for easy project creation and templates to help you to get started. A Visual Studio Debugger add-in lets you debug RTSS applications in a familiar environment. RTX supports Visual Studio 2015 and Visual Studio 2013.

Because RTSS applications run in kernel mode, they can also be debugged with a kernel-level debugger such as Microsoft WinDbg. The RTX SDK includes an RTX Debugger Data Extension for WinDbg that allows you to view active RTSS processes and objects.

RTX supports a subset of over 50 Win32 API calls that make sense in a real-time environment.

In addition, RTX provides a large selection of real-time API calls that developers use to access the RTSS and system resources. This real-time API (RTAPI) is composed of a set of unique API calls and Win32-based API calls.

The unique real-time API calls are Win32 modeled calls that provide essential programming capabilities required for real-time applications, along with access to the RTSS and system resources. These unique RTAPI calls have no equivalent Win32 calls.

The Win32-based API calls that are supported by RTX are unlike the RTAPI in that there are similar functions in the Win32 environment; however, these calls require a different implementation than their Win32 counterparts to support the real-time requirements of the RTSS. All the Win32-based calls are compatible with Win32 programming interface semantics, making it easy for developers already familiar with the Windows Win32 API.

RTX was designed so that developers could design and develop applications as RTSS or Win32 applications. If built as Win32, developers can take advantage of features like user-mode memory protection and other third-party debugging tools specific to user mode applications. After an application is working as desired, recompile it as an RTSS application which runs in kernel mode with no code changes required.

Unlike other applications that run in kernel mode, RTSS applications support structured exception handling. RTX lets developers call structured exception handling functions such as try, catch, and throw within their RTSS application. For example, if an application references a NULL pointer, the application can handle the error by terminating or freezing the application that caused the fault without bringing down the system.

RTX supports a subset of Microsoft C Runtime calls that you can call from your RTSS application. RTX provides C Runtime Support for Visual Studio 2015 and Visual Studio 2013.

RTX 8.1 and later support “virtual” IPv4 addresses. You can assign up to 32 virtual IP addresses to a single NIC.

Yes. RTX supports and saves state information for AVX/AVX2 (YMM/YMM8), SSE (SSE/SSE2/SSE3/SSE4), and MMX registers, as long as the hardware supports it.

A kernel debugger is not necessary to debug an RTSS application. The RTX SDK includes Visual Studio debugger add-ins that let developers debug real-time or control applications that run in kernel mode from within the familiar Visual Studio development environment. The debugger add-ins for Visual Studio 2015 and Visual Studio 2013 also support remote debugging so developers can remotely debug an RTSS application on a target system that has special hardware requirements.

However, if you prefer using Microsoft’s WinDbg, the RTX SDK provides symbols to help with the debugging of your RTSS application, along with a Debugger Data Extension which allows users to view information about active RTSS processes, threads, and objects. Note that WinDbg cannot be used on dedicated configurations to break in and step through code.

The RTX SDK provides a tool called TimeView that lets you set up a system trace. These system traces time stamp and log a configurable set of system and process events, allowing developers to trace the behavior of their real-time application with minimal impact on their system’s real-time performance. The RTAPI also provides instrument tracing functionality within RTSS application.

The RTX SDK includes a complete API reference guide for all supported functions in addition to small code segments that explain more complex concepts.

The RTX SDK also provides source code for a number of sample applications, some of which are the RTX measurement tools. These samples can be compiled and run, and show important concepts and application interaction.

RTX provides a number of tools and APIs that help developers measure system response and timer latency:

• SRTM (System Response Timer Measurement) – A command-line application that measures timer latencies and displays results in reports and histograms.
• KSRTM (Kernel System Response Timer Measurement) – A driver and a Win32 utility that measures HAL-level timer latencies and displays results in reports and histograms.
• RTX Demo – A graphic version of SRTM that displays timer latencies.
• PerformanceView – A graphical utility that shows CPU utilization by real-time applications, Windows processes, and system idle time. PerformanceView also displays the maximum amount of time RTX has held the CPU on shared systems.
• ObjectViewer – A graphical utility that displays information for all active objects in the RTSS environment, including thread creation date/time and duration.
• Several APIs for profiling across processors, including the following:
  • RtGetThreadTimes retrieves the execution time of a given thread.
  • QueryPerformanceCounter and QueryPerformanceFrequency provide accurate time tracing between multiple processors.

RTX lets Win32 and RTSS applications communicate through a number of Inter-Process Communication (IPC) objects. Use the RTAPIs to create objects that can be viewed and used by Windows processes. Similar to Windows inter-process communication, RTSS and Windows applications create or open handles to named objects or memory regions, allowing simple and standard communication and synchronization between real-time (RTSS) and non-real-time (Windows) applications. Shared memory regions allow Windows and RTSS applications to view the same physical memory without passing additional messages or data between environments.

Standard objects:

• Event – The event object is a synchronization object. It is useful in sending a signal to a thread, indicating that a particular action has occurred.
• Mutex – The mutex object is a synchronization object whose state is signaled when it is not owned by any thread and not signaled when the mutex is owned by a thread. The mutex object arbitrates exclusive access to a shared resource.
• Semaphore – The semaphore object is a synchronization object that maintains a count between zero and a specified maximum value. The count is decreased by one each time a thread completes a wait for the semaphore object; the count is increased by a variable amount at the semaphore release. When the count reaches zero, the semaphore object’s state is no longer signaled and no more threads can complete a wait on the semaphore object until some thread increases the count.
• Shared Memory – The shared memory object is a region of non-paged physical memory that can be mapped into the virtual address space of a process. When a shared memory object has a name, additional processes may map the region of memory. A shared memory object is accessed with both a handle and a virtual address. In order for a process to completely end its access to a shared memory object it must close any open handles.

RTX provides a set of real-time Kernel API (RTKAPI) calls that allow Windows drivers to access RTX inter-process communication objects from within a Windows kernel device driver. These RTKAPI calls are analogous to their RTAPI counterparts. For example, RtkOpenSemaphore is analogous to RtOpenSemaphore.

The RTKAPI functions and the RTAPI functions are used in the same way, but RTKAPI functions are used exclusively in the Windows kernel environment.

RTX acquires the resources the device needs from the Windows Plug and Play Manager. To make this possible, a device’s driver must be updated to point to the RTX plug and play stub driver. After the device is controlled by RTX, the device’s resources must be updated to request a unique interrupt that is not already being used by Windows. (Sharing interrupts with Windows would cause determinism to be lost.) Once the device is set up, any RTSS application can access and use the device.

RTX 8.1 and later support MSI and MSI-X capable devices, providing an alternative to line-based interrupts. This functionality is available on all RTX supported operating systems.

Windows has a set of 32 priority levels, ranging from 0 – 31. They are further defined into 4 priority classes, of which the “real-time” priority class is the highest priority class.

The “real-time” priority class, in turn, has 7 levels within the class. RTX uses a flat priority scheme of 127 priority levels. When there are any RTX tasks or RTX threads that are ready to run, RTX will gain total control of the system resources, regardless of what priority level a Windows thread may be granted.

All RTX priorities are higher than the highest Windows priorities.

The one case where the Windows priority scheme is relative to the RTX scheme is when an RTX application is compiled as a Win32 application and not as a RTSS application. In this case, RTX priority levels are mapped to Windows priority levels. These mappings are fixed and designed to preserve relative ordering among thread priorities.

RTX provides the option to set one of three priority inversion protocols to handle cases where a higher priority thread is waiting on a mutex held by a lower priority thread:

• Priority Promotion with Tiered Demotion elevates a low priority thread to the level of the highest priority thread that is waiting for the shared mutex until it has released the mutex requested by a higher priority thread.
• Priority Promotion with Limited Demotion – Elevates a low priority thread to the level of the highest priority thread that is waiting for the shared mutex until it has released all mutexes that it owns
• Disable – Does not elevate priorities in cases where a higher priority thread is waiting on a mutex held by a lower priority thread.

RTX includes a real-time enabled Hardware Abstraction Layer (HAL) extension; this extension does not replace the existing Windows HAL. The extension maintains interrupt isolation between RTSS and Windows. Windows cannot mask (at the interrupt controller level) interrupts managed by RTSS. Windows interrupts are masked during RTSS processing. The real-time HAL extension supports high-resolution clocks and timers for RTSS, while it also supports non real-time clocks and timers for Windows. Other real-time HAL extension features include a software interrupt mechanism between RTSS and Windows, basic exception management, and enhancements for determinism. The HAL timer values can be changed via a predefined value table to as little as 1µs, or can be assigned a custom value using the SDK.

Windows STOPs, or Bug Checks, are the result of kernel level drivers or operating system components failing safety checks, bringing Windows to a controlled stop. These Windows STOPs are designed to keep data corruption to a minimum and help developers find out what went wrong.

Since the RTSS is able to continue running after Windows issues a STOP, developers can build safe shutdown handling into RTSS applications. RTX calls the shutdown handlers when Windows issues a STOP, allowing system real-time components to safely shut down. Once all shutdown handlers finish running, RTX lets the Windows shutdown process continue.

If the RTSS determines that Windows needs to be shut down, RTX issues a STOP, but instead of displaying the traditional Windows blue screen, RTX displays the RTX green screen, which contains information about the state of RTX at the time of the STOP.

No states are saved when Windows crashes.