LynxOS vs QNX
Armin Steinhoff
In article <5sdotr$rea$1...@vancouver.wdg.mot.com>, robi...@see-my-sig.com says...
>
>If anyone would care to compare QNX to LynxOS (at any level), it would be
>appreciated. My limited impression is that QNX's microkernel approach is
>superior to LynxOS's monolithic kernel, but aside from that there isn't
>that much in the way of differences.
There is an important architectural difference:
QNX is a fully distributed Realtime Operating System !
^^^^^^^^^^^^^^^^^
Armin Steinhoff
http://www.steinhoff.de
>
>--
>Jim Robinson
>robi...@wdg.mot .com # remove space in address
Bruce Edge
Jim Robinson wrote in article <5sdotr$rea$1...@vancouver.wdg.mot.com>...
>If anyone would care to compare QNX to LynxOS (at any level), it would be
>appreciated. My limited impression is that QNX's microkernel approach is
>superior to LynxOS's monolithic kernel, but aside from that there isn't
>that much in the way of differences.
>
>--
I only had a brief experience with LynxOS. I signed up to evaluate it and
they sent 2 field engineers to hand deliver the product. THey then spent the
entire day trying to install it. They never did get the X server runnng.
I also signed up to evaluate QNX. Got that installed in about 60 min,
(without any accompanying support engineers) X, TCP and everything. At that
point the choice seemed pretty clear. I've been using QNX for 3 years now
and it's one of the few decisions I've made that I haven't regretted. :-)
Bruce Edge
be...@sattel.com
Mitchell Schoenbrun
: If anyone would care to compare QNX to LynxOS (at any level), it would be
: appreciated. My limited impression is that QNX's microkernel approach is
: superior to LynxOS's monolithic kernel, but aside from that there isn't
: that much in the way of differences.
This probably isn't what you wanted, but you did say "at any level".
This was a number of years ago, so my recollection is a bit
fuzzy. A customer came to me and asked me about
possibly porting my Bernoulli Box driver to LynxOS. They put me
in contact with the technical staff there. They did not seem
happy about this. After some interaction with the customer, they
seemed to have agreed to send me the material I would need to do
this, and provide me with some technical support. After a few
months of waiting, I realized that they were not going to provide
either.
I speak having worked with QSSL for years in this same
area having gotten all the help I needed. Admittedly this was
a long time ago, and LynxOS did not know me personally at the time.
--
Mitchell Schoenbrun --------- masc...@pobox.com
Bill Sturm
>appreciated. My limited impression is that QNX's microkernel approach is
>superior to LynxOS's monolithic kernel, but aside from that there isn't
>that much in the way of differences.
>
Just out of curiosity, was this message also posted in comp.os.lynx to
get the opinions of Lynx users?
--
Bill Sturm
bst...@gatecom.com
Please remove the "NO_SPAM" from my e-mail address when replying.
Greg Bergsma
Jim Robinson (robi...@see-my-sig.com) wrote:
: If anyone would care to compare QNX to LynxOS (at any level), it would be
: appreciated. My limited impression is that QNX's microkernel approach is
: superior to LynxOS's monolithic kernel, but aside from that there isn't
: that much in the way of differences.
: --
: Jim Robinson
: robi...@wdg.mot .com # remove space in address
My understanding is that LynxOS uses kernel plug-in modules to achieve
scalability. The problem with such an approach is that these plug-in
modules become part of the kernel and thus you run into reliability issues
by having too much stuff in the kernel - you still have a monolithic kernel
architecture.
One of the key elements to creating fault-tolerant, highly available
systems is to minimize the possibilities of kernel faults. The larger the
kernel, the higher the likelihood of kernel faults - the only way out is a
hardware reboot. Stray pointers and rogue array indices in code running in
kernel space are the main cause of kernel faults.
A true microkernel architecture, extended by separate MMU-protected processes
provides the advantage of being able to scale your system without the risk
of increasing the possibility of kernel faults. In addition to this, the OS
must provide a mechanism that assists in fault-recovery when stray pointers
and such are detected by the MMU. In QNX you can develop a software
watchdog that is INFORMed of abnormal process deaths (like memory
violations, illegal instruction, floating point errors). This software
watchdog can then recover intelligently from the fault. No hardware reboot
required - faster recovery - the operators may not even notice.
This is a key architectural difference. They don't have Photon either :-)
--
Greg Bergsma
Senior Technology Analyst
_______________________________________________________
QNX Software Systems Ltd | Phone: +1 (613) 591 0931
175 Terence Matthews Crscent| Fax: +1 (613) 591 3579
Kanata, Ontario, Canada | Email: gber...@qnx.com
K2M1W8 | WWW: http://www.qnx.com
_______________________________________________________
nospam-...@pobox.com
Steve Watt -- KD6GGD <st...@Watt.COM> wrote:
: Seriously, there are advantages to both OSes, and advantages to both the
: microkernel approach and the monolithic (or hybrid, in the case of the
: new Galaxy stuff). The worst-case interrupt and task response times are
: somewhat better with a monolithic kernel, because there are fewer MMU
: context switches involved in handling an interrupt. Unless the interrupts
: are handled in the kernel context in QNX which removes some of the argument
: that microkernels are safer because all the various bits are protected from
: each other.
: As in all branches of engineering, there are tradeoffs both ways. My
: suspicion is that QNX is slightly more robust against device driver
: writers that LynxOS, but that LynxOS is somewhat quicker under heavy
: load. And LynxOS has demand-paged VM, for those processes of
: sufficiently low priority that it's useful. :)
: Uhh... why is everyone glaring at me? Ok, I'll leave. ;)
Oh, its not that bad here. Most user find there way to QNX because
they require the preformance. We become advocates only because
we find it. I'm very interested in your point about interrupt
latencies. It is true that QNX runs your interrupt handler in
your context. That would imply two context switches to process
an interrupt. Once when the interrupt fires into Kernel mode,
and another before calling the handler. Actually this would be
doubled since you have to do it all in reverse to get out I think.
I suspect that QSSL (maybe they will respond, are you there Dan?)
would argue that their design is so much better that they still
have better latencies. Assuming that that is the case, then all
that needs to be done is to check the numbers. QSSL published some
numbers a while back that had to do with 386's. I'd like to see
some numbers for Pentiums for both OS's. This would move the
question from philosophy to product quality. The original questioner
wasn't asking whether he should use a micro-kernel vs. monolithic.
He was ask whether he should use QNX or LynxOS.
Steve Watt -- KD6GGD
In article <33F3AABB.3D5C@NO_SPAM.gatecom.com>,
Bill Sturm <bsturm@NO_SPAM.gatecom.com> wrote:
>Jim Robinson wrote in article <5sdotr$rea$1...@vancouver.wdg.mot.com>...
>>
>>appreciated. My limited impression is that QNX's microkernel approach is
>>superior to LynxOS's monolithic kernel, but aside from that there isn't
>>that much in the way of differences.
>>
>
>get the opinions of Lynx users?
No, it wasn't. Pity, could've had a little fun. Not safe to do that in
this newsgroup, though. ;) (Caution: I'm a bit biased, and haven't had
much time to play with QNX.)
Seriously, there are advantages to both OSes, and advantages to both the
microkernel approach and the monolithic (or hybrid, in the case of the
new Galaxy stuff). The worst-case interrupt and task response times are
somewhat better with a monolithic kernel, because there are fewer MMU
context switches involved in handling an interrupt. Unless the interrupts
are handled in the kernel context in QNX which removes some of the argument
that microkernels are safer because all the various bits are protected from
each other.
As in all branches of engineering, there are tradeoffs both ways. My
suspicion is that QNX is slightly more robust against device driver
writers that LynxOS, but that LynxOS is somewhat quicker under heavy
load. And LynxOS has demand-paged VM, for those processes of
sufficiently low priority that it's useful. :)
Uhh... why is everyone glaring at me? Ok, I'll leave. ;)
--
Steve Watt KD6GGD PP-ASEL-IA Packet: KD6GGD @ N0ARY.#NOCAL.CA.USA.NA
ICBM: 121W 56' 58.1" / 37N 20' 14.2" Internet: steve @ Watt.COM
Free time? There's no such thing. It just comes in varying prices...
Steve Watt -- KD6GGD
Something to watch out for when doing benchmarking is to ensure that
the benchmarks are equivalent, not just in terms of the underlying
hardware, but also in the system load. Lynx publishes worst-case
numbers with 5 interrupting devices. This has gotten Lynx in trouble
more than once because people see the ~100uS times and say "but that's
awful, <other os> has times around 5uS!" LynxOS' best case on a 133MHz
Pentium is in that vicinity (I don't remember the specific numbers),
but the best case isn't the one you care about when you're designing
for a hard deadline. Heck, you don't even care about the average, which
is almost the same as the best case (again, from memory).
I agree with your analysis that it's at least two context switches to
the interrupt handler code, assuming that said code is running in a
separate MMU context. And I *know* that MMU context switches ain't
real sprightly on the x86. I don't think any of the processors
that I've used enough to get a feeling for are very quick on context
switches, though the PowerPCs are up there.
As for returning from the interrupt handler to user code, I don't think
it is all that hard to arrange things so there's just the one MMU context
switch, from the interrupt-handling process (for lack of a better term)
to the original process.
And as for the "should I use QNX or LynxOS" well ... my opinion is
probably guessable, and it ain't QNX. ;) But then, I might (just maybe)
have a biased opinion. Seriously, it has quite a bit do to with your
requirements. As a trivial example, if you want a non-Intel processor,
QNX ain't much good. Unfortunately, I'm not well-enough versed in QNX
operation to make a more technical comparison.
In article <33f9f...@news.tsoft.net>, <nospam-...@pobox.com> wrote:
>Steve Watt -- KD6GGD <st...@Watt.COM> wrote:
>
>: The worst-case interrupt and task response times are
>: somewhat better with a monolithic kernel, because there are fewer MMU
>: context switches involved in handling an interrupt.
>
> I'm very interested in your point about interrupt
>latencies. It is true that QNX runs your interrupt handler in
>your context. That would imply two context switches to process
>an interrupt. Once when the interrupt fires into Kernel mode,
>and another before calling the handler. Actually this would be
>doubled since you have to do it all in reverse to get out I think.
>
>I suspect that QSSL (maybe they will respond, are you there Dan?)
>would argue that their design is so much better that they still
>have better latencies. Assuming that that is the case, then all
>that needs to be done is to check the numbers. QSSL published some
>numbers a while back that had to do with 386's. I'd like to see
>some numbers for Pentiums for both OS's. This would move the
>question from philosophy to product quality. The original questioner
>wasn't asking whether he should use a micro-kernel vs. monolithic.
>He was ask whether he should use QNX or LynxOS.
John Wilson
In article <33fac...@news.tsoft.net>, <nospam-...@pobox.com> wrote:
>I believe the numbers QSSL was publishing
>were worst case, but I could be mistaken.
I don't have the brochure in front of me, but I remember seeing a little
timing chart that showed something like 4.x usec (on a P5-100???) between
the interrupt and the first instruction of the ISR being executed, but then
there was a little footnote that said something like "well actually, 4.x
usec PLUS whatever's the longest time that either QNX or the user turns off
interrupts". Well DUH! So who knows what the worst case is.
I'm used to programming PDP-11s, which have been claiming 10 usec best-case
interrupt response since *1970*, I can't believe there's only a 150%
improvement on hardware that's a zillion times faster. Admittedly the
PDP-11 was designed for fast interrupts (multiple stack pointers and it
switches priority automatically on the way in and out of the ISR) and the
10 usec is for kernel-mode,int handlers, but still 4ish usec seems pretty
weak...
John Wilson
D Bit
Dan Hildebrand
In article <EF5G...@Watt.COM>, Steve Watt -- KD6GGD <st...@Watt.COM> wrote:
>In article <33F3AABB.3D5C@NO_SPAM.gatecom.com>,
>Bill Sturm <bsturm@NO_SPAM.gatecom.com> wrote:
>>Jim Robinson wrote in article <5sdotr$rea$1...@vancouver.wdg.mot.com>...
>>>
>>>If anyone would care to compare QNX to LynxOS (at any level), it would be
>>>appreciated. My limited impression is that QNX's microkernel approach is
>>>superior to LynxOS's monolithic kernel, but aside from that there isn't
>>>that much in the way of differences.
>>
>>Just out of curiosity, was this message also posted in comp.os.lynx to
>>get the opinions of Lynx users?
>
>No, it wasn't. Pity, could've had a little fun. Not safe to do that in
>this newsgroup, though. ;) (Caution: I'm a bit biased, and haven't had
>much time to play with QNX.)
Splashing gasoline around is always fun. :-)
>Seriously, there are advantages to both OSes, and advantages to both the
>microkernel approach and the monolithic (or hybrid, in the case of the
>new Galaxy stuff).
Is it truly a "hybrid", or is it a monolithic kernel with dynamically
loadable kernel extensions, like the Linux and BSD groups have done? If
the loaded entensions are running in the same address space as the kernel,
this is still a monolithic kernel.
>The worst-case interrupt and task response times are
>somewhat better with a monolithic kernel, because there are fewer MMU
>context switches involved in handling an interrupt. Unless the interrupts
>are handled in the kernel context in QNX which removes some of the argument
>that microkernels are safer because all the various bits are protected from
>each other.
Under QNX, a physical interrupt is "landed" by the microkernel which then
calls into the interrupt handler in the user process' space. While the
interrupt handler is executing, it can make use of the code and data. At
the end of the interrupt handler function, it returns a value to the
microkernel that indicates whether the kernel should simply return to the
context of the interupted process, or exit via the scheduler into the
context of a process the interrupt handler has indicated should now be made
ready. If that process made ready is the highest priority process in the
system, the microkernel effectively does a "return from interrupt" into the
newly readied process, otherwise the previously interrupt process continues
to run. Incidentally, kernel calls work very much like this as well, with
entry via a software interrupt, and the return from interrupt taking the
CPU into the "now ready" process, which may or may not be the same as the
calling process.
>As in all branches of engineering, there are tradeoffs both ways. My
>suspicion is that QNX is slightly more robust against device driver
>writers that LynxOS, but that LynxOS is somewhat quicker under heavy
>load.
It would be an interesting analysis.
>And LynxOS has demand-paged VM, for those processes of
>sufficiently low priority that it's useful. :)
>
>Uhh... why is everyone glaring at me? Ok, I'll leave. ;)
:-)
--
Dan Hildebrand (da...@qnx.com) QNX Software Systems, Ltd.
http://www.qnx.com/~danh 175 Terence Matthews
phone: +1 (613) 591-0931 Kanata, Ontario, Canada
fax: +1 (613) 591-3579 K2M 1W8
Dan Hildebrand
In article <EF7Bp...@Watt.COM>, Steve Watt -- KD6GGD <st...@Watt.COM> wrote:
>Something to watch out for when doing benchmarking is to ensure that
>the benchmarks are equivalent, not just in terms of the underlying
>hardware, but also in the system load. Lynx publishes worst-case
>numbers with 5 interrupting devices. This has gotten Lynx in trouble
>more than once because people see the ~100uS times and say "but that's
>awful, <other os> has times around 5uS!" LynxOS' best case on a 133MHz
>Pentium is in that vicinity (I don't remember the specific numbers),
>but the best case isn't the one you care about when you're designing
>for a hard deadline. Heck, you don't even care about the average, which
>is almost the same as the best case (again, from memory).
Cache and TLB effects are also interesting. Forcing "cold cache"
conditions before a timing run are worthwhile.
>I agree with your analysis that it's at least two context switches to
>the interrupt handler code, assuming that said code is running in a
>separate MMU context.
At least two? Under QNX, interrupt handlers run with a different MMU
mapping in effect, but a context switch is not incurred to set this up. The
interrupt occurs, which is landed by the microkernel, some MMU manipulation
is done so that the interrupt handler (itself present in the user process
address space) can be called such that it can use data in the user process'
address space, and the microkernel either does a simple return from
interrupt, or unwinds through the scheduler (as indicated by the return
value from the interrupt handler function).
>And I *know* that MMU context switches ain't
>real sprightly on the x86.
Ahh, but there are many ways of implementing them. :-)
>I don't think any of the processors
>that I've used enough to get a feeling for are very quick on context
>switches, though the PowerPCs are up there.
>
>As for returning from the interrupt handler to user code, I don't think
>it is all that hard to arrange things so there's just the one MMU context
>switch, from the interrupt-handling process (for lack of a better term)
>to the original process.
Yup.
>And as for the "should I use QNX or LynxOS" well ... my opinion is
>probably guessable, and it ain't QNX. ;) But then, I might (just maybe)
>have a biased opinion. Seriously, it has quite a bit do to with your
>requirements. As a trivial example, if you want a non-Intel processor,
>QNX ain't much good. Unfortunately, I'm not well-enough versed in QNX
>operation to make a more technical comparison.
The following article was expired on my news server, so I'll comment on it
within the quotes here:
>In article <33f9f...@news.tsoft.net>, <nospam-...@pobox.com> wrote:
>>Steve Watt -- KD6GGD <st...@Watt.COM> wrote:
>>
>>: The worst-case interrupt and task response times are
>>: somewhat better with a monolithic kernel, because there are fewer MMU
>>: context switches involved in handling an interrupt.
>>
>> I'm very interested in your point about interrupt
>>latencies. It is true that QNX runs your interrupt handler in
>>your context. That would imply two context switches to process
>>an interrupt. Once when the interrupt fires into Kernel mode,
>>and another before calling the handler. Actually this would be
>>doubled since you have to do it all in reverse to get out I think.
Be careful with how you use the word "context". There's a process context
in the sense of context switching as done by the scheduler, and there's
addressability, achieved by manipulating the MMU and page mapping tables.
Much of what is described above is just changes in addressability.
>>I suspect that QSSL (maybe they will respond, are you there Dan?)
Yup. :-)
>>would argue that their design is so much better that they still
>>have better latencies.
While we context switch to get in and out of, say, a filesystem process, we
don't context switch to get in and out of interrupt handlers. Our position
is that since context switching is so quick, using context switches to get
to a filesystem process is worthwhile. This is because the server process
will tend to do enough work that the couple microseconds the context switch
took is irrelevent. However, having incurred the context switch to invoke
the service means that:
1) The service provider runs in a separate address space from the service
requester, with all the gains in reliability, version control, quality
control, etc that this implies.
2) The service provider/requester can run on different CPUs in a LAN
without any application changes. The result is a distributed computing
environment.
3) Services can be dynamically started and stopped.
If you think about services like an SQL database server, you'll see what
I'm driving at. Most people would accept that you don't want to build this
into the OS kernel. If not, why not? And why wouldn't those same
arguments apply to not building filesystems, etc into the kernel? Once
you've achieved fast context switching you have the architectural
flexibility to provide new kinds of services and reliability levels.
Also, environments like Photon (a GUI built from a team of cooperating
processes) can be built from this cheap context switching that can do some
very flexible things that cannot be easily done on other systems.
>>Assuming that that is the case, then all
>>that needs to be done is to check the numbers. QSSL published some
>>numbers a while back that had to do with 386's. I'd like to see
>>some numbers for Pentiums for both OS's. This would move the
>>question from philosophy to product quality. The original questioner
>>wasn't asking whether he should use a micro-kernel vs. monolithic.
>>He was ask whether he should use QNX or LynxOS.
While performance numbers tell part of the story, they don't characterize
the benefits of the architectural flexibility that a microkernel
architecture can provide. By microkernel, I mean an architecture where
higher-level OS services are implemented in separate, MMU-protected address
spaces invoked by means of the IPC services provided by the microkernel. I
don't mean a monolithic kernel with either compiled-in, or dynamically
linked-in services ending up in the same address space, invoked by function
calls within that single address space.
nospam-...@pobox.com
Dan Hildebrand <da...@qnx.com> wrote:
: >That is, unless your Interrupt model allows multiple processes to
: >attach interrupt handlers to a single hardware interrupt. This is
: >a QNX feature quite worth of an extra context switch.
: Not a context switch - just changes in MMU addressability.
I guess I am mixing up the definition of a "context switch."
It seems to me that when a hardware interrupt occurs under QNX,
first control is passed to the kernel, which then calls each
associated user handler, in their own context. I guess you are
saying that this is not a "context switch". Can you give
a more precise definition?
nospam-...@pobox.com
Steve Watt -- KD6GGD <st...@Watt.COM> wrote:
: Something to watch out for when doing benchmarking is to ensure that
: the benchmarks are equivalent, not just in terms of the underlying
: hardware, but also in the system load.
Well this is pretty much out of my hands. I think a properly
checking of latencies would need a logic analyser, or at least
a Scope. Obviously it is important to scrutenize the numbers
we are handed. I believe the numbers QSSL was publishing
were worst case, but I could be mistaken.
: Lynx publishes worst-case
: numbers with 5 interrupting devices. This has gotten Lynx in trouble
: more than once because people see the ~100uS times and say "but that's
: awful, <other os> has times around 5uS!" LynxOS' best case on a 133MHz
: Pentium is in that vicinity (I don't remember the specific numbers),
: but the best case isn't the one you care about when you're designing
: for a hard deadline. Heck, you don't even care about the average, which
: is almost the same as the best case (again, from memory).
: I agree with your analysis that it's at least two context switches to
: the interrupt handler code, assuming that said code is running in a
: separate MMU context. And I *know* that MMU context switches ain't
: real sprightly on the x86. I don't think any of the processors
: that I've used enough to get a feeling for are very quick on context
: switches, though the PowerPCs are up there.
Well just to know where QSSL's heart is on this subject, a little
story, And this is
just educated rumor. Their latest product Neutrino, a future kernel
replacement for QNX 4.+, is mostly being used in embedded products.
Apparently the memory model for the whole OS is flat 32 bit. No
segment register loading at all once the OS initialization is done.
The purported reason for this is that when there is a segment load,
I believe of just the CS, Intel processors do a pipeline flush.
Sort of makes sense, but really slows things down.
: As for returning from the interrupt handler to user code, I don't think
: it is all that hard to arrange things so there's just the one MMU context
: switch, from the interrupt-handling process (for lack of a better term)
: to the original process.
That is, unless your Interrupt model allows multiple processes to
attach interrupt handlers to a single hardware interrupt. This is
a QNX feature quite worth of an extra context switch.
: And as for the "should I use QNX or LynxOS" well ... my opinion is
: probably guessable, and it ain't QNX. ;) But then, I might (just maybe)
: have a biased opinion.
Well, why are you biased? What do you like about LynxOS? I'm
interested to hear. Some things you might comment on.
* Quality of the OS, compilers, utilities, technical support
* Availability of 3rd party products
* Support for hardware
Standard items like disk controllers, network cards, and video cards
Exotic stuff like A/D and Video Capture
* Price
Dan Hildebrand
>story, And this is
>just educated rumor. Their latest product Neutrino, a future kernel
>replacement for QNX 4.+, is mostly being used in embedded products.
>Apparently the memory model for the whole OS is flat 32 bit. No
>segment register loading at all once the OS initialization is done.
A small clarification: QNX/Neutrino supports several memory models ranging
from a single, flat 32 bit address space with no memory protection, up
through various levels of user/kernel address space separation, culminating
in the same per-process address space protection used in QNX 4.x. The
idea here is that deeply embedded systems may not have a paged MMU (like
the National Semiconductor NS486SXF), or the system may be too
memory-constrained to support the page mapping tables. This lets the
developer tune the memory usage / memory protection tradeoff.
>The purported reason for this is that when there is a segment load,
>I believe of just the CS, Intel processors do a pipeline flush.
>Sort of makes sense, but really slows things down.
Segments loads have definately become more expensive in the newer x86
processors.
>: As for returning from the interrupt handler to user code, I don't think
>: it is all that hard to arrange things so there's just the one MMU context
>: switch, from the interrupt-handling process (for lack of a better term)
>: to the original process.
>
>That is, unless your Interrupt model allows multiple processes to
>attach interrupt handlers to a single hardware interrupt. This is
>a QNX feature quite worth of an extra context switch.
Not a context switch - just changes in MMU addressability.
Geoff Roberts
On 20 Aug 1997 12:56:33 GMT, wil...@dbit.com (John Wilson) wrote:
>In article <33fac...@news.tsoft.net>, <nospam-...@pobox.com> wrote:
>>I believe the numbers QSSL was publishing
>>were worst case, but I could be mistaken.
>
>I don't have the brochure in front of me, but I remember seeing a little
>timing chart that showed something like 4.x usec (on a P5-100???) between
>the interrupt and the first instruction of the ISR being executed, but then
>there was a little footnote that said something like "well actually, 4.x
>usec PLUS whatever's the longest time that either QNX or the user turns off
>interrupts". Well DUH! So who knows what the worst case is.
One could easily get the impresson here that interrupt latency is the
primary benchmark governing the quality of a RTOS. Somehow, I don't
think it is quite that simple.
Arguments about which is a better operating system are starting to
bore me. To me, one should use one that they feel comfortable with,
that can do the required job, is designed for the job, and be cost
effective (given all the various factors that govern this).
One could say that they are all good in their own way - all have had
considerable effort put into them. But some operating systems (well,
one in particular) have no business being in the real time arena, but
marketing issues dictate that it is. So, all the argument I have seen
in this thread, and a couple of others, is just nonsense in that
whatever the technical elegance and effectiveness of an RTOS may be,
the marketing arguments will prevail and at the end of the day,
technical elegance and quality are sacrificed. So why do we bother?
>I'm used to programming PDP-11s, which have been claiming 10 usec best-case
>interrupt response since *1970*, I can't believe there's only a 150%
>improvement on hardware that's a zillion times faster. Admittedly the
>PDP-11 was designed for fast interrupts (multiple stack pointers and it
>switches priority automatically on the way in and out of the ISR) and the
>10 usec is for kernel-mode,int handlers, but still 4ish usec seems pretty
>weak...
Weak? Well, if these are "weak", where does that leave NT? :-)
Geoff Roberts.
>John Wilson
>D Bit
Steve Watt -- KD6GGD
What I really like about LynxOS? The first and foremost is that it's a
familiar environment to Unix users. Porting arbitrary software off the
'net is really a no-brainer, even when said arbitrary software is as
complex as Perl. That's a recent change, I must admit, and one for the
better. The compilers are all GNU (another somewhat less recent change),
which I think of as a feature -- there are some very useful extensions
of ANSI C in GCC. I admit that I don't use C++, so I can't address the
complaints I've heard about G++.
In the not-too-distant past, Lynx was way ahead on meeting POSIX. I think
that gap is being narrowed as the various POSIX committees slow down.
Real demand-paged virtual memory is another big win in my book. I can
run the fattest X programs (heck, Motif even!) and not have to install
a heck of a lot of memory. Mind you, it's a lot faster with the memory
than to page. Shocking.
And lastly? Multiple platforms -- I guess I just have an irrational
dislike of Intel, but I have grown it over a number of years.
The quality of the tech support is great; go look in comp.os.lynx in
the recent "LynxOS vs Linux" thread for some comments from a very satisfied
customer. And yes, LynxOS has got that same problem with Linux that all
the other RTOSes do. "But Linux does <blah>!" Yeah, but Linux doesn't
have real-time constraints.
There's a pretty substantial third-party program, named Synergy. Take a
look at the Lynx web site.
The hardware support on the x86 isn't as broad as some would like, but
I think that's a side effect of picking the most popular devices to
make room to support all 4 platforms.
As for obscure (OK, A/D ain't obscure) devices, driver writing isn't that
hard, and any of the distributors (and Lynx' consulting group) will be
glad to help with a driver that you can't get from Lynx or a third party.
Armin Steinhoff
In article <5thjjh$nm9$1...@news.wizvax.net>, wil...@dbit.com says...
>
>In article <33fa740d...@news.zippo.com>,
>Geoff Roberts <ge...@rtts.com.au> wrote:
>>One could easily get the impresson here that interrupt latency is the
>>primary benchmark governing the quality of a RTOS. Somehow, I don't
>>think it is quite that simple.
>
Wrong ... the predictable processing of the interupt events is the key !
For instance WinNT is very responsible for interrupts ... is it a
realtime operating system ??
>Now, which OS is a better *OS* in general is of course a religious issue
>and talking about it out loud gets you incinerated. But an OS that gets
>around to servicing external inputs whenever it feels like it, is not
>going to be much use as an RTOS, no matter what a good and/or well-marketed
>product it is otherwise.
Fast interrupt processing is a basic feature ... the architecture
of an RTOS is more important !!
>Anyway there aren't enough hard data here. One the one hand we have
>"QNX might have slower int service than LynxOS because of the extra
>context switch", and on the other there's "LynxOS might be buggier
>due to not partitioning the kernel". These are both just maybes...
It's a piece of logic that a bigger program contains more bugs ...
look to WinNT :-)) There are also differences in the hardware
architectures ...
Armin Steinhoff
http://www.steinhoff.de
John Wilson
In article <5thtrn$5...@drn.zippo.com>,
Armin Steinhoff <Ar...@Steinhoff.de> wrote:
>>Hold on here -- response to external events is what puts the RT in RTOS!
>
>Wrong ... the predictable processing of the interupt events is the key !
Uh ... I don't see how these two statements differ, unless you thought that
by "response" I just meant "as opposed to no response", but what I meant
was "guaranteed fast response".
>Fast interrupt processing is a basic feature ...
... which makes it real-time.
>the architecture
>of an RTOS is more important !!
... which is a religious issue (i.e. you like it because you like it and
no one can sway you). So we agree -- great!
>It's a piece of logic that a bigger program contains more bugs ...
>look to WinNT :-)) There are also differences in the hardware
>architectures ...
Saying bigger programs have more bugs than smaller programs with all other
variables being equal makes sense, but those other variables are rarely
anywhere near equal. The number of bugs in a kernel has more to do with
the skill that went into writing it, than the overall size. Microsoft
has produced plenty of SMALL bug-ridden products too!
Anyway I'm a little vague on the benefits of having protection in micros
where you usually run very few tasks anyway (and no malicious users).
I mean, chances are those protected user processes are the ones I really
care about anyway -- if the word processor blows up and loses an entire day's
work, am I supposed to be thrilled that at least the OS is still OK? I get
this all the time on my Linux box, one or more of the vital system daemons
will take a hike, and frankly since they're all auto-started on boot I've
never learned how to start them by hand, so I need to reboot anyway to get
them back.
Similarly, having the microkernel protect itself from the file system (etc.)
blowing up seems a bit pointless (except maybe during debugging), since
leaving yourself on a happily running machine with a dead file system, or
network, or whatever else, is of little use most of the time. So what do you
really buy yourself in exchange for having to make context switches all the
time (or map changes or whatever, I don't just mean "context switch" by the
narrow definition in the Intel docs, y'know, the same ones that were so
proud of the 17 usec context switch time in the original 386)?
John Wilson
D Bit
Dean Z. Douthat
nospam-...@pobox.com wrote:
: Dan Hildebrand <da...@qnx.com> wrote:
: : >That is, unless your Interrupt model allows multiple processes to
: : >attach interrupt handlers to a single hardware interrupt. This is
: : >a QNX feature quite worth of an extra context switch.
: : Not a context switch - just changes in MMU addressability.
: I guess I am mixing up the definition of a "context switch."
: It seems to me that when a hardware interrupt occurs under QNX,
: first control is passed to the kernel, which then calls each
: associated user handler, in their own context. I guess you are
: saying that this is not a "context switch". Can you give
: a more precise definition?
: --
: Mitchell Schoenbrun --------- masc...@pobox.com
A full context switch must save the machine state to be restored later.
This is clearly not the case for an interrupt handler as can be seen by
the restrictions in an interrupt handler. For example, you may not do
floating point operations in the handler because the FP registers are
not saved.
--
Names: Dean Z. Douthat de...@cyberzone-inc.com
Snail: PO Box 7571 Ann Arbor MI 48107-7571 USA
Phone: (313)747-9170 (voice) (313)747-8478 (fax)
John Wilson
In article <33fa740d...@news.zippo.com>,
Geoff Roberts <ge...@rtts.com.au> wrote:
>One could easily get the impresson here that interrupt latency is the
>primary benchmark governing the quality of a RTOS. Somehow, I don't
>think it is quite that simple.
Hold on here -- response to external events is what puts the RT in RTOS!
Now, which OS is a better *OS* in general is of course a religious issue
and talking about it out loud gets you incinerated. But an OS that gets
around to servicing external inputs whenever it feels like it, is not
going to be much use as an RTOS, no matter what a good and/or well-marketed
product it is otherwise.
Anyway there aren't enough hard data here. One the one hand we have
"QNX might have slower int service than LynxOS because of the extra
context switch", and on the other there's "LynxOS might be buggier
due to not partitioning the kernel". These are both just maybes...
>Weak? Well, if these are "weak", where does that leave NT? :-)
No argument there!
John Wilson
D Bit
Steve Watt
In article <33fc9...@news.tsoft.net>, <nospam-...@pobox.com> wrote:
>Steve Watt -- KD6GGD <st...@Watt.COM> wrote:
>
>
>A lot of QNX users would like this feature. I'm curious how it is
>implemented with respect to real-time. Is there a "please-page"
>or a "don't page" process flag somewhere? A spawn option?
All of the above, and then some. There's the POSIX.1b-specified mlock()
and mlockall() interface, which requests (demands? sorry, couldn't resist
the pun) that a specific range (or all of the process) not be paged.
Additionally, there's a "priority fence": Any process whose priority
when it starts is above the pager's priority will not have virtual
pages allocated to it; it will not be pageable.
>: As for obscure (OK, A/D ain't obscure) devices,
>
>Well specific A/D boards are probably a little to obscure for an
>OS manufactorer to write. That's what keeps consultants like me
>in business.
If any single A/D board vendor gets big enough sales that the OS vendors
start noticing that their boards are worth supporting, the industry
has gotten too large. Or too small. ;)
(Aside to Armin Steinhoff:
I'm not a VME bigot either, <flamebait>it's just that the x86
architecture really is a souped-up 8080, and it shows.</flamebait>
I kinda *like* PCI. Weirdest interrupt system I ever found, but
that's what keeps kernel workers happy. I wonder about IIO; it
just sounds like channel controllers all over again to me, and
a scheme to sell i960's. (Not to mention that OS...)
My favorite processor is the R3000. Pity Lynx doesn't support any
of the MIPS line anymore. And my least favorite is the Sparc line.
Register windows are the Spawn Of The Beast(TM). Especially when
it comes to predictable real-time performance. But there are major
companies out there using Sparc processors in (soft-ish) realtime
systems.
)
Armin Steinhoff
In article <5tif3u$1v8$1...@news.wizvax.net>, wil...@dbit.com says...
>>
>
>Uh ... I don't see how these two statements differ, unless you thought that
>by "response" I just meant "as opposed to no response", but what I meant
>was "guaranteed fast response".
>>Fast interrupt processing is a basic feature ...
>
>... which makes it real-time.
>
Fast response time is only a basic feature for predictable interrupt
processing ! ^^^^^^^^^^^
Here are some values about the interrupt handling of NT (Pentium 90):
Measurement Duration
Hardware Interrupt Latency 1.8 - 2.9 microseconds
Interrupt Dispatching 4.6 - 10.5 microseconds
Interrupt Service Routine Length 10.3 - 16.7 microseconds
Total Elapsed Time 16.7 - 30.1 microseconds
Impressive ? ... so NT must be a RTOS for you ??
Must something wrong in your picture about realtime systems ....
REAL TIME means at least there is a predictable deadline for the processing
of an interrupt event ! ^^^^^^^^^^^^^^^^^^^^
If it is real time ... it terminates deterministic after 200us or so ...
if it is NOT realtime it terminates in the time RANGE of 200us to 200ms !
>>the architecture of an RTOS is more important !!
>
>... which is a religious issue (i.e. you like it because you like it and
>no one can sway you). So we agree -- great!
Nonsens ... take a look to the architecture of Lynx. It is based on
old old Unix ideas ... plan9 and inferno are in meantime the newer
concepts of the Unix guys :-))
However, visit the RTOS homepage of the IEEE. There are many links to
completely different OS architectures, very interesting and of
cause ... make a some comparisons:
http://cs-www.bu.edu/pub/ieee-rts/Home.html --> IEEE
>>It's a piece of logic that a bigger program contains more bugs ...
>>look to WinNT :-)) There are also differences in the hardware
>>architectures ...
>
>Saying bigger programs have more bugs than smaller programs with all other
>variables being equal makes sense, but those other variables are rarely
>anywhere near equal. The number of bugs in a kernel has more to do with
>the skill that went into writing it, than the overall size.
That's really a very optimistic view ....
> Microsoft has produced plenty of SMALL bug-ridden products too!
Really ?? :-))
>Anyway I'm a little vague on the benefits of having protection in micros
[ clip ..]
>them back.
Well, Linux and handling problems ....
[clip ..]
Armin Steinhoff
http://www.steinhoff.de
Dan Hildebrand
In article <01bcaf2e$c5557600$21b7...@owl.infomarket.ru>,
Igor N Kovalenko <in...@mail.wplus.net> wrote:
>nospam-...@pobox.com wrote in article <33fac...@news.tsoft.net>...
>
>> Well, why are you biased? What do you like about LynxOS? I'm
>> interested to hear. Some things you might comment on.
>>
>> * Quality of the OS, compilers, utilities, technical support
>> * Availability of 3rd party products
>> * Support for hardware
>> Standard items like disk controllers, network cards, and video cards
>> Exotic stuff like A/D and Video Capture
>> * Price
>
>
>1. There are more drivers, but less 3rd party products and ported freeware.
I would contend that QNX has more drivers. :-)
>2. Prices are higher for development, but cheaper for incorporation.
My impression is that QNX development systems are less expensive, and that
we compete for runtime pricing.
>3. You can get *the source*.
Only if you purchase a source license. We can be approached for a source
license as well, but our microkernel architecture allows lots of OS
extensions to be done without requiring access to the source, and this
tends to minimize the need for access.
>4. Unix compatibility is *much* better (as this is U**x kernel).
Lynx is written from scratch, as is QNX. Neither is derived from U**x
source code.
>5. It is probably closest competitor for QNX (IMHO).
Perhaps. :-)
>6. comp.os.lynx is almost silent. Not a good sign, IMHO.
>
>The (3) point is extremely good for extremely mission critical systems. I
>did not read Lynx license agreement, but one from QSSL denies usage of QNX
>in life support systems. Heh, can someone from QSSL comment this?
We routinely make our source code available under various escrow agreements
to people building mission critical systems. Regarding life support
systems, this all comes down to the developers certifying the end
application and not us. It's a common licensing clause.
Armin Steinhoff
In article <5tkpis$e...@qnx.com>, da...@qnx.com says...
>
>In article <01bcaf2e$c5557600$21b7...@owl.infomarket.ru>,
>Igor N Kovalenko <in...@mail.wplus.net> wrote:
>>nospam-...@pobox.com wrote in article <33fac...@news.tsoft.net>...
>>
>>> Well, why are you biased? What do you like about LynxOS? I'm
>>> interested to hear. Some things you might comment on.
>>>
>>> * Quality of the OS, compilers, utilities, technical support
>>> * Availability of 3rd party products
>>> * Support for hardware
>>> Standard items like disk controllers, network cards, and video cards
>>> Exotic stuff like A/D and Video Capture
>>> * Price
>>
>>I don't know much about Lynx, just a few impressions (which may be wrong):
>>
>>1. There are more drivers, but less 3rd party products and ported freeware.
>
>I would contend that QNX has more drivers. :-)
Well, just read in comp.os.lynx ....
/Hello,
/A friend of mine who is using Lynx has told me that there does not appear to
/be a NE2000 compatible network card driver included with Lynx. Has anybody
/written one or know where one is available from ?? Please reply via e-mail as
/I rarely have time to read the newsgroups.
/Thanks.
/Jeremy Randle
I wonder if they have FDDI and ATM support ... not mentioned fieldbuses :-)
Armin Steinhoff
http://www.DACHS.net
Mike Davies
In article <5tkpis$e...@qnx.com>, Dan Hildebrand <da...@qnx.com> writes
.... big snip .....
>>The (3) point is extremely good for extremely mission critical systems. I
>>did not read Lynx license agreement, but one from QSSL denies usage of QNX
>>in life support systems. Heh, can someone from QSSL comment this?
>
>We routinely make our source code available under various escrow agreements
>to people building mission critical systems. Regarding life support
>systems, this all comes down to the developers certifying the end
>application and not us. It's a common licensing clause.
>
Certifying the application is something that all developers must
obviously do for themselves. It seems to me that the QNX OS structure
(discrete modular kernal / process handler / file-systems etc) lends
itself better than most to QSSL certifying it .
My interest would be in aviation certification, not life-support, though
it amounts to the same thing really :-)
--
Mike Davies