>Great. Then solve the problem after you _know_ there is a problem.
>Several people have told you that they don't like your approach. That
>should be enough for you to have to justify your changes with real
>applications which have been proven to be hitting this problem. That
>should be trivial, according to you, because you have repeatedly come
>up with long arguments as to why it must be true. Fine. Show that it
>is true before you tinker with the scheduler. It's too important
>to be changed because you think there might be a problem. Don't you
>agree?
>
>: I also think it's a bit unfair to label people who agree with me
>: as "pseudo-RT friends".
>
>Come on Richard, you're just being defensive. You seem to represent
>a set of people who don't want RT but they want some other thing which
>you call "soft-RT". I, and others with more experience in this area,
>question the validity of any sort of real time features in a multi user,
>time sharing system. We happen to believe that the two disciplines are
>mutually exclusive. I don't know what you want me to call your friends,
>but they seem to like this strange thing you call "soft-RT". Since that
>is not considered real time by _any_ textbook or _any_ credible published
>paper, I'm feel completely justified in calling it "pseudo-RT". So you
>have these friends, they like your ideas, your ideas are focussed on
>pseudo-RT, so I called them your pseudo-RT friends. What's the problem?
First let me qualify myself per Larry's criteria. I don't know Richard or
anyone else on this list although I've lurked around Linux since 1.0.xx.
In my job, we assemble real time embedded systems to mission and safety
critical applications...black boxes that do the input-process-output
thing where the sensor inputs have sample rates from 10 Hz to 1 GHz and
the output have rates from servo control through real time imagery. This
business brings our portion of the company about $800M per year and
pays for about 1600 engineers.
Currently the these boxes uses commercial real time kernels like pSOS,
QNX, VxWorks, VRTX, even some self developed ones. The applications tend
to run about 30K to 100K lines of code and use very little commercial
software besides the compilers library functions.
The biggest problems for this business include
- low productivity of software development
- high software maintenance costs
- doesn't use technology from the commercial world
- difficult to find qualified experienced people
- lack of protected mode OS
- high cost to update hardware technology
To me, it's obvious that the business can benefit from a commercial
protected mode OS that supports a wide range libraries, and building
block applications. For example, take a look at the recent Linux
Journal for the article on developing a radar that flies on the
hurricane hunter aircraft and measures ocean wave characteristics.
Having qualified myself...Linux as it comes out of the box fits most
of the needs for these embedded systems. We'd like to stretch it from
the standard distribution with some ROM booting, more I/O preprocessors,
and POSIX real-time scheduling algorithms. These things exist already,
not in an integrated form.
On the subject of real-time...It's amazing how much FUD there is on the
subject, probably because not too many people have a lot of experience.
It's useless to discuss hard vs soft real time because the terms have
no standard definition. Plus, there's lots of factors to consider,
each of which falls on a continuum, IRQ latency, scheduling latency,
priority inversion, IRQ overhead, scheduling overhead, etc. etc.
Linux v2.2 comes very close to meeting our needs. Here's some ideas
for improvements
- integrate real time IRQ extensions to main kernel
(for example: http://hegel.ittc.ukans.edu/projects/kurt/)
- integrate micro sec timers extension to main kernel
(for example: http://hegel.ittc.ukans.edu/projects/utime/)
- integrate and extend the POSIX real time extensions
(for example: http://hegel.ittc.ukans.edu/projects/posix/)
- Quantify performance with a benchmark
(no more hard/soft debates, just a page full of numbers)
IRQ performance probably meets our needs already. We're used to
developing hardware I/O devices that buffer and reduce the need for
fast IRQ's or high rate IRQ's.
Scheduling algorithms may not meet our needs. We'd like to signal a
task to run after an I/O event or internal timeout with low latency and
minimum jitter. That part of the kernel seems to need the most work.
This isn't an argument for efficiency in walking queues, rather it's
asking for clean straight line paths from event to user level process
running. It's also necessary to limit the CPU time taken by the kernel
infrastructure. The kernel programmers have done a superb job of
limiting IRQ mask time as shown by the low IRQ latency of a stock
kernel. But, what effect do the bottom half handlers have on user
process execution time? I've never seen a measurement of bh execution
time for various cases of processor and I/O loading.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/