| |||||||||||||
Hard and soft real timeHard and soft real timePosted Nov 4, 2010 9:36 UTC (Thu) by csimmonds (subscriber, #3130)Parent article: KS2010: Deadline scheduling
Seems that the discussion at the summit went off on a bit of a tangent. Playing a video stream is a classic example of a soft real time system: there are deadlines but nothing bad happens if you miss them some times, and as Linus pointed out in most cases the behaviour people want is best effort, but try harder in this case.
With hard real time, you must not miss the deadline ever. An example of a system I have worked on recently: printing sell-by dates on bottles going along a production line. If one bottle is not printed the whole production line has to be halted, the problem fixed and then restarted, which is very expensive. This is hard real time.
You can achieve hard real time behaviour with a priority based scheduler, but it is not easy. Much better to use a deadline scheduler which gives you the guarantees that you want. So, I vote very energetically for inclusion of the deadline scheduler. It may not be useful on the desktop or server, but that is a small part of what Linux does.
Chris.
(Log in to post comments)
Hard and soft real time Posted Nov 4, 2010 13:34 UTC (Thu) by zmower (subscriber, #3005) [Link]
I was watching videos from the Ada conference the other day. They were considering multicore processors and it seems that the interaction between the processors and various caches is such that these systems can no longer be considered to be predictable. One speaker even went so far as to say "Hard realtime is dead" which got a few lighthearted boos!
So would you like to change your statement to embedded hard realtime on unicore processors is a very small part of what linux should do?
Hard and soft real time Posted Nov 4, 2010 15:36 UTC (Thu) by Shewmaker (subscriber, #1126) [Link]
Research into optimal real-time multiprocessor scheduling is not dead.
Here's a well written paper from this year.
DP-FAIR: A Simple Model for Understanding Optimal Multiprocessor Scheduling
A short overview presentation of that paper.
This same research group is also working on solving the other parts of the problem. Linus is correct, we can't solve these problems with just CPU scheduling.
Efficient Guaranteed Disk Request Scheduling with Fahrrad (2008)
Work on memory and network resources is in earlier stages, but the result will hopefully be a coherent general theory of real-time performance management.
Hard and soft real time Posted Nov 4, 2010 20:15 UTC (Thu) by zmower (subscriber, #3005) [Link]
I think this falls into the category of too simple models. In particular I would questions the assumptions that tasks are independent and that there's no cost overhead in context switches or CPU migrations. Would that it were so easy.
As for linux, even if you have optimal scheduling for all the subsystems, the combined effect is still chaotic.
Ada conference videos etc here http://www.disca.upv.es/jorge/ae2010/outcome.html
Hard and soft real time Posted Nov 4, 2010 19:20 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
but even with hard-real-time work, most of the situations allow you to miss a deadline once in a while. If your production line has to be stopped daily or hourly, you can't accept it, but if it stops once a year because the deadline was missed, that's probably acceptable.
you could also have a hard-real-time task that has a 5 second deadline to get the task done. non-real-time linux can accomplish that today (except in the face of failing hardware)
even things with fairly short deadlines can be made statistically reliable in many cases. It's only when you start getting into extremely short deadlines or systems that also handle non-critical processes that compete for resources that you start having real problems.
"hard" real-time Posted Nov 4, 2010 20:06 UTC (Thu) by dmarti (subscriber, #11625) [Link] "Hard" real-time is where if you miss a deadline, the robot chops off the user's head, or the user's plane crashes.
"hard" real-time Posted Nov 4, 2010 20:37 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
even in the case of aircraft, missing one deadline does not make the plane crash. having the system lock up will make the plane crash, making the system miss deadlines too badly, or too frequently may make the plane crash.
there are _very_ few situations where a single missed deadline proves fatal to the system (or the user :-)
in engineering, the assumption is that you may have unexpected loads, or you may have sub-par materials, so every design includes a safety margin, which means that they make it statistically unlikely that too many things will go wrong and the item will fail.
Even on the Space Shuttle, something as critical as the heat resistant tiles are not individually critical, it's expected that some number of them will be damaged or fall off on any flight. When too many of them get damages, you have the Columbia disintegrating, but that doesn't translate into zero tolerance of tile failure
"hard" real-time Posted Nov 4, 2010 22:26 UTC (Thu) by csimmonds (subscriber, #3130) [Link]
We seem to be getting off the topic here. The point is that Linux is used in real-time applications - I have worked on several myself. Real time is about determinism and deadlines, and typically there are a range of acceptable behaviours. Dead line scheduling is a valuable tool in designing systems that have to meet deadlines (in essence, it makes the analysis easier). So, it would make sense to have such a scheduler as an option in the Linux. People seem to be arguing against improving the kernel, and I don't understand why.
Chris.
|
|||||||||||||