21 Feb
2006
21 Feb
'06
10:02 p.m.
On Tue, 2006-02-21 at 20:49 -0500, Lee Revell wrote:
On Tue, 2006-02-21 at 19:30 -0600, Jan Depner wrote:
I beg to differ. Hard real-time guarantees the response time. Most
good hard real-time systems actually do respond in the 10-15 microsecond
range (though that is not a requirement of hard real-time). Theory has
no place in hard real-time. Check with Monta Vista and see if they
think the kernel with RT patches is hard real-time.
--
Jan 'Evil Twin' Depner
The Fuzzy Dice
http://myweb.cableone.net/eviltwin69/fuzzy.html
"As we enjoy great advantages from the invention of others, we should be
glad of an opportunity to serve others by any invention of ours, and
this we should do freely and generously."
Benjamin Franklin, on declining patents offered by the governor of
Pennsylvania for his "Pennsylvania Fireplace", c. 1744
On Tue, 2006-02-21 at 15:28 -0500, Lee Revell
wrote:
Hard RT is not about what the response time is, it's about whether you
can guarantee to make some arbitrary deadline, which the -rt patch can
theoretically do (I say theoretically because you still would have to
audit a limited set of code paths for RT safeness).
On Tue, 2006-02-21 at 13:19 -0600, Jan Depner
wrote:
While I agree that it's very good it's not hard real-time. It can't
do guaranteed 15 microsecond interrupt response. It is a very good soft
real-time system.
There's a bunch of information on that on my
site (albeit outdated).
Tuning the disk drives is a must and it *will* help but there are
instances where the disk drive is busy and you can't get to it no
matter
how well tuned it is. I prefer to minimize any chance of that. You
have to remember that unless you're running RTLinux or VXWorks (or DOS
or VMS) you're not running a hard real time system. Shit happens.
The -rt kernel with fuill preemption actually is a hard real time system
(no one claims it is in the same league of reliability as QNX or
VXWorks, yet...) - it should be able to guarantee response times.