In article <p7bq8499sq6assv1je1ok64oal8muavbh4@4ax.com>,
Jack Klein <jackklein@spamcop.net> wrote:
> 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.
I have to ask: Why even have Windows-anything in the picture? There
are lots of one-box Linux cum realtime approaches available, and a
two-box solution (QNX in one, vanilla Linux in the other, enet between)
would be dead simple, and either approach would be far more stable than
Windows, both immediately, and also in avoidance of the Windows Upgrade
Treadmill.
If (as others have suggested) you use industrial-grade hardware, the
treadmill will churn far slower than with consumer PCs as well.
Joe Gwinn
Reply by Paul Keinanen●July 28, 20082008-07-28
On Sun, 27 Jul 2008 21:31:02 -0500, Jack Klein <jackklein@spamcop.net>
wrote:
>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.
That requirement sounds that you should use more than two computers
(or at least several XP systems in VMware etc.). Keep the QNX system
on a separate hardware and the VM system on a different hardware.
It would be natural to keep the general XP specific part on one VM and
the country and hospital specific part on the other XP VM. It is quite
likely that the hospital side may be updated at some time different
for the update time of the rest of the imaging system.
By the way, for how long are you required to provide spare parts and
support for your system, one year, three years or ten years or more ?
This will also dictate what kind of hardware to use and how to
partition the functionality into different (real or virtual) boxes.
Paul
Reply by Paul Keinanen●July 28, 20082008-07-28
On Sun, 27 Jul 2008 23:12:35 -0500, 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.
Sure it is, but my guess is that the computer box cost is
insignificant compared to the total life cycle costs of the OP's
system.
My experience with passive backplanes is from the days of ordinary PCI
backplanes, the PCI Express may have complicated things.
Paul
Reply by Paul Keinanen●July 28, 20082008-07-28
On Sun, 27 Jul 2008 21:31:02 -0500, Jack Klein <jackklein@spamcop.net>
wrote:
>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.
Is this ordinary Win XP or Win XP Embedded ? If XP, I would be quite
concerned with the remaining life cycle for XP, the Win XXX Embedded
versions have had at least in the past a longer life cycle (e.g. no
W2k Embedded, so NT4 Embedded lived for quite a long time).
>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.
I do not know about the processing power requirement for your QNX
system, but usually the x86 embedded boards have a much longer life
cycle then ordinary desk top boxes. However, the RoHS requirements may
prematurely terminate the production of some older non-RoHS boards due
to lack of non-RoHS components.
For the user interface box, you are still going to have to replace the
box due to the increasing resource requirements of future Windows
operating systems.
>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.
At least for the QNX box, you should be able to extend the life cycle
and thus reduce the requalification costs, with suitable choice of
hardware, especially if you do not need the absolute top performance
for the application.
>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.
When there are some severe realtime requirements for a system running
a general purpose OS (Such as Windows or Linux), the usual practice is
to use a real time extension, which in practice is a RT-kernel running
the RT application and then running the general purpose
(Windows/Linux) OS as the null/idle task in the RT-kernel, using the
unused CPU would have otherwise been used by the idle loop.
>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.
Do you absolutely need the newest hardware for performance issues or
due to end of production for the older card ?
Paul
Reply by Guy Macon●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/>
Reply by Steve Watt●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 AZ Nomad●July 28, 20082008-07-28
On Mon, 28 Jul 2008 06:46:50 +0300, Paul Keinanen <keinanen@sci.fi> 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 Paul Keinanen●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 AZ Nomad●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 Jack Klein●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