LynxOS vs Linux
Nils Tore Sandstoe
I'm currently using Linux, but we are considering changing to LynxOS
What are main different between these two OSs??
NTS
Miles Davies
What is the difference between chalk and cheese ?
One is a real time POSIX compliant operating system (LynxOS), the other is
not.
One is FREE (Linux), the other is not.
If you do not want hard real-time, which I would doubt if Linux serves
your purpose, stick with the free one.
Nils Tore Sandstoe <tsan...@online.no> wrote in article
<33E53A4E...@online.no>...
S Ramraj
Nils Tore Sandstoe wrote:
>
> I'm currently using Linux, but we are considering changing to LynxOS
> What are main different between these two OSs??
>
> NTS
I can think the following :
----------------------------------------------------------------------
Linux LynxOS
----------------------------------------------------------------------
Linux is not a Realtime OS. LynxOS is a realtime OS
Linux filesystem is different LynxOS file system is fast
linked file system (FLFS)
Linux is not fully preemptable LynxOS is fully preemptable
Linux is not a multi-threaded kernel LynxOS is multithreaded kernel
and isr is servised normally by a
thread
-----------------------------------------------------------------------
--
-----------------------------------------------------------------------------
S Ramraj | 408-879-3900 x 149
Lynx Real Time Systems | email : ram...@lynx.com
2239 Samaritan Drive, | ... Live to learn and then learn to live
San Jose, CA - 95124. | Give to earn and then earn to give ...
------------------------------------------------------------------------------
Wolfgang Denk
I tried to keep my mouth shut, but I cannot :-(
S Ramraj <ram...@lynx.com> writes:
>I can think the following :
>----------------------------------------------------------------------
>Linux LynxOS
>----------------------------------------------------------------------
>Linux is not a Realtime OS. LynxOS is a realtime OS
...but has better general performance,
much more effcient memory management,
provides mmap() on files, ...
Even for critical things like context switches I have run tests where
Linux (2.0.22) was more than twice (!) as fast as LynxOS (2.5.0 FCS,
both on the same Sparc LX). Ok, Linux is not RT...
>Linux filesystem is different LynxOS file system is fast
> linked file system (FLFS)
The Linux I/O system outperforms LynxOS
>Linux is not fully preemptable LynxOS is fully preemptable
>Linux is not a multi-threaded kernel LynxOS is multithreaded kernel
> and isr is servised normally by a
> thread
Umm... sure?
Ok, let's add some more items:
Linux has full source code for free. You have to pay a lot to see
LynxOS sources.
On Linux, you have ELF binary format which makes Shared Libraries a
piece of cake.
On the PC, Linux has much better support for different hardware
(device drivers for nearly everything).
On Linux, you can compile nearly every piece of software without any
problems.
Please do not understand me wrong: I am using LynxOS as well (and
even in a *big* project), and I'm quite happy with it.
But if there is no need for hard realtime, then today there are very
few reasons not to go the Linux way - and the poster who asked the
question was already using Linux and thinking about a change. For him
it should be VERY easy...
Sorry Lynx, but as a GENERAL development environment Linux is much
more comfortable, both from the tooling and from the performance
point of view.
Wolfgang Denk
Office: (+49)-89-722-27328, Fax -36703 w...@uebemc.siemens.de
Private: (+49)-89-95720-110, Fax -112 w...@denx.muc.de
In C we had to code our own bugs, in C++ we can inherit them.
Thomas Mueller
Vik Sohal wrote:
>>
>> I tried to keep my mouth shut, but I cannot :-(
>>
Me neither ;-)
>
> lots of good points removed....
>Linux certainly has many advantages from a general purpose OS standpoint
>over LynxOS, but make no mistake, it is a public domain product,
>supported by people who work on it in their spare time. LynxOS, on the
>other hand is maintained by a lot of dedicated people who work very hard
>to ensure that it remains the best real-time OS in the industry.
Well some of the volunteers seem to have a lot of spare time if
we consider the quality of most free software.
> Overall Linux is the result of a distributed development effort. This
> has its plusses and minuses. Wolfgang has already pointed out the
> plusses, but consider the minusses:
> - No central point of contact to effect changes to the source tree for
> fixes or enhancements.
> - Lots of "stuff" that you must consider when building a configuration
> for deployment. Indeed, LynxOS is far more configurable than Linux in
> this regard, especially with the MasterLynx configuration system.
> - No central group of people working to ensure that the overall
> robustness of the system is kept high.
If we consider another OS availabe as free software (FreeBSD), then all
these three points are fulfilled (check out http://www.freebsd.org/).
(please, this is not a flame bait for yet another 'Linux vs.
the rest of the world' discussion).
--
Thomas Mueller Systrix CS GmbH
Ulrich Hoffmann
In <33EA4A...@lynx.com> Vik Sohal <v...@lynx.com> writes:
> As a response to your allegations about various performance issues,
> remember, context switch time is not a measure of real-time response,
> worst case task response time is. I am quite certain that for real-time
> we beat Linux hands-down.
It would be nice, if you could comment on those efforts pushing
Linux into the realtime/scalable/embedded direction as are done
by the (Sub-)projects:
- RT-Linux (http://luz.cs.nmt.edu/~rtlinux/),
- Linux-Threads (http://pauillac.inria.fr/~xleroy/linuxthreads/), or
- Embeddable Linux Kernel Subset (http://www.uk.linux.org/Linux8086.html).
I read about those projects but find it hard to compare their characteristics
with those LynxOS can offer.
Greetings,
Ulrich
--
Ulrich Hoffmann, Uni Kiel http://www.informatik.uni-kiel.de/~uho/
Institut f. Informatik, u...@informatik.uni-kiel.de
Preusserstr 1-9, D-24105 Kiel, Germany Tel: +49 431 560426 Fax: 566143
Wolfgang Denk
It seems that I missed some important topics in my previous posting;
I definitely didn't want to start a "my unix vs. you unix" war
here...
Vik Sohal <v...@lynx.com> writes:
>Linux certainly has many advantages from a general purpose OS standpoint
>over LynxOS, but make no mistake, it is a public domain product,
>supported by people who work on it in their spare time...
Point taken. Of course you are right. Especially if you are working
for a big company, or follow some strict work procedures like ISO
9000 it will be EXTREMELY difficult to use Linux because "there is
nobody responsible for the product".
> ... LynxOS, on the
>other hand is maintained by a lot of dedicated people who work very hard
>to ensure that it remains the best real-time OS in the industry.
Well, credit where credit is due: I can summarize our experiences
with Lynx in this respect very shortly: they are extraordinary well.
We had lots of requirements not available in the 2.4 and 2.5.0
releases of LynxOS (for instance we need massive support for C++
shared libraries). The most outstanding fact about Lynx is that I
*never* just got a commitment from some marketroid. Everything was
technically clean, and so far they *always* delivered on schedule.
For some mission critical features for us they even delivered a full
month AHEAD of schedule, and I know that their schedule really was
tight.
Technical support is very good, too. If I compare to other vendors
the biggest difference is that they really SOLVE problems and fix
things. Even difficult ones.
>As a response to your allegations about various performance issues,
>remember, context switch time is not a measure of real-time response,
>worst case task response time is. I am quite certain that for real-time
>we beat Linux hands-down.
I think nobody will put this in question. There is a whole a list of
issues where LynxOS is just the right choice: real-time, embedded
systems, truely scalable kernels just to name a few. Guess why we are
running LynxOS here?
And Dorr H. Clark <dhc...@crl4.crl.com> writes:
> So, to address the original question, are there aspects of your project
> that recommend an RTOS? Is embeddability an issue? Do you need to
> boot out of PROMs? Do you have stringent performance requirements?
> Do you need a quick reboot cycle? Would your customers ever ask
> for a cutting edge powerpc solution? A diskless system? There are
> many engineering criteria which might immediately recommend LynxOS.
>
> There are also business considerations as well. For many tasks both
> technical solutions are plausible, but if at least some of your
> customers are institutions then commerical support is a critical
> issue and LynxOS is the way to go.
Thanks for bringing this to the point. I wholeheartedly agree.
Wolfgang Denk
Office: (+49)-89-722-27328, Fax -36703 w...@uebemc.siemens.de
Private: (+49)-89-95720-110, Fax -112 w...@denx.muc.de
Do not follow where the path may lead....go instead where there is no
path and leave a trail.
Wes Peters
Miles Davies wrote:
Nils Tore Sandstoe asked:
% I'm currently using Linux, but we are considering changing to LynxOS
% What are main different between these two OSs??
Miles Davies replied:
> What is the difference between chalk and cheese ?
>
> One is a real time POSIX compliant operating system (LynxOS), the other is
> not.
> One is FREE (Linux), the other is not.
>
> If you do not want hard real-time, which I would doubt if Linux serves
> your purpose, stick with the free one.
There is a freely available real-time kernel, called RTEMS, available
as well. It does not have all of the features of a product like LynxOS,
but certainly is worth looking into. Search for RTEMS using a search
engine like Alta Vista or Yahoo.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters
Softweyr LLC
soft...@xmission.com
http://www.xmission.com/~softweyr
Hiro Sugawara
In article <33FC1343...@rtusi.com>, laurent <lau...@rtusi.com> wrote:
> Wes Peters wrote:
>
> > Miles Davies wrote:
> > Nils Tore Sandstoe asked:
> > % I'm currently using Linux, but we are considering changing to LynxOS
> >
> > % What are main different between these two OSs??
> >
> > Miles Davies replied:
> > > What is the difference between chalk and cheese ?
> > >
> > > One is a real time POSIX compliant operating system (LynxOS), the
> > other is
> > > not.
>
> You can fing RT-Linux at http://luz.cs.nmt.edu/~rtlinux/
Visited the site. Not impressive at all. RT-Linux essetially inserts a
tap layer between the hardware and the regular Linux kernel. Virtually
everything is done by directly communicating with the hardware. If my
understanding is correct, no file systems, no memory protection, no
nothing. It's more like a "resident monitor" and the regular Linux
kernel is just one of its available tasks and a real-time task is just
another one with a higher priority. You cannot write a real-time
"application program." Any real-time task seems to have to be a module
linked with the kernel. Hmmm... It's like XINU. Actually, the presence
of the Linux kernel does not seem necessary.
The idea is similar or identical to the one I recall Hitachi developed
about 15 years agoin which a real-time kernel runs a Unix kernel as one
of its tasks. I also recall that AT&T ported a Unix kernel about the same
time on top of an IBM main frame kernel.
On RT-Linux, can you
write a stand-alone application "program"?
let real-time application tasks communicate with each other through
standard IPC's?
access file systems from a real-time task?
let a real-time task communicate over a network?
debug an application task without risking a system crash?
reliably update a real-time task module without rebooting?
all of which LynxOS can in a very Unix fashion.
Please correct me if I'm worng, but I don't see any point in comparing
RT-Linux with LynxOS.
hiro
--
Hiro Sugawara
Remove "nospam" when replying
laurent
Wes Peters wrote:
> Miles Davies wrote:
> Nils Tore Sandstoe asked:
> % I'm currently using Linux, but we are considering changing to LynxOS
>
> % What are main different between these two OSs??
>
> Miles Davies replied:
> > What is the difference between chalk and cheese ?
> >
> > One is a real time POSIX compliant operating system (LynxOS), the
> other is
> > not.
> > One is FREE (Linux), the other is not.
> >
> > If you do not want hard real-time, which I would doubt if Linux
> serves
> > your purpose, stick with the free one.
>
> There is a freely available real-time kernel, called RTEMS, available
> as well. It does not have all of the features of a product like
> LynxOS,
> but certainly is worth looking into. Search for RTEMS using a search
> engine like Alta Vista or Yahoo.
>
> --
> "Where am I, and what am I doing in this handbasket?"
>
> Wes Peters
> Softweyr LLC
> soft...@xmission.com
> http://www.xmission.com/~softweyr
You can fing RT-Linux at http://luz.cs.nmt.edu/~rtlinux/
Laurent Uhres
L.U...@rtusi.com
Philippe Le Foll
Wes Peters wrote:
>
> Miles Davies wrote:
> Nils Tore Sandstoe asked:
> % I'm currently using Linux, but we are considering changing to LynxOS
> % What are main different between these two OSs??
>
> Miles Davies replied:
> > What is the difference between chalk and cheese ?
> > One is a real time POSIX compliant operating system (LynxOS), the other is not.
> > One is FREE (Linux), the other is not.
> >
> > If you do not want hard real-time, which I would doubt
> > if Linux serves your purpose, stick with the free one.
I currentely build a realtime application and we plane using Linux
with it realtime extentions. It is true that it is not POSIX compiant
for realtime entry point (it is for everything else including threading)
With tests I made my first conclusion is:
-Realtime performance under Linux are excelent
-Software developement facilities for realtime are weak
To give more information on my problem, I have to build a video
application, and LynxOs can't be use because of it disk limitation.
We need a filesystem beween 8 and 20MB and LynxOs is limitted to 2MB.
Further more I need 12.5MS/s of application troughtput Linux provide
15.5MB/s with an ordinary Adapted bord and it Raid0 kernel driver.
In this situation Linux fit and Lynx does not.
>
> There is a freely available real-time kernel, called RTEMS, available
> as well. It does not have all of the features of a product
> like LynxOS, but certainly is worth looking into.
> Search for RTEMS using a search
> engine like Alta Vista or Yahoo.
>
You will find RTEMS on cygnus ftp site, nevertheless RTEMS is a very
raw realtime kernel imagine VxWorks with no debugger, no loader,
no netwotk, no BSP, ... If you don't pay ingeenering time it is a very
nice solution.
Note: You can also look for QNX if you don't need RISC plateform.
Philippe Le Foll
yoda...@cs.nmt.edu
In article <hiro-21089...@172.16.1.19>,
hi...@nospam.arkusa.com (Hiro Sugawara) wrote:
> > You can fing RT-Linux at http://luz.cs.nmt.edu/~rtlinux/
>
> tap layer between the hardware and the regular Linux kernel. Virtually
> everything is done by directly communicating with the hardware. If my
> understanding is correct, no file systems, no memory protection, no
> nothing.
Your understanding is not correct. RT-Linux real-time
tasks access the file system via linux processes which
run with normal memory protection etc.
It's more like a "resident monitor" and the regular Linux
> kernel is just one of its available tasks and a real-time task is just
> another one with a higher priority. You cannot write a real-time
> "application program."
I'm not sure what you mean by this. If you mean that
to run a real-time program you need both kernel level and
user level components, then you are correct.
>Any real-time task seems to have to be a module
> linked with the kernel. Hmmm... It's like XINU. Actually, the presence
> of the Linux kernel does not seem necessary.
Modules are run-time loadable in Linux. And the Linux
kernel is necessary for any but the simplest RT tasks.
> The idea is similar or identical to the one I recall Hitachi developed
> about 15 years agoin which a real-time kernel runs a Unix kernel as one
> of its tasks.
Do you have a reference?
>I also recall that AT&T ported a Unix kernel about the same
> time on top of an IBM main frame kernel.
You may be thinking of MERT. But that was very different.
> On RT-Linux, can you
> write a stand-alone application "program"?
What do you mean by "stand-alone"? You cannot write a
program that runs without the OS on RT-Linux, but that's
hardly unique to us.
> let real-time application tasks communicate with each other through
> standard IPC's?
No. I don't see any need for this slow and inherently
non real-time mechansism.
> access file systems from a real-time task?
Via Linux processes and the fifos.
> let a real-time task communicate over a network?
Same as above.
> debug an application task without risking a system crash?
RT modules run in kernel mode so they can crash the system.
Since most RT applications involve direct control of some
hardware, it seemed pointless to sacrifice performance here.
> reliably update a real-time task module without rebooting?
This is standard for Linux modules.
> all of which LynxOS can in a very Unix fashion.
>
> Please correct me if I'm worng, but I don't see any point in comparing
> RT-Linux with LynxOS.
I'd find it quite educational to hear what people found
hard or easy in LynxOS compared with Linux.
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Boris Vaysburg
yoda...@cs.nmt.edu wrote:
>
......
>
> > let real-time application tasks communicate with each other through
> > standard IPC's?
>
> No. I don't see any need for this slow and inherently
> non real-time mechansism.
>
The above seems wrong to me. In pretty much any real time system you
will need IPC mechanisms. Using the standard IPC mechanisms is not
necessarily slow and non non-RT.
Using standard IPC mechanisms versus proprietary mechanisms increases
reusability and will help you in moving from one platform and OS to
another.
I don't see anything in the way standard IPCs like message queues and
fifos
are defined that prevents them from satisfying real-time requirements.
If I had a choice between standard and proprietary IPC mechanisms, I
would
go with the standard. There are situations, of course... It is all
driven by
your requirements. Standard mechanisms do tend to be slower, but they
are
supported by more systems which makes it easier to develop, test, and
maintain,
driving your overall cost down in a long run.
> > access file systems from a real-time task?
>
> Via Linux processes and the fifos.
Can an RT process access a file system directly or does it have
to use a non RT process as a router for file system access? This
is what above seems to imply?
>
> > let a real-time task communicate over a network?
>
> Same as above.
>
> > debug an application task without risking a system crash?
>
> RT modules run in kernel mode so they can crash the system.
> Since most RT applications involve direct control of some
> hardware, it seemed pointless to sacrifice performance here.
>
All (maybe most) device drivers are RT, but RT does not mean device
drivers.
We have a lot of software that is RT and does not communicate
directly with hardware. As a matter of fact, there is, probably,
more software that has to run RT and not directly control a
hardware device.
It is very useful to be able to run RT processes separately from
the kernel so if they ever crash, the entire system will not be
affected.
This is good for general reliability.
Regards.
--
=========================================================
Boris Vaysburg (Boris_Vays...@email.mot.com)
Hiro Sugawara
In article <340F4DCB...@email.mot.com>, Boris Vaysburg
<Boris_Vays...@email.mot.com> wrote:
> If I had a choice between standard and proprietary IPC mechanisms, I
> would
> go with the standard. There are situations, of course... It is all
> driven by
> your requirements. Standard mechanisms do tend to be slower, but they
> are
> supported by more systems which makes it easier to develop, test, and
> maintain,
> driving your overall cost down in a long run.
--snip--
> It is very useful to be able to run RT processes separately from
> the kernel so if they ever crash, the entire system will not be
> affected.
> This is good for general reliability.
Boris presents another good point: Software cost--reusability,
developers' learning curve, ease of debugging, mantainability,
reliability, (and all other kinds of *abilities)--is far more
important than ever, while hardware costs become cheaper and cheaper.
In the good old days of Z80, when every memory bit cost a half cent,
fewer bytes immediately meant a better system. But today many
applications would gratefully allow doubling the hardware capacity if
the development cycle could be cut in half.
LynxOS employs the Unix process model with a POSIX thread extrension,
meaning clear separation and protection between processes and between
process and kernel spaces, and resulting in far more reliability and
much easier debugging of applications, while all processes (threads)
are still real-time.
POSIX conformance means software poratability: Applications developed
on Unix platforms can be easily ported to LynxOS to work as real-time
tasks.
This software cost issue seems to me to be becoming more and more
important as software complexity grows rapidly while time-to-market
demands are pressured more.
yoda...@cs.nmt.edu
> will need IPC mechanisms. Using the standard IPC mechanisms is not
> necessarily slow and non non-RT.
>
> Using standard IPC mechanisms versus proprietary mechanisms increases
> reusability and will help you in moving from one platform and OS to
> another.
BSD sockets, for example, are designed to allow for an enormous
degree of flexibility and to hide a very complex buffering system
from the programmer. That's wonderful, but it seems to me to be
incompatible with real-time. If you need that functionality, you
should not be using it from within a RT kernel.
> I don't see anything in the way standard IPCs like message queues and
> fifos
> are defined that prevents them from satisfying real-time requirements.
Sure. There is nothing necessarily non rt about messsage queues and
fifos, and they are available to rt-linux tasks. "Standard IPC" must
mean something different to me than it does to you.
> Can an RT process access a file system directly or does it have
> to use a non RT process as a router for file system access? This
> is what above seems to imply?
It must go via a non RT process. Again, the file system is very much
optimized for average case, as it should be. I don't see an advantage
for a direct connection between a RT task and such a system. Is there
one?
> All (maybe most) device drivers are RT, but RT does not mean device
> drivers.
> We have a lot of software that is RT and does not communicate
> directly with hardware. As a matter of fact, there is, probably,
> more software that has to run RT and not directly control a
> hardware device.
I'm not sure if most device drivers are RT. In our system most Linux
drivers run happily without real-time. I'm curious, however, to
get a general idea of how your, and other, rt systems are structured.
My experience is that many RT systems consist of 2% actual RT code
and a much larger body of code that is, at most, soft RT.
> It is very useful to be able to run RT processes separately from
> the kernel so if they ever crash, the entire system will not be
> affected.
> This is good for general reliability.
Sure. I'd like to add a mode to the system so that rt-modules would run
in their own address space for debugging. Unfortunately, current
generation processors impose a very large time penalty for changing
address space (via TLB and cache misses) so we currently sacrifice
safety for speed. In practice, this does not seem to be too unsafe and
it is quite fast.
Dan Hildebrand
In article <8734970...@dejanews.com>, <yoda...@cs.nmt.edu> wrote:
>
>> It is very useful to be able to run RT processes separately from
>> the kernel so if they ever crash, the entire system will not be
>> affected.
>> This is good for general reliability.
>
>Sure. I'd like to add a mode to the system so that rt-modules would run
>in their own address space for debugging.
This isn't good enough for many realtime applications (ie: mission
critical). While it may run in the lab, this doesn't address intermittent
failures in the field.
>Unfortunately, current
>generation processors impose a very large time penalty for changing
>address space (via TLB and cache misses) so we currently sacrifice
>safety for speed. In practice, this does not seem to be too unsafe and
>it is quite fast.
I think you're overstating the speed difference. Also, the phrase "too
unsafe" is very relative.
--
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
yoda...@cs.nmt.edu
In article <5v110v$3...@qnx.com>,
da...@qnx.com (Dan Hildebrand) wrote:
>
>
> In article <8734970...@dejanews.com>, <yoda...@cs.nmt.edu> wrote:
> >
> >> It is very useful to be able to run RT processes separately from
> >> the kernel so if they ever crash, the entire system will not be
> >> affected.
> >> This is good for general reliability.
> >
> >Sure. I'd like to add a mode to the system so that rt-modules would run
> >in their own address space for debugging.
>
> This isn't good enough for many realtime applications (ie: mission
> critical). While it may run in the lab, this doesn't address intermittent
> failures in the field.
software in the field is a solution.
> >generation processors impose a very large time penalty for changing
> >address space (via TLB and cache misses) so we currently sacrifice
> >safety for speed. In practice, this does not seem to be too unsafe and
> >it is quite fast.
>
> I think you're overstating the speed difference. Also, the phrase "too
> unsafe" is very relative.
I' like to get down to <10us response time and I don't see how
it can be done with a memory context switch. For the "relativity",
what absolute safety metric do you propose?
Dan Hildebrand
In article <8737995...@dejanews.com>, <yoda...@cs.nmt.edu> wrote:
>In article <5v110v$3...@qnx.com>,
> da...@qnx.com (Dan Hildebrand) wrote:
>>
>> In article <8734970...@dejanews.com>, <yoda...@cs.nmt.edu> wrote:
>> >
>> >> It is very useful to be able to run RT processes separately from
>> >> the kernel so if they ever crash, the entire system will not be
>> >> affected.
>> >> This is good for general reliability.
>> >
>> >Sure. I'd like to add a mode to the system so that rt-modules would run
>> >in their own address space for debugging.
>>
>> This isn't good enough for many realtime applications (ie: mission
>> critical). While it may run in the lab, this doesn't address intermittent
>> failures in the field.
>I'm not sure how a trapped memory fault in buggy mission critical
>software in the field is a solution.
A watchdog process can notice the failure of the buggy process and choose
one of:
a) restart that failed process
b) take down a few related processes and restart the set
c) performan a coordinated shutdown of the system
Optionally, when the process fails the system can write a memory image of
the failed process to some mass storage (a local disk, file system at the
other end of a network link, etc). With the right tools, you can
source-level inspect that memory image to determine why the system failed.
The end result is that the realtime system can stay up and running without
having something as clumsy as a hardware watchdog timer reset it from
scratch whenever it goes wrong.
The point of a mission critical system is to recognize that software
failures might occur and design the system as much as possible to survive
them in some intelligent way. Memory protection is one of several useful
tools for accomplishing this.
>> >generation processors impose a very large time penalty for changing
>> >address space (via TLB and cache misses) so we currently sacrifice
>> >safety for speed. In practice, this does not seem to be too unsafe and
>> >it is quite fast.
>>
>> I think you're overstating the speed difference. Also, the phrase "too
>> unsafe" is very relative.
>For the speed difference, it depends on what you are trying to do.
>I' like to get down to <10us response time and I don't see how
>it can be done with a memory context switch.
Are you saying you don't see how to get <10us response time in a memory
protected system?
>For the "relativity",
>what absolute safety metric do you propose?
There isn't an absolute metric, it comes down to using the resources
available within the hardware to best effect. My comment was intended in
imply that some designers would prefer to use memory protection whenever
the hardware provided support for it.
Victor Yodaiken
On 9 Sep 1997 12:46:43 GMT, Dan Hildebrand <da...@qnx.com> wrote:
>>I'm not sure how a trapped memory fault in buggy mission critical
>>software in the field is a solution.
>
>A watchdog process can notice the failure of the buggy process and choose
>one of:
>
>a) restart that failed process
>b) take down a few related processes and restart the set
>c) performan a coordinated shutdown of the system
I'm sure that this is important in some cases. However, I think that
in most cases a memory fault is an unrecoverable failure and
a watchdog timer in hardware or a reset button is your best bet.
If I was sending up a sattelite, I'd want separate address spaces. If
I was working out robot control algorithms, collecting data from an
experiment, or ... --- it would not be a major benefit as far as I can
see.
>Are you saying you don't see how to get <10us response time in a memory
>protected system?
Yes. Add up the costs for catch an irq, switch address space, take tlb
miss cost, take cache miss costs, run simple rt process, go back
--- on a P120 this starts to add up. If you used the segmentation
registers instead of the paging mechanism you might do better, but ...
>There isn't an absolute metric, it comes down to using the resources
>available within the hardware to best effect. My comment was intended in
>imply that some designers would prefer to use memory protection whenever
>the hardware provided support for it.
Sure. I think that RT is so varied and so poorly understood that
the correct answer is often "it depends".
---------------------------------
Victor Yodaiken
Department of Computer Science
New Mexico Institute of Mining and Technology
Socorro NM 87801
http://luz.cs.nmt.edu/~rtlinux
Dan Hildebrand
In article <slrn61lq35....@chelm.cs.nmt.edu>,
Victor Yodaiken <yoda...@chelm.cs.nmt.edu> wrote:
>On 9 Sep 1997 12:46:43 GMT, Dan Hildebrand <da...@qnx.com> wrote:
>>>I'm not sure how a trapped memory fault in buggy mission critical
>>>software in the field is a solution.
>>
>>A watchdog process can notice the failure of the buggy process and choose
>>one of:
>>
>>a) restart that failed process
>>b) take down a few related processes and restart the set
>>c) performan a coordinated shutdown of the system
>
>I'm sure that this is important in some cases. However, I think that
>in most cases a memory fault is an unrecoverable failure and
>a watchdog timer in hardware or a reset button is your best bet.
If, by "memory fault", you mean something like a process accessing memory
outside of it's allocated space or attempting to write to a read-only page,
then I disagree with you. While the *process* may be aborted by the OS,
from the perspective of the *system*, it is a recoverable fault. A
watchdog process can take some intelligent action and keep the "system"
running, something not possible without memory protection. Hence the
usefulness of memory protection in high-reliability realtime systems.
>If I was sending up a sattelite, I'd want separate address spaces. If
>I was working out robot control algorithms, collecting data from an
>experiment, or ... --- it would not be a major benefit as far as I can
>see.
If the MMU was already present in the CPU, and the system could easily meet
your performance requirements with the MMU enabled, are you saying that you
don't see the merit of enabling the MMU for robotic control applications?
Given the software complexity of robotic systems, and the incredible
expense incurred by their downtime, I would think you should insist on
memory protection.
>>Are you saying you don't see how to get <10us response time in a memory
>>protected system?
>
>Yes. Add up the costs for catch an irq, switch address space, take tlb
>miss cost, take cache miss costs, run simple rt process, go back
>--- on a P120 this starts to add up. If you used the segmentation
>registers instead of the paging mechanism you might do better, but ...
We're finding the key to better performance is to avoid the segmentation
registers. The PentiumPro and Pentium II incur pipeline stalls whenever
you modify a segment register.
>>There isn't an absolute metric, it comes down to using the resources
>>available within the hardware to best effect. My comment was intended in
>>imply that some designers would prefer to use memory protection whenever
>>the hardware provided support for it.
>
>Sure. I think that RT is so varied and so poorly understood that
>the correct answer is often "it depends".
Absolute agreement.
Noah J. Cowan
Steve Watt wrote:
> Adaptec 1542, good luck. A 2942, on the other hand, should work fine.
> And I thought Linux didn't support the 2900 series Adaptecs? Or did
> I misunderstand something?
I'm using an adaptec 2940, and it works great under linux.
--
-----------------------------------------------------------------------
| Noah J. Cowan * University of Michigan * Department of Electrical |
| Engineering: Systems Division * Title: GSRA * Office: (313)936-2830 |
| Lab: (313)763-1572 * http://www.eecs.umich.edu/~ncowan/ * Go Bucks! |
-----------------------------------------------------------------------
eager...@gmail.com
> >Linux certainly has many advantages from a general purpose OS standpoint
> >over LynxOS, but make no mistake, it is a public domain product,
> >to ensure that it remains the best real-time OS in the industry.
Linux is not public domain. It is Open Source and distributed under the GPLv2 license.
The majority of people who work on Linux, especially the kernel, are employed to do so full time, not working on it as a hobby in their spare time. Contributors work for IBM, RedHat, Google, Intel, Nokia, and hundreds of other companies.
I don't know whether LynxOS is the "best reat-time OS in the industry," I'm sure that others make similar claims. I do know that there are many more people who work on Linux development than are employed at LynxWorks, perhaps by two orders of magnitude.
Steve Watt
<eager...@gmail.com> wrote:
>Subject: Re: LynxOS vs Linux
>From: eager...@gmail.com
>Injection-Date: Sun, 08 Sep 2013 15:26:37 +0000
>> Vik Sohal wrote:
>> >Linux certainly has many advantages from a general purpose OS standpoint
>It's fine to promote your company's product and trash talk Linux (including Blue Cat Linux?) but let's keep to the facts.
Wow. This has to be some kind of new record. A followup to a post a mere 16 years old.
Wait, it's September, isn't it? Been a long time...
--
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...
himanshu...@gmail.com
s...@amritahyd.org
s...@amritahyd.org
tpl...@gmail.com
> I'm currently using Linux, but we are considering changing to LynxOS
>
Nearly 20 years old and I found this post quite useful...and funny. Especially when watching the Linux-fanboys come out swinging at perceived slights. Linux is certainly flat-out awesome, but the two products in question serve two completely different problem domains. They are almost nothing alike. Oh wait, they do both support the bash shell.
