On Thu, 24 Jul 2008 11:31:49 +0200, Dombo <d...@disposable.invalid> wrote:
>AZ Nomad schreef:
>> On Wed, 23 Jul 2008 17:17:11 +0200, Dombo <d...@disposable.invalid> wrote:
>>> AZ Nomad schreef:
>>>> On Wed, 23 Jul 2008 15:12:30 +0200, Dombo <d...@disposable.invalid> wrote:
>>>>> AZ Nomad schreef:
>>>>>> On Tue, 22 Jul 2008 22:07:49 -0500, Jack Klein <j...@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.

AZ Nomad schreef:
> On Thu, 24 Jul 2008 11:31:49 +0200, Dombo <d...@disposable.invalid> wrote:
>> AZ Nomad schreef:
>>> On Wed, 23 Jul 2008 17:17:11 +0200, Dombo <d...@disposable.invalid> wrote:
>>>> AZ Nomad schreef:
>>>>> On Wed, 23 Jul 2008 15:12:30 +0200, Dombo <d...@disposable.invalid> wrote:
>>>>>> AZ Nomad schreef:
>>>>>>> On Tue, 22 Jul 2008 22:07:49 -0500, Jack Klein <j...@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.

Jack Klein <j...@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

On Wed, 23 Jul 2008, Dombo wrote:

|--------------------------------------------------------------------------------|
|"> On Tue, 22 Jul 2008 22:07:49 -0500, Jack Klein <j...@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?

On Sun, 27 Jul 2008 12:12:45 +0100, Colin Paul Gloster
<C...@ACM.org> wrote in comp.realtime:

> On Wed, 23 Jul 2008, Dombo wrote:
> 
> |--------------------------------------------------------------------------------|
> |"> On Tue, 22 Jul 2008 22:07:49 -0500, Jack Klein <j...@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

On Sun, 27 Jul 2008 21:31:02 -0500, Jack Klein <j...@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?

On Sun, 27 Jul 2008 22:00:42 -0500, AZ Nomad
<a...@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

On Mon, 28 Jul 2008 06:46:50 +0300, Paul Keinanen <k...@sci.fi> wrote:
>On Sun, 27 Jul 2008 22:00:42 -0500, AZ Nomad
><a...@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.

In article <s...@ip70-176-155-130.ph.ph.cox.net>,
AZ Nomad  <a...@PremoveOBthisOX.COM> wrote:
>On Mon, 28 Jul 2008 06:46:50 +0300, Paul Keinanen <k...@sci.fi> wrote:
>>On Sun, 27 Jul 2008 22:00:42 -0500, AZ Nomad
>><a...@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...

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/>;