Solaris Hard Real-Time???

Solaris Hard Real-Time???

Post by Alcl » Sat, 29 Mar 1997 04:00:00



We are engaged in an argument as to whether or not Solaris on Sparcs can
really support "hard" real-time.  We want to architect a system composed
of background off-the-shelf processes (e.g. RDBMSs, HTML browsers)
overlaid with selected data acquisition processes which have hard
requirements, the worst of which is a moderate 20 ms.

As a note, by "hard" real-time, I mean processes which have dispatch
deadlines which must be met.  In our case, data acquisition hardware must
be responded to or it will become discombobulated.  This also implies that
priority inversion problems have been worked such that the higher priority
processes don't get hung up by lower ones due to shared semaphores and the
like.

Our researches so far (newgroup searches, SunSoft documentation searches,
urban legends) indicate that Solaris 2.5 (we have 2.5.1) does support hard
real-time, and also supports fully (??) the POSIX threads and real-time
extensions.

Can anyone comment on these seemingly positive results?  Does anyone have
any benchmarks concerning interrupt service / dispatch latency for
real-time priorities on Sparc 20 or Ultra platforms?  Any pointers to
relevant docs available?

Any comments, positive or negative would be appreciated.  We're going to
setup and run benchmarks on a set of networked Ultras, but have no
guarantee we'll find all the dispatches bugs.  


 
 
 

1. Hard real-time guarantees

[Newsgroups trimmed]


There are many facets to what people lump together as 'real time'
requirements.  Some applications require guaranteed response to
external input in a minimum time.  Some applications can cope
with delays, but require long uptime.  In some cases mis-operation
is far worse than delays.  It all depends.

For real guaranteed responses, do it in hardware.

For hard real time (i.e. guaranteed minimum response time) you need
to go with a real time kernel, like pSOS or vxWorks. They
publish, in writing, context switch and interrupt latency times.
But then you need to write your entire app to also respect
these esp. interrupt latency.

If you can let up on the response time a bit, you can start
to look at hybrid systems like QNX or 0S-9000 (Or the RT
package for Linux).  Here you
get a unix-like ienvironment on top of a rt core.
But you are still at the mercy of an IDE device driver writer
saying to himself "I'll just turn off interrupts for a little
bit here".  This is a very real issue with, for example,
using the RT linux package with IDE drives.

There was a Circuit Celler Ink article about RT and Win NT, but
I didn't read it.

Remember -- murphy is very much involved with rt systems:
If anything can go wrong, it will.  They run so fast for so long
that if there is the tinyiest possibility that several thing
will happen at just the right time to crash things -- they will.

So the answer is, it all depends.

-- cary

2. Need help PS/2, three button mouse

3. Real-time process and Solaris

4. write to a directory

5. enabling real-time for solaris 2.3

6. sun dkinfo command question

7. Real-Time and Solaris 2.3

8. SMC EtherEZ Interrupt Changes?

9. Solaris real-time thread capabilities

10. Solaris real-time???

11. Real-time performance of Solaris 7

12. Solaris 2.3 real-time info

13. Solaris Real-Time Support