Real time process priority on Windows

[divisionbyzero]

Running Labview 2012 SP1, up to date as of today.

I'm writing a timed program. The program needs to be precise to at least ms resolution, perhaps with microsecond resolution in the future. It would be great to avoid the additional costs of running a realtime deployment. From what I read, microsecond resolution requires a real time setup, which has a computer dedicated to running the real time program. This is because Windows is a protected-mode operating system. However, in Windows XP, 7, etc there is an option in the task manager to elevate a process from normal priority to realtime priority. Therefore I have two questions:

1) Has anyone ever tried running a program in realtime priority to get microsecond resolution on a Windows machine?

2) Has anyone set up realtime in a virtual machine running on Windows? We have VmWare Workstation v9 and a Dell Optiplex 745 (Intel Core 2 Duo). I'm quite accustomed to running virtual machines on various hardware. This wouldn't avoid any of the licensing costs but would at least avoid the cost of another machine.

From what I understand this may cause Windows to crash whenever there is an error in the realtime process. And perhaps Labview the Create 1MHz Timer vi wouldn't run if it's being executed in Windows anyhow, so question 1 would be moot. But nevertheless...

[Simon-P]

Greetings;

Sure, I have personally heightened priorities in Windows to ensure an operation that it closer to Real-Time. However, since Windows works via Preemptive Multitasking, the OS can take control of the processor at any instant. While a Real-Time process (as set in windows) cannot take interrupts (and may thus lead to starvation), that will merely increase your applications determinism but not make it the same as you would get in a Real Time OS. 

Additionally, you might be able to ensure that the process seizes the processor, but not that the program itself will start at a particular time.

And in what concerns setting up a Virtual Machine within Windows, that might allow you to run a "Real-Time" application, but due to the inherent workings of Winodws, it will not be Real-Time. 

The following discussion goes over MHz timing and Windows timing and might be of interest:

https://forums.ni.com/t5/LabVIEW/1MHz-Software-Timing/td-p/1858287

Anyhow, I wish you a great day!

Cordially;

Simon P.

[divisionbyzero]

Hi Simon, thanks for the reply. This link is quite informative.

How is system stability affected by elevating Labview to a realtime priority? Specifically, does a Labview crash also crash the OS? Which version of Windows did you try this on? Was it 32-bit or 64-bit? If you've tried both bits, did one keep more accurate time than the other?

As far as I understand, so long as your hardware supports hardware virtualization (namely the high precision timer in amd64 systems) then virtual machines hosted in VmWare Workstation 8 or later will keep accurate timing, though the precise definition of "accurate" is unknown. Versions before that, or running it without access to high precision timer virtualization resulted in the VMs operating system keeping terrible system time. Presumably this is from it hopping in and out of the process queue in an asynchronous manner, such as what Windows does with all process, and the rounding errors in the timing as it does this propagate to a large magnitude quickly. I've not quantifiably compared the high timing accuracy in workstation with running in a dedicated ESXi 4 or 5 server. However it seems intuitive that the higher accuracy results from giving the guest OS access to the hardware timer instead of a software timer subject to the whims of Windows' asynchronicity, and so more accurate timing could be gained from running a realtime VM. But is a realtime VM running in VmWare Workstation 8 or above with the proper harware virtualization support going to actually yield realtime timing? That's the core of the question I think. If anyone has tried this, please share your experiences. Our production machine that must run this has the harware virtualization to support it but only 2 GB RAM. I may be able to scrape some more RAM together but trying this myself will certainly not be immediately possible.

[Simon-P]

Greetings;

I personally have tinkered with the priority in Windows 7, 32 Bit. However, system stability does become somewhat problematic but not more or less than any other program being elevated to RealTime. Particularly because LabVIEW may use more than one core which, when set to real time, leads to starvation. I do not know, however, whether a LabVIEW crash would crash the OS as well in this case, as it didn't quite happen to me. It bears mentioning that all I am discussing here has been my own testing on my spare time more than any internal knowledge, however.

Still, LabVIEW tends to be pretty "fair" in what concerns sharing resources, so it might still relinquish control to another process.

The core of the question is indeed whether a VM with proper virtualization will lead to real-time timing in an RT OS, and the answer to that is "possibly". Virtual Machines can be either Hosted or Bare Metal, which I believe is what you are refering to when discussing the hardware timer. As such, if Vmware does allow for a bare-metal virtualization, then you will likely get Real-Time Operation when running a Real-Time OS. 

We have, for example, the Real-Time Hypevisor system as the supported solution to this issue, which does something similar to what you are describing in that it allows you to run both a host OS as well as a true RT side on the same computer (PXI); it does so via this bare-metal synchronization.

But I do not know the inner workings of VmWare Workstation to be able to say that you will be able to completely dissociate Windows and the RT OS, that is to say, whether VmWare allows for true bare-metal virtualization.

Cordially;

Simon P.