Any ideas anyone?
“Dmitri Ivanov” <ivdal@yahoo.com> wrote in message
news:an0uiv$a4e$1@inn.qnx.com…
Any ideas anyone?
Depends on where are you going. And how fast you wanna be there.
// wbr
Depends on where are you going. And how fast you wanna be there.
Well, i’ve been using QNX4 for several years. Now i’m wondering
should i switch to QNX6.2 or maybe some other OS like
Solaris or RTLinux. Or maybe i better stick to QNX4.
QNX4 is great but it is not supported by QSSL anymore.
I need a reliable realtime operating system for x86.
I know that Solaris has limited RT support but that’s all i know.
Has anyone compared QNX vs Solaris? And how much does
Solaris cost?
Dmitri Ivanov <ivdal@yahoo.com> wrote:
Any ideas anyone?
If you want to run on Sparc, run Solaris.
If you want to run on x86, read this:
http://news.com.com/2100-1001-803719.html?legacy=cnet&tag=prntfr
Dmitri Ivanov wrote:
Well, i’ve been using QNX4 for several years. Now i’m wondering
should i switch to QNX6.2 or maybe some other OS like
Solaris or RTLinux. Or maybe i better stick to QNX4.
QNX4 is great but it is not supported by QSSL anymore.
I need a reliable realtime operating system for x86.
I know that Solaris has limited RT support but that’s all i know.
Has anyone compared QNX vs Solaris? And how much does
Solaris cost?
Solaris is not a hard realtime O/S. RTLinux provides a very crude
programming environment. If you want to do a comparison with something
that is at least in the same ball-park as QNX (wrt real-time api and
performance), you should probably look at VxWorks.
If you are doing soft real-time then Sl^Holaris may fit the bill.
Nobody has compared QNX to Solaris because they aren’t in the same
ballpark (hard real-time OS).
I have no idea what Solaris costs.
That is old news David. Sun has apparently reversed their decision to
ditch x86 platform. There’s been numerous reports back in august that
Solaris9 will be released for x86 after all.
However, there is some truth in the opinion that Solaris makes more
sense on SPARC. Some really high-end advanced features are only
implemented on SPARC (dynamic domain reconfiguration, CPU hot swap, etc).
– igor
David Donohoe wrote:
Dmitri Ivanov <> ivdal@yahoo.com> > wrote:
Any ideas anyone?
If you want to run on Sparc, run Solaris.If you want to run on x86, read this:
http://news.com.com/2100-1001-803719.html?legacy=cnet&tag=prntfr
Rennie Allen wrote:
Dmitri Ivanov wrote:
Well, i’ve been using QNX4 for several years. Now i’m wondering
should i switch to QNX6.2 or maybe some other OS like
Solaris or RTLinux. Or maybe i better stick to QNX4.
QNX4 is great but it is not supported by QSSL anymore.
I need a reliable realtime operating system for x86.
I know that Solaris has limited RT support but that’s all i know.
Has anyone compared QNX vs Solaris? And how much does
Solaris cost?
Solaris is not a hard realtime O/S. RTLinux provides a very crude
programming environment. If you want to do a comparison with something
that is at least in the same ball-park as QNX (wrt real-time api and
performance), you should probably look at VxWorks.If you are doing soft real-time then Sl^Holaris may fit the bill.
People like to mock Solaris for slowness, but that is most of the time
due to lack of knowledge. Speed is not the strength of Solaris indeed.
But capacity is. Try to run 1,000,000 processes on Linux, you will see.
Solaris has certain realtime features. Depending on how hard your
requirement are, they may or may not be sufficient. Most important
attributes that allow Solaris to be used in some realtime systems include:
- fully preemptable kernel;
- nested interrupts and schedulable interrupt handlers;
- realtime scheduling class (128 levels I believe);
- proper implementation of POSIX realtime extensions API (threads, IPC,
synchronisation);
Applications in realtime class have absolute notion of priority. They
have higher priority than kernel and will preempt kernel. Other
applicatuions have adjustable priorities below kernel.
The biggest issue with hard realtime is probably the nature of drivers’
framework. SVR4-based systems use STREAMS and certain semantics of it
(scheduling of STREAMS modules) may conflict with realtime requirements.
Nobody has compared QNX to Solaris because they aren’t in the same
ballpark (hard real-time OS).
Nobody? That’s my middle name I suppose…
I have no idea what Solaris costs.
It depends on type of use and volume. I believe single commercial
license runs about $700 (development tools are extra, but GNU tools can
be used). Non-commercial can be downloaded for free. Full source is
available including kernel (you need to register and fax them EULA).
We use both Solaris & QNX in our project.
– igor
Solaris has certain realtime features. Depending on how hard your
Yes, I’ve read ‘Real-time Programming and Administration’ chapter
in Solaris docs. I’m curious how does it feel in real life?
requirement are, they may or may not be sufficient. Most important
attributes that allow Solaris to be used in some realtime systems include:
- fully preemptable kernel;
- nested interrupts and schedulable interrupt handlers;
- realtime scheduling class (128 levels I believe);
- proper implementation of POSIX realtime extensions API (threads, IPC,
synchronisation);
I couldn’t find any figures about how big interrupt latency,
dispatch latency …etc. are with x86. They only give some
figures for SPARCs. Perhaps i just didn’t know where
to look - i haven’t spent much time with Solaris docs yet.
Applications in realtime class have absolute notion of priority. They
have higher priority than kernel and will preempt kernel. Other
applicatuions have adjustable priorities below kernel.
The biggest issue with hard realtime is probably the nature of drivers’
framework. SVR4-based systems use STREAMS and certain semantics of it
(scheduling of STREAMS modules) may conflict with realtime requirements.Nobody has compared QNX to Solaris because they aren’t in the same
ballpark (hard real-time OS).Nobody? That’s my middle name I suppose…
I have no idea what Solaris costs.It depends on type of use and volume. I believe single commercial
license runs about $700
Is it charged per-installation?
(development tools are extra, but GNU tools can
be used).
I’ll stick with GNU tools, i guess
Non-commercial can be downloaded for free. Full source is
available including kernel
I like it!
We use both Solaris & QNX in our project.
Ok, which one is best?
If you want to run on Sparc, run Solaris.
If you want to run on x86, read this:
http://news.com.com/2100-1001-803719.html?legacy=cnet&tag=prntfr
Thanks. But i really think Solaris 8 will do fine for now.
Dmitri Ivanov wrote:
Solaris has certain realtime features. Depending on how hard your
Yes, I’ve read ‘Real-time Programming and Administration’ chapter
in Solaris docs. I’m curious how does it feel in real life?
In real life it feels like very solid an reliable OS. Never ever
crashes. I mean I have yet to see a single case when Solaris would dump
the kernel. I’ve seen QNX doing that on quite a few occasions (both QNX4
and QNX6).
OTOH, having realtime class above the kernel in real life makes you
reluctant to use it, especially if project involves less-than-trusted
coders. Any runaway application in that class completely blocks the
system. You can’t do anything at all. Having a higher-priority shell
won’t help either, because kernel can’t process the signals.
I couldn’t find any figures about how big interrupt latency,
dispatch latency …etc. are with x86. They only give some
figures for SPARCs. Perhaps i just didn’t know where
to look - i haven’t spent much time with Solaris docs yet.
You won’t find any numbers for Intel, so do your own tests. Sun does not
directly support Solaris on Intel at all. You’re supposed to obtain
support from your hardware vendor, which is never a good story on really
deep issues. I would say story is not good even on not-so-deep ones. You
will also find that documentation and books are lacking on Intel side
for things involving interaction with hardware. They all talk about
SPARC and Intel variant always has some undocumented masochistic quirkness.
Is it charged per-installation?
I would think so. There are various kinds of licenses I understand, like
‘server license’ and ‘workstation license’. Embedded runtimes would be
subject to a specific OEM contract with any OS.
(development tools are extra, but GNU tools can
be used).
I’ll stick with GNU tools, i guess
GNU tools for SPARC stink, but for X86 you should be okay.
Ok, which one is best?
It will really depend on what you do. If your task involves lot of
exposure to kernel behavior and you anticipate needing serious support,
then you will likely be happier with QNX. Solaris like any high-volume
OS is catered to volume customer - people who do standard things on
standard hardware. You can afford doing nonstandard things if you’re
very big. If you’re not big and doing nonstandard things, you will be on
your own essentially.
Experience with both have indicated that you’re much less likely to
encounter odd behavior in Solaris than in QNX. However if you do
encounter such odd behavior, with QNX you have decent chances of getting
it fixed if it is a genuine bug. With Solaris you will have to bypass it
by changing your code.
Solaris is harder to install (in terms of complications involved in
making custom installations). It is bulkier and generally more PITA to
deal with until you get everything sorted out. Getting POSIX API to
behave in POSIX-conformant way is also separate story - you will need a
couple of lines of compiler switches (otherwise things compile and link
but do not really work as documented). However once you got everything
sorted, it runs steady as tourist bus. Practically no bumps at all.
Your mileage may vary 
– igor
It will really depend on what you do. If your task involves lot of
exposure to kernel behavior and you anticipate needing serious support,
then you will likely be happier with QNX. Solaris like any high-volume
OS is catered to volume customer - people who do standard things on
standard hardware. You can afford doing nonstandard things if you’re
very big. If you’re not big and doing nonstandard things, you will be on
your own essentially.Experience with both have indicated that you’re much less likely to
encounter odd behavior in Solaris than in QNX. However if you do
encounter such odd behavior, with QNX you have decent chances of getting
it fixed if it is a genuine bug. With Solaris you will have to bypass it
by changing your code.Solaris is harder to install (in terms of complications involved in
making custom installations). It is bulkier and generally more PITA to
deal with until you get everything sorted out. Getting POSIX API to
behave in POSIX-conformant way is also separate story - you will need a
couple of lines of compiler switches (otherwise things compile and link
but do not really work as documented). However once you got everything
sorted, it runs steady as tourist bus. Practically no bumps at all.Your mileage may vary >
A friend of mine came back from vocations at Italy. Their tourist bus was
delayed for two or three hours in Rome… So that’s not always a measure of
stability
// wbr
In real life it feels like very solid an reliable OS. Never ever
crashes. I mean I have yet to see a single case when Solaris would dump
the kernel. I’ve seen QNX doing that on quite a few occasions (both QNX4
and QNX6).
I’ve seen QNX4 crashes too, but only if an interrupt handler
was misbehaving. But in Solaris, device drivers and interrupt
handlers work inside the kernel, don’t they? That surely must
compromise stability.
You won’t find any numbers for Intel, so do your own tests. Sun
Well, actually i don’t have Solaris installed yet. I think i’ll get it
in a couple of days. Have you done any tests?
then you will likely be happier with QNX. Solaris like any high-volume
OS is catered to volume customer - people who do standard things on
standard hardware. You can afford doing nonstandard things if
To start with, is M-Systems DiskOnChip supported?
it fixed if it is a genuine bug. With Solaris you will have to bypass it
In QNX4.25 i’ve never seen such thing as kernel bug.
Is QNX6 buggier?
Igor Kovalenko <kovalenko@attbi.com> wrote:
However, there is some truth in the opinion that Solaris makes more
sense on SPARC. Some really high-end advanced features are only
implemented on SPARC (dynamic domain reconfiguration, CPU hot swap, etc).
Some of the things that Solaris on SPARC is capable of in the enterprise-class
hardware are truely amazing. Some of those features could be quite beneficial
for an RTOS too, but I doubt anything on intel hardware will ever get there.
Cheers,
Camz.
<camz@passageway.com> wrote in message news:an9v9c$ljq$1@inn.qnx.com…
Some of the things that Solaris on SPARC is capable of in the
enterprise-class
hardware are truely amazing. Some of those features could be quite
beneficial
for an RTOS too, but I doubt anything on intel hardware will ever get
there.
I admined an 8way Enterprise 4500, complete with fibrechannel RAID when I
was in school. I loved doing things like “configure ; make -j 16” and 2 or
3 minutes later having a complete QT library ready for deployment. Zoom
zoom.
Kris
Kris Warkentin <kewarken@qnx.com> wrote:
I admined an 8way Enterprise 4500, complete with fibrechannel RAID when I
was in school. I loved doing things like “configure ; make -j 16” and 2 or
3 minutes later having a complete QT library ready for deployment. Zoom
zoom.
I’m talking more about things like the ability to stuff another CPU card in,
tell it to migrate all processes to the new card, then pulling the original.
All without a user noticing at all. That and things like domains where you
also automatically migrate one of the CPU cards from one domain to another
to handle a daily peak period.
Cheers,
Camz.
Dmitri Ivanov wrote:
In real life it feels like very solid an reliable OS. Never ever
crashes. I mean I have yet to see a single case when Solaris would dump
the kernel. I’ve seen QNX doing that on quite a few occasions (both QNX4
and QNX6).I’ve seen QNX4 crashes too, but only if an interrupt handler
was misbehaving. But in Solaris, device drivers and interrupt
handlers work inside the kernel, don’t they? That surely must
compromise stability.
In theory, driver bugs are more dangerous for Solaris than for QNX. In
practice you will find that QNX drivers can take the system down just as
easily. A little mistake in an interrupt handler and you’re toast,
because they run in kernel mode. Granted, QNX allows you to not use
direct interrupt handlers at all. That helps somewhat, but still does
not give you absolute protection. If your interrupt thread fails to
clear interrupt for whatever reason, kernel gets overloaded very quickly
with pulses being queued for you. That manifests itself as system not
doing anything except for spitting ‘Out of interrupt events’ on the
screen continuously. The end result is, you have to reset it. It is as
good as a crash.
Bottom line, as long as you deal with hardware, you have opportunity to
take system down, Solaris or QNX or anything else. The probability of
such case will depend more on how well the hardware is understood and
how well the OS is understood by the driver writers, than on OS
architecture.
If majority of drivers for a given OS is written by hardware vendors,
you usually end up with less crashes of that sort, since they know their
hardware and OSes they support and usually very well known and well
understood. QNX may have safer architecture, but Solaris wins in the
area of off-the-shelf drivers, because it has better support by hardware
manufacturers and in general is much better described and understood by
developers. Availability of kernel source and large number of high
quality books are not to be underestimated.
Story may be different for drivers which you have to write yourself.
There you usually deal with hardware which is new and not well
known/understood. Potential for making mistakes is higher, so every bit
of protection you can have from OS is useful. QNX provides more
protection, especially on X86 hardware. QNX also makes it easier to
write new drivers (provided you understand the hardware and the OS well)
becaue you can use usual system calls and usual debugging tools.
Well, actually i don’t have Solaris installed yet. I think i’ll get it
in a couple of days. Have you done any tests?
No. We use Solaris in ‘soft-realtime’ system, so we did not need to do
it. However the architectural features it has and practical experience
suggest that it has no unbound latencies.
To start with, is M-Systems DiskOnChip supported?
We don’t use it, so I don’t know. This is not typical hardware Solaris
is used with, so chances are not very high. You better ask M-Systems.
In QNX4.25 i’ve never seen such thing as kernel bug.
Is QNX6 buggier?
QNX6 is younger and is being under active development. That inherently
means buggier. Everything has its price, especially new features. QNX4
did have kernel bugs too, there are no bug-free OSes
– igor
In theory, driver bugs are more dangerous for Solaris than for QNX. In
practice you will find that QNX drivers can take the system down just as
easily. A little mistake in an interrupt handler and you’re toast,
because they run in kernel mode. Granted, QNX allows you to not use
direct interrupt handlers at all. That helps somewhat, but still does
What do you mean?
not give you absolute protection. If your interrupt thread fails to
clear interrupt for whatever reason, kernel gets overloaded very quickly
with pulses being queued for you. That manifests itself as system not
You always can read CPU clock counter and block spurious
interrupts.
doing anything except for spitting ‘Out of interrupt events’ on the
screen continuously. The end result is, you have to reset it. It is as
good as a crash.Bottom line, as long as you deal with hardware, you have opportunity to
take system down, Solaris or QNX or anything else. The probability of
such case will depend more on how well the hardware is understood and
how well the OS is understood by the driver writers, than on OS
architecture.
I agree. A system programmer has a chance to crash the system, anyway.
If majority of drivers for a given OS is written by hardware vendors,
you usually end up with less crashes of that sort, since they know their
hardware and OSes they support and usually very well known and well
understood. QNX may have safer architecture, but Solaris wins in the
area of off-the-shelf drivers, because it has better support by hardware
manufacturers and in general is much better described and understood by
developers. Availability of kernel source and large number of high
quality books are not to be underestimated.Story may be different for drivers which you have to write yourself.
There you usually deal with hardware which is new and not well
known/understood. Potential for making mistakes is higher, so every bit
of protection you can have from OS is useful. QNX provides more
protection, especially on X86 hardware. QNX also makes it easier to
write new drivers (provided you understand the hardware and the OS well)
Actually you don’t even have to understand OS too much
becaue you can use usual system calls and usual debugging tools.
Well, actually i don’t have Solaris installed yet. I think i’ll get it
in a couple of days. Have you done any tests?
No. We use Solaris in ‘soft-realtime’ system, so we did not need to do
it. However the architectural features it has and practical experience
suggest that it has no unbound latencies.
But the don’t seem very good. For example System Interface Guide
gives dispatch latency for SPARC Station 2 (whatever SPARC
Station 2 is ) as large as 1 ms (vs microseconds in QNX).
To start with, is M-Systems DiskOnChip supported?
We don’t use it, so I don’t know. This is not typical hardware Solaris
is used with, so chances are not very high. You better ask M-Systems.
Probably it doesn’t matter anymore. DiskOnChip used to be a kind of
flash memory - recently the’ve released DiskOnChip with IDE interface.
In QNX4.25 i’ve never seen such thing as kernel bug.
Is QNX6 buggier?QNX6 is younger and is being under active development. That inherently
It sure is ! During the QNX-Russia-2002 Momentics IDE glitched a lot,
so we didn’t have a chance to see multithreaded debugging and such
things.
BTW, why on earth they decided to use java for Momentics IDE?
means buggier. Everything has its price, especially new features. QNX4
did have kernel bugs too, there are no bug-free OSes >
As a matter of fact I was quite happy with QNX4. The best OS ever!
Maybe it lacked some fancy tools and games, but it was predictable
and I’ve never seen a single bug in it (unless you mingle with QNX4
threads).
But it seems that QNX4 support is dead. So obvious choice would
be QNX6. And I think I like it. But I’m still looking for other
options, like Solaris or RTLinux. One reason is that QNX6 PE
is too expensive. Another reason is that Solaris and Linux are more
ubiquitous. Anyway I’m still on the fence and two leaders are
QNX6 and Solaris.
<camz@passageway.com> wrote in message news:anabrf$175$1@inn.qnx.com…
Kris Warkentin <> kewarken@qnx.com> > wrote:
I admined an 8way Enterprise 4500, complete with fibrechannel RAID when
I
was in school. I loved doing things like “configure ; make -j 16” and 2
or
3 minutes later having a complete QT library ready for deployment. Zoom
zoom.I’m talking more about things like the ability to stuff another CPU card
in,
tell it to migrate all processes to the new card, then pulling the
original.
All without a user noticing at all. That and things like domains where
you
also automatically migrate one of the CPU cards from one domain to another
to handle a daily peak period.
Actually, we were doing that too. We had a firmware problem (that we
initially thought was hardware) on one of the blades and it kept croaking
but we could keep the machine up while we were swapping cpu’s and so on.
Pretty cool stuff. I especially liked the fancy volume management stuff for
storage as well.
Kris.
Igor Kovalenko wrote:
Solaris is not really goot fit for such hardware.
Now there’s the understatement of the week ! and by someone not usually
prone to understatement 
Dmitri Ivanov wrote:
In theory, driver bugs are more dangerous for Solaris than for QNX. In
practice you will find that QNX drivers can take the system down just as
easily. A little mistake in an interrupt handler and you’re toast,
because they run in kernel mode. Granted, QNX allows you to not use
direct interrupt handlers at all. That helps somewhat, but still does
What do you mean?
InterruptAttachEvent() will tell kernel to queue and event (usually
pulse or signal) instead of calling interrupt handler function. You
receive that event using MsgReceive().
Advantage is, there is no interrupt handler anymore, you only deal with
regular threads. They don’t run in kernel mode, which means better
protection. And they are schedulable according to OS priorities rather
than ‘hardware priorities’ of interrupt handlers.
Disadvantage is, danger of overloading kernel event queue. If you have a
runaway process at higher priority, queue won’t be drained, your devices
stop working and eventually you get into ‘Out of interrupt events’ mode.
not give you absolute protection. If your interrupt thread fails to
clear interrupt for whatever reason, kernel gets overloaded very quickly
with pulses being queued for you. That manifests itself as system not
You always can read CPU clock counter and block spurious
interrupts.
Wishful thinking. You can’t tell which ones are spurious. The
non-spurious ones become ‘spurious’ if you stop draining the queue.
Besides, you can’t block them even if you could tell because then your
hardware stops working.
of protection you can have from OS is useful. QNX provides more
protection, especially on X86 hardware. QNX also makes it easier to
write new drivers (provided you understand the hardware and the OS well)
Actually you don’t even have to understand OS too much >
I’ve seen horrible things done by people who think they don’t have to
understand the OS when writing drivers.
But the don’t seem very good. For example System Interface Guide
gives dispatch latency for SPARC Station 2 (whatever SPARC
Station 2 is >
SPARC Station 2 is like your grandma’s 20Mhz 386-SX or something of that
sort. I don’t think 1ms is bad for that hardware.
It sure is ! During the QNX-Russia-2002 Momentics IDE glitched a lot,
so we didn’t have a chance to see multithreaded debugging and such
things.
BTW, why on earth they decided to use java for Momentics IDE?
Because that was their only chance to get something workable sooner than
the return of the Christ.
As a matter of fact I was quite happy with QNX4. The best OS ever!
Maybe it lacked some fancy tools and games, but it was predictable
and I’ve never seen a single bug in it (unless you mingle with QNX4
threads).
But it seems that QNX4 support is dead. So obvious choice would
be QNX6. And I think I like it. But I’m still looking for other
options, like Solaris or RTLinux. One reason is that QNX6 PE
is too expensive. Another reason is that Solaris and Linux are more
ubiquitous. Anyway I’m still on the fence and two leaders are
QNX6 and Solaris.
PE is not really more expensive than development seat of Solaris when
you use Sun’s development tools (but of course, PE still uses GNU
toolchain, unlike Sun’s compiler which is much better than GCC).
It would help if you told what your project is. Since you talk about
DiskOnChip you sound like it is something embedded and perhaps resource
constrained. Solaris is not really goot fit for such hardware.
– igor