Pseudo RT system idea

[PeterB]

Hi folks,

A little thought experiment. I'm thinking about ways to get RT behaviour from a multicore CPU using something akin to a hypervisor.

Lets say I have a Quad core CPU (oh, that's right I actually do..), anyway what if I could force the Operating system to only run on 2 of those cores and LabVIEW (not LV RT) run on the other two cores (perhaps under another O/S ?). This way LV wouldn't be interrupted by random O/S activity and would have closer RT behaviour.

All the RT targets available have slower CPU speeds than what is available on desktops at any given point in time, so being able to do something like this would provide me with a cheaper/fast pseudo RT system.

Waddya think ??

The NI-hypervisor only runs on NI RT platforms

rgds

Peter Badcock

Product Development

ResMed Ltd

[crelf]

Lets say I have a Quad core CPU (oh, that's right I actually do..), anyway what if I could force the Operating system to only run on 2 of those cores and LabVIEW (not LV RT) run on the other two cores (perhaps under another O/S ?). This way LV wouldn't be interrupted by random O/S activity and would have closer RT behaviour.

I like these sort of thought experiments. Yes, you'd need another OS for your LabVIEW code to run on, but I'm not sure how you'd boot it. Also, there's the shared hardware outside of the CPU that you'd need to consider (buses and memory and peripherals, oh my!) I'm not saying it couldn't be done, but it'd sure be fun to try... Perhaps there are already untilities out there that allow you to split the cores? How would you communicate between the LabVIEW RT-ish OS and the host? I guess if you have 2 network cards in there (one for each OS) and plugged in a cross-over cable?

[PeterB]

I like these sort of thought experiments. Yes, you'd need another OS for your LabVIEW code to run on, but I'm not sure how you'd boot it. Also, there's the shared hardware outside of the CPU that you'd need to consider (buses and memory and peripherals, oh my!) I'm not saying it couldn't be done, but it'd sure be fun to try... Perhaps there are already untilities out there that allow you to split the cores? How would you communicate between the LabVIEW RT-ish OS and the host? I guess if you have 2 network cards in there (one for each OS) and plugged in a cross-over cable?

Thanks for chiming in Chris. You raise many important details that would need solving. Guess what, I just did a quick search and there is a product which will fit the bill

Check out this RTS Real Time Embedded Hypervisor. The blurb says:

"

Deployment of multiple operating systems on multi-core processor platforms is a logical step in embedded systems design, thus reducing total hardware costs while increasing reliability and system performance.

"

Check out the picture showing how memory and a network is shared.

rgds

Peter Badcock

Product Development

ResMed Ltd

[crelf]

Guess what, I just did a quick search and there is a product which will fit the bill

I knew there had to be something out there that did this!

"...the boot sequence can be specified, and when desired, an operating system can be rebooted independently of the other(s). In order to facilitate communication between operating systems, the RTS solution also provides a configurable user-shared memory as well as a TCP/IP based virtual network driver."

That is uber-cool!

Check out this RTS Real Time Embedded Hypervisor.

Okay, so now the question becomes: what does NI's Hypervisor have that this one doesn't?

A lsightly-related question: I wonder if you can do something in parallel(ish) with virtual machines (I guess it depends on just what level of jitter you'll accept, and your reasons for having an RT system).

[CaseyW]

Hi All,

I can help with some of these questions, as I manage the Real-Time Hypervisor product for NI.

In theory, you could potentially use a variety of bare-metal hypervisors (hypervisors that don't depend on a host OS) to run LabVIEW Real-Time and another OS in parallel. However, this may take substantial integration work on your part.

You could also try to use hosted virtualization software such as VMWare Workstation on top of Windows to run LabVIEW Real-Time, although it would not perform deterministically in this case and you may run into compatibility issues with the emulated Ethernet devices, etc. I/O will also be limited to USB/Serial/Ethernet in most cases.

When creating the Real-Time Hypervisor, NI used a low-level hypervisor similar to the one that was mentioned in a previous post (called VirtualLogix VLX). Work was done on top of this low-level component to:

- Make dynamically partitioning I/O devices and RAM easy through a graphical utility called the Real-Time Hypervisor Manager

- Support soft-rebooting LabVIEW Real-Time without rebooting Windows XP (I/O devices also must intelligently reset in this case)

- Expose virtual Ethernet and Virtual Console (COM) connections between OSs

- Host the hard drive under Windows XP, and allow LabVIEW Real-Time to access files through the hypervisor on an independent partition

- More...

Therefore, the short story is that although using a bare-metal hypervisor to set up a system that boots LabVIEW Real-Time and other OSs in parallel is very much possible, you can probably expect some integration work (not an out-of-box experience). The Real-Time Hypervisor aims to help users avoid this work, as systems are shipped preconfigured and graphical utilities ease any adjustments that customers would like to make.

You are correct, however, that the Real-Time Hypervisor does not yet support 3rd party PCs. Because virtualization is closely tied to system hardware, we have thus far prioritized development on NI hardware platforms that we closely control (known interrupt line configurations, components, etc). However, we are looking at what it would take to support generic PCs in the future.

Please let me know if you have any questions, and have a great week everyone!

Best Regards,

Casey Weltzin

Product Manager, LabVIEW Real-Time

National Instruments

[PeterB]

Casey,

Thanks for your valuable feedback.

regards

Peter Badcock

Product Development

ResMed Ltd

[crelf]

I can help with some of these questions, as I manage the Real-Time Hypervisor product for NI.

Excellent summary Casey - thanks for getting back to us!

[hooovahh]

I haven't quite figured out what RTX is but it seems to be similar, where Windows and RT reside on the same machine.

[crelf]

I haven't quite figured out what RTX is but it seems to be similar, where Windows and RT reside on the same machine.

LabVIEW RT used to come in two flavours: ETS (the way it is now - RT running on a target) and ETS (the method you linked to above).

[Mark Smith]

LabVIEW RT used to come in two flavours: ETS (the way it is now - RT running on a target) and ETS (the method you linked to above).

But they were really hard to tell apart.... ?

Mark

[CaseyW]

Hi All,

I can comment on how RTX fits in to this discussion.

There are a few different companies that provide solutions called "real-time subsystems" that can also be used to run real-time and general-purpose applications on the same computer hardware. The caveats are that I/O can be limited with these solutions (often different drivers are needed due to the change in HAL), and there is more room for any application problems to have a serious impact on the entire system (RT code runs in kernel mode). From a thousand-foot view, real-time subsystems basically modify interrupt service routines to run some real-time code alongside a general-purpose OS (e.g. Windows).

National Instruments released a product based on RTX (one of these real-time subsystems) previously, but I/O support was limited to a few types of boards as mentioned above. This is one of the reason that LabVIEW Real-Time for RTX (the NI product name) is no longer actively sold.

Virtualization is another technology for doing the same thing (running an RTOS in parallel with a general-purpose OS), but it provides a few advantages. With the right configuration, virtualization software can enable OSs to natively access I/O, which means that special drivers don't need to be developed. In addition,there is typically isolation between real-time and general-purpose applications. The bottom line is that virtualization is a very good technology for building multi-OS systems. The NI Real-Time Hypervisor is based on this technology.

Please let me know if I can help answer any additional questions, and have a great day all!

Best Regards,

Casey Weltzin

Product Manager, LabVIEW Real-Time

National Instruments

casey.weltzin@ni.com