On Thu, 24 Jul 2008 11:31:49 +0200, Dombo <dombo@disposable.invalid> wrote:>AZ Nomad schreef: >> On Wed, 23 Jul 2008 17:17:11 +0200, Dombo <dombo@disposable.invalid> wrote: >>> AZ Nomad schreef: >>>> On Wed, 23 Jul 2008 15:12:30 +0200, Dombo <dombo@disposable.invalid> wrote: >>>>> AZ Nomad schreef: >>>>>> On Tue, 22 Jul 2008 22:07:49 -0500, Jack Klein <jackklein@spamcop.net> wrote: >>>>>>> I'm looking for any suggestions, and especially any real experiences, >>>>>>> that anyone cares to offer. >>>>>>> We have a system that includes an x86 box running QNX 6.something. It >>>>>>> has the following interfaces: >>>>>> ... >>>>>> check out QEMU, and also do a google search for "qnx qemu" >>>>> I'm not sure how well the QEMU solution would meet the 'real time >>>>> performance' the OP mentioned. Also QEMU is quite slow since it emulates >>>>> the processor as well. >>>> Only I/O is emulated. Programs run natively until they need to do I/O. >>>> Drivers are installed into the guest OS in order to provide native performance >>>> for I/O as well. It is the same with vmware. >> >>> Apparently you are talking about a different QEMU than I am, unless you >>> were talking about KQEMU. >> >> I've used QEMU ahd it doesn't do processor virtualization. For the most part >> the guest OS runs at native speeds espcially after a driver is installed >> into the guest OS.>I've used QEMU (without the KQEMU driver) on a Windows PC, and it did >surely did emulate the processor (just like the author of this software >claims, check the website).With the KQEMU driver, the only sane way of using QEMU when both the host and guest OS are X86, QEMU virtualizes, not emulates. From the QEMU website: When used as a machine emulator, QEMU can run OSes and programs made for one machine (e.g. an ARM board) on a different machine (e.g. your own PC). By using dynamic translation, it achieves very good performances. When used as a virtualizer, QEMU achieves near native performances by executing the guest code directly on the host CPU. A host driver called the QEMU accelerator (also known as KQEMU) is needed in this case. The virtualizer mode requires that both the host and guest machine use x86 compatible processors.
Virtualizing QNX 6.0
Started by ●July 23, 2008
Reply by ●July 24, 20082008-07-24
Reply by ●July 24, 20082008-07-24
AZ Nomad schreef:> On Thu, 24 Jul 2008 11:31:49 +0200, Dombo <dombo@disposable.invalid> wrote: >> AZ Nomad schreef: >>> On Wed, 23 Jul 2008 17:17:11 +0200, Dombo <dombo@disposable.invalid> wrote: >>>> AZ Nomad schreef: >>>>> On Wed, 23 Jul 2008 15:12:30 +0200, Dombo <dombo@disposable.invalid> wrote: >>>>>> AZ Nomad schreef: >>>>>>> On Tue, 22 Jul 2008 22:07:49 -0500, Jack Klein <jackklein@spamcop.net> wrote: >>>>>>>> I'm looking for any suggestions, and especially any real experiences, >>>>>>>> that anyone cares to offer. >>>>>>>> We have a system that includes an x86 box running QNX 6.something. It >>>>>>>> has the following interfaces: >>>>>>> ... >>>>>>> check out QEMU, and also do a google search for "qnx qemu" >>>>>> I'm not sure how well the QEMU solution would meet the 'real time >>>>>> performance' the OP mentioned. Also QEMU is quite slow since it emulates >>>>>> the processor as well. >>>>> Only I/O is emulated. Programs run natively until they need to do I/O. >>>>> Drivers are installed into the guest OS in order to provide native performance >>>>> for I/O as well. It is the same with vmware. >>>> Apparently you are talking about a different QEMU than I am, unless you >>>> were talking about KQEMU. >>> I've used QEMU ahd it doesn't do processor virtualization. For the most part >>> the guest OS runs at native speeds espcially after a driver is installed >>> into the guest OS. > >> I've used QEMU (without the KQEMU driver) on a Windows PC, and it did >> surely did emulate the processor (just like the author of this software >> claims, check the website). > > With the KQEMU driver, the only sane way of using QEMU when both the > host and guest OS are X86, QEMU virtualizes, not emulates.QEMU without the KQEMU driver is a very handy if you need a VM but don't want to install something on the system and/or don't have administrative privileges. E.g. one can run a (lightweight) Linux distro from a USB stick in a window without rebooting and without changing a single thing to the system.
Reply by ●July 24, 20082008-07-24
Jack Klein <jackklein@spamcop.net> writes:> I'm looking for any suggestions, and especially any real experiences, > that anyone cares to offer....> We are looking at the possibility of moving the QNX system and > application into a virtual machine on the workstation, which will be a > quad core, dedicating one core to QNX....> They say VMware would work, but it is more expensive than they would > like.VMware Server is free, no? (I've run the QNX desktop GUI [Neutrino?] under VMware and it behaved quite OK even on single-core hardware.) VirtualBox (now free from Sun) apparently plays nicer with some peripherals (particularly some USB devices) than VMware does. I've just started to play with it and it looks OK. mlp
Reply by ●July 27, 20082008-07-27
On Wed, 23 Jul 2008, Dombo wrote: |--------------------------------------------------------------------------------| |"> On Tue, 22 Jul 2008 22:07:49 -0500, Jack Klein <jackklein@spamcop.net> wrote:| |> > I'm looking for any suggestions, and especially any real experiences, | |> > that anyone cares to offer. | |> | |> > We have a system that includes an x86 box running QNX 6.something. It | |[..] | | | |I'm not sure how well the QEMU solution would meet the 'real time performance' | |the OP mentioned. Also QEMU is quite slow since it emulates the processor as | |well. | | | |Though there are plenty of VM's (Virtual PC, VirtualBox, VMWare), I think it is | |unlikely one will find a VM that allows guests OS'es to provide hard real time | |guarantees while running in that VM. | | | |Unfortunately the OP wasn't specific about the real time deadlines that had to | |be met, or the host OS." | |--------------------------------------------------------------------------------| I have not used QNX in QEMU, but I have noticed that the throughput of a simulated operating system in QEMU can be impressively high (depending on what is being done) if the host operating system does not need to use virtual memory for the simulation (i.e. if the simulation can be kept within the host computer's main memory). The high throughput is still accompanied by QEMU's high latency however. I was not trying to access any external hardware, which may make this to be a less useful example for Jack. I do not know why the people Jack mentioned no longer want a perfectly functioning QNX native installation. I used to study with someone whose master's thesis was about a Windows system he developed by porting a QNX application which he did not develop to Windows. Why do people do these things?
Reply by ●July 27, 20082008-07-27
On Sun, 27 Jul 2008 12:12:45 +0100, Colin Paul Gloster <Colin_Paul_Gloster@ACM.org> wrote in comp.realtime:> On Wed, 23 Jul 2008, Dombo wrote: > > |--------------------------------------------------------------------------------| > |"> On Tue, 22 Jul 2008 22:07:49 -0500, Jack Klein <jackklein@spamcop.net> wrote:| > |> > I'm looking for any suggestions, and especially any real experiences, | > |> > that anyone cares to offer. | > |> | > |> > We have a system that includes an x86 box running QNX 6.something. It | > |[..] | > | | > |I'm not sure how well the QEMU solution would meet the 'real time performance' | > |the OP mentioned. Also QEMU is quite slow since it emulates the processor as | > |well. | > | | > |Though there are plenty of VM's (Virtual PC, VirtualBox, VMWare), I think it is | > |unlikely one will find a VM that allows guests OS'es to provide hard real time | > |guarantees while running in that VM. | > | | > |Unfortunately the OP wasn't specific about the real time deadlines that had to | > |be met, or the host OS." | > |--------------------------------------------------------------------------------| > > I have not used QNX in QEMU, but I have noticed that the throughput of > a simulated operating system in QEMU can be impressively high > (depending on what is being done) if the host operating system does > not need to use virtual memory for the simulation (i.e. if the > simulation can be kept within the host computer's main memory). The > high throughput is still accompanied by QEMU's high latency however. I > was not trying to access any external hardware, which may make this to > be a less useful example for Jack. > > I do not know why the people Jack mentioned no longer want a perfectly > functioning QNX native installation. I used to study with someone > whose master's thesis was about a Windows system he developed by > porting a QNX application which he did not develop to Windows. Why do > people do these things?Since you asked, I will be happy to reply. Right now, the product (a medical imaging device) must ship with at least two x86 computers. One, the image acquisition computer, runs QNX 6.something. The other, which is the user workstation and interface to the hospital/clinic network, DICOM translator, image processor, archive, etc., runs under Windows XP. Having two computers instead of one is an expense in and of itself. Beyond this, it is a maintenance headache. Any particular x86 box these days is not available for a great length of time. By the time we are shipping a particular new computer, its end of life is already announced and we are qualifying and validating the next one. Seeing as how this is a medical device, which is a highly regulated industry by the FDA in the US and corresponding agencies in other countries and regions of the world, the overhead of testing and documenting any change in hardware is quite substantial. Right now we are continuously validating not one, but two different replacement computers at any give time, for two different sets of operating systems and applications. If we can successfully run QNX and the application on a VM under XP, there is now only one computer to validate for hardware updates. The other great savings potential is simply the fact that new x86 hardware (motherboards, BIOS, network cards, etc.) always ship with Windows driver support. It is not always so easy or quick to have or get QNX drivers for the latest, newest hardware. At least some VM implementations virtualize hardware interfaces such as NIC, serials ports, USB controllers, so they look generic to the guest OS. That can also save some headaches. -- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://c-faq.com/ comp.lang.c++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c++ http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
Reply by ●July 28, 20082008-07-28
On Sun, 27 Jul 2008 21:31:02 -0500, Jack Klein <jackklein@spamcop.net> wrote:>If we can successfully run QNX and the application on a VM under XP, >there is now only one computer to validate for hardware updates.If at all possible, you should have XP in the VM. A RTOS in a VM on a pig like XP will have the same lockups that every XP process is prone. Baring that, why not just have two PC's sitting side by side? How tightly coupled are the operating systems in the final application? How do they interface?
Reply by ●July 28, 20082008-07-28
On Sun, 27 Jul 2008 22:00:42 -0500, AZ Nomad <aznomad.3@PremoveOBthisOX.COM> wrote:> >Baring that, why not just have two PC's sitting side by side? How >tightly coupled are the operating systems in the final application? >How do they interface?There are (or at least have been) rack mountable boxes available with two separate passive backplanes with separate power supplies. Add just a KVM switch and the system looks just like a "single computer" as the customer wanted. Of course you can run different operating systems or even different processors on the two backplanes. Paul
Reply by ●July 28, 20082008-07-28
On Mon, 28 Jul 2008 06:46:50 +0300, Paul Keinanen <keinanen@sci.fi> wrote:>On Sun, 27 Jul 2008 22:00:42 -0500, AZ Nomad ><aznomad.3@PremoveOBthisOX.COM> wrote:>> >>Baring that, why not just have two PC's sitting side by side? How >>tightly coupled are the operating systems in the final application? >>How do they interface?>There are (or at least have been) rack mountable boxes available with >two separate passive backplanes with separate power supplies. Add just >a KVM switch and the system looks just like a "single computer" as the >customer wanted. Of course you can run different operating systems or >even different processors on the two backplanes.I bet they cost a heck of a lot more than two PC's.
Reply by ●July 28, 20082008-07-28
In article <slrng8qhpj.cq7.aznomad.3@ip70-176-155-130.ph.ph.cox.net>, AZ Nomad <aznomad.3@PremoveOBthisOX.COM> wrote:>On Mon, 28 Jul 2008 06:46:50 +0300, Paul Keinanen <keinanen@sci.fi> wrote: >>On Sun, 27 Jul 2008 22:00:42 -0500, AZ Nomad >><aznomad.3@PremoveOBthisOX.COM> wrote: > >>>Baring that, why not just have two PC's sitting side by side? How >>>tightly coupled are the operating systems in the final application? >>>How do they interface? > >>There are (or at least have been) rack mountable boxes available with >>two separate passive backplanes with separate power supplies. Add just >>a KVM switch and the system looks just like a "single computer" as the >>customer wanted. Of course you can run different operating systems or >>even different processors on the two backplanes. > >I bet they cost a heck of a lot more than two PC's.Yes, but they'll be stable and avaialable for 10 years. The industrial computer market is much better behaved, in terms of deployments, than the consumer market. I'll third (fourth, fifth) the votes to have XP be the virtualized OS underneath something else. There are very probably good reasons the original designers are using QNX, most likely having to do with the fact that it's a real-time system. XP simply can not provide real-time guarantees. Oh, and it's increasingly hard to get XP, too. Depending on exactly how Windows-dependent the user interface code is, it could probably be ported to run on QNX. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3" Internet: steve @ Watt.COM Whois: SW32-ARIN Free time? There's no such thing. It just comes in varying prices...
Reply by ●July 28, 20082008-07-28
Paul Keinanen wrote:> >AZ Nomad wrote: > >>Baring that, why not just have two PC's sitting side by side? How >>tightly coupled are the operating systems in the final application? >>How do they interface? > >There are (or at least have been) rack mountable boxes available with >two separate passive backplanes with separate power supplies. Add just >a KVM switch and the system looks just like a "single computer" as the >customer wanted. Of course you can run different operating systems or >even different processors on the two backplanes.And, if he buys server-class rather than consumer-class PCs, his "By the time we are shipping a particular new computer, its end of life is already announced and we are qualifying and validating the next one" problem will go away. -- Guy Macon <http://www.GuyMacon.com/>
