Jump to content

Pseudo RT system idea


PeterB

Recommended Posts

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

Link to comment
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?

Link to comment

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 :thumbup1:

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

Link to comment
Guess what, I just did a quick search and there is a product which will fit the bill thumbup1.gif

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!

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).

Link to comment

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

Link to comment

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

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.