Re: [vox-tech] real time in linux
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [vox-tech] real time in linux
There are a couple of levels of realtime. Hard realtime applications
are ones where the system will _fail_ if some or all of the tasks
cannot start and complete within a certain time frame. An example of
this type of application is a robot with a moving arm. If it isn't
told to stop soon enough it will destroy something.
Soft realtime applications are ones, where the information is
degraded if the deadlines are missed. This is usually a data
collection or interpretation type application. If you are taking
temperature readings every 20 milliseconds being a millisecond
off could degrade the informations usefulness.
For realtime applications you need to know that a task will start
within a reasonable margin of its scheduled time. It really has
nothing to do with fast, but that all of the tasks can happen when
they need to. You could have a realtime system that needs to execute
only one thing a year, but it needs to happen within one microsecond
of the scheduled time.
In order to guarantee this schedulability you need to know what the
interrupt latency, how often a task will run, and how long tasks
will run. With this information you can either guarantee that the
system will execute appropriately or be able to tell how often the
system is likely to fail. In practice many realtime systems are
analyzed with heuristic approaches and there is a level of
confidence that the system will perform properly. Some systems are
more formally proven to be correct, but even then there is usually
a disconnect between the proof (of concept) and the actual
Some of the companies that have "realtime" Linux schedule most task
in the background and have a limited number of "realtime" tasks that
can preempt the normal tasks.
Some links to actual realtime Linux's for the interested.
Rate Monotonic Analysis
On Sat, Sep 29, 2001 at 11:58:06AM -0700, Nicole Carlson wrote:
> On Sat, 29 Sep 2001, Peter Jay Salzman wrote:
> > i came across an article 'low latency in the linux kernel' written for
> > o'reilly's website. here's a quote i find curious:
> > under certain circumstance, it may be possible to run an application
> > in a condition known as setuid root. as the name implies, this
> > condition sets the user's ID to root status, raising the application's
> > execution to real-time scheduling.
> > this is NOT my understanding of setuid root executables. if this were the
> > case, nice-ing a setuid executable would be meaningless since the application
> > would get the attention of the kernel whenever it wants attention.
> > also, there would be no need for 'real time linux' since running an app as
> > setuid root would imply real time scheduling.
> I agree with you; I'm suspicious of O'Reilly's quote there. "Real-time"
> is not a synonym for "really fast"; it has a very specific meaning, and it's
> rather non-trivial to implement. In a real-time OS, processes are guaranteed
> to finish by a predefined interval. The Linux kernel doesn't implement
> that--if memory serves, it uses several levels of priorities (so
> kernel-space stuff gets priority over user-space stuff) and round-robin
> within priority levels. It's possible (though I find it unlikely) that a
> setuid root program runs in the kernel-space priority queue, but even that
> isn't enough for true real-time scheduling. Real-time is a guarantee, not
> a vague implication of higher priority.
> --nicole twn
>  Though you can of course hack it to do so; q.f. RTLinux.
> "The personal computer market is about the same size as the total potato
> chip market. Next year it will be about half the size of the pet food
> market and it is fast approaching the total worldwide sales of
> pantyhose."--James Finke, president of Commodore, 1982
> Visit Nicolopolis! http://wwwcsif.cs.ucdavis.edu/~carlsonn
> email@example.com firstname.lastname@example.org email@example.com