On Thu, 2010-09-16 at 08:27 -0700, Nivedita Singhvi wrote: > Steven Rostedt wrote: > > > Hardware that is less complex is easier to mathematically prove that it > > will do what you expect to do in all cases, than hardware that is over > > engineered, just like software. > > > > I hold that PREEMPT_RT is not soft real time, but is hard real time > > designed. That is, we can't prove that it is hard real time, but any > > time we find a case that the software can break its deterministic > > result, it is a bug and needs to be fixed. (aka, a system failure). > > Which serves to highlight my point about using these terms -- you're > the terms "hard" and "soft" in a different way than a previous poster. > (Assuming "hard real time designed" can get mistaken for "hard real time". Hard and soft are relative terms. > > You're saying it's hard because we intend it to meet system deadlines > (regardless of deadline??), and it's a bug if it doesn't. heh, no. The "regardless of deadlines" was not what I meant. I meant "we have determined that the worse case runtime is X+delta, and if we run within that time the system works". The deadlines are determined at system design based on the hardware and software used. If you can not make a deadline at design time, you go back to the drawing board. It's all about determinism. > > The previous poster in this list was using it to imply guarantees of > of very specific response times (< xxx us). > > You really, really have to talk about the specifics of the environment, > the requirements, the application needs, etc. And I'm missing about > half a dozen "really"'s there. Note, I'm not sure you implied that vanilla Linux being fast enough can be considered "real-time" for long deadlines. If that's the case, it is wrong. A simple classic case of priority inversion will cause the system to fail no matter how long the deadlines are. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
