rtlinux - keeping simple – tech and business … · rtlinux is decoupled from linux rtlinux...
TRANSCRIPT
Outline.
� The usual: definitions of realtime.
Who needs realtime?
How RTLinux works.
Why RTLinux works that way.
Free software and embedded.
RTLinux – p.2/33
Outline.
� The usual: definitions of realtime.
� Who needs realtime?
How RTLinux works.
Why RTLinux works that way.
Free software and embedded.
RTLinux – p.2/33
Outline.
� The usual: definitions of realtime.
� Who needs realtime?
� How RTLinux works.
Why RTLinux works that way.
Free software and embedded.
RTLinux – p.2/33
Outline.
� The usual: definitions of realtime.
� Who needs realtime?
� How RTLinux works.
� Why RTLinux works that way.
Free software and embedded.
RTLinux – p.2/33
Realtime versus Time Shared
� Time sharing software: switch betweendifferent tasks fast enough to create theillusion that all are going forward at once.
Realtime software: switch between differenttasks in time to meet deadlines.
RTLinux – p.3/33
Realtime versus Time Shared
� Time sharing software: switch betweendifferent tasks fast enough to create theillusion that all are going forward at once.
� Realtime software: switch between differenttasks in time to meet deadlines.
RTLinux – p.3/33
Hard realtime
1. Predictable performance at each moment intime: not as an average.
2. Low latency response to events.
3. Precise scheduling of periodic tasks.
RTLinux – p.4/33
Soft realtime
� Good average case performance
� Low deviation from average caseperformance
RTLinux – p.5/33
Traditional problems with softrealtime
� The chips are usually placed on the solderdots.
The machine tool generally stops the cut asspecified.
The power almost always shuts off before theturbine explodes.
RTLinux – p.6/33
Traditional problems with softrealtime
� The chips are usually placed on the solderdots.
� The machine tool generally stops the cut asspecified.
The power almost always shuts off before theturbine explodes.
RTLinux – p.6/33
Traditional problems with softrealtime
� The chips are usually placed on the solderdots.
� The machine tool generally stops the cut asspecified.
� The power almost always shuts off before theturbine explodes.
RTLinux – p.6/33
New problems with soft realtime
� The voice-over-IP system only loses packetsunder stress.
The cell-phone connect won’t drop yourInternet handset during a handoff unlessthere is heavy traffic.
If you start a browser on one machine, mostof the time sales transactions won’t get loston the other side of your SOHO router.
RTLinux – p.7/33
New problems with soft realtime
� The voice-over-IP system only loses packetsunder stress.
� The cell-phone connect won’t drop yourInternet handset during a handoff unlessthere is heavy traffic.
If you start a browser on one machine, mostof the time sales transactions won’t get loston the other side of your SOHO router.
RTLinux – p.7/33
New problems with soft realtime
� The voice-over-IP system only loses packetsunder stress.
� The cell-phone connect won’t drop yourInternet handset during a handoff unlessthere is heavy traffic.
� If you start a browser on one machine, mostof the time sales transactions won’t get loston the other side of your SOHO router.
RTLinux – p.7/33
You don’t really need hardrealtime
� We have one failure every 100 hours ofoperation on the average, but somecustomers experience 5 failures in an hour.
Tell ’em to stop being such whiners.
Poor performance? More memory and afaster processor!
What’s wrong with quad Itaniums, 8 Gig ofmemory, and a liquid cooling system on a$100 SOHO router?
RTLinux – p.8/33
You don’t really need hardrealtime
� We have one failure every 100 hours ofoperation on the average, but somecustomers experience 5 failures in an hour.
� Tell ’em to stop being such whiners.
Poor performance? More memory and afaster processor!
What’s wrong with quad Itaniums, 8 Gig ofmemory, and a liquid cooling system on a$100 SOHO router?
RTLinux – p.8/33
You don’t really need hardrealtime
� We have one failure every 100 hours ofoperation on the average, but somecustomers experience 5 failures in an hour.
� Tell ’em to stop being such whiners.
� Poor performance? More memory and afaster processor!
What’s wrong with quad Itaniums, 8 Gig ofmemory, and a liquid cooling system on a$100 SOHO router?
RTLinux – p.8/33
You don’t really need hardrealtime
� We have one failure every 100 hours ofoperation on the average, but somecustomers experience 5 failures in an hour.
� Tell ’em to stop being such whiners.
� Poor performance? More memory and afaster processor!
� What’s wrong with quad Itaniums, 8 Gig ofmemory, and a liquid cooling system on a$100 SOHO router?
RTLinux – p.8/33
Hard realtime is needed
1. If "rare" timing failures are serious.
2. If precise timing makes a process possible.
3. If precise timing makes a performanceadvantage.
RTLinux – p.9/33
Timing
1. A 30 microsecond delay can drop 20 GigEthernet packets.
2. 10 70hz video streams need packetsunloaded at millisecond rates.
3. Time for 1 degree error on manipulator: 10microseconds.
RTLinux – p.10/33
Low end examples.
1. Replace a digital joystick with an analogjoystick and a sound card.
2. Reduce control loop times by sampling A/D at100 microseconds.
3. Log data over the network using Linux utilitieswith no software development costs.
4. Use Apache standard web server as a controlinterface – with no software developmentcosts.
RTLinux – p.11/33
Larger examples.
� Multiple software "Virtual routers" operatingon packets in realtime.
� Interactive robot control with non-RTgraphical interface.
RTLinux – p.12/33
The RTLinux operating system
A small hard realtime operating system that runsLinux (or BSD) as its lowest priority task. Usedfor everything from making chain-saw chains, to
switching packets to animating movies.
RTLinux – p.13/33
RTLinux is decoupled from Linux
RTLinux schedules itself — Linux scheduler isnot involved.
Linux cannot delay or interrupt execution ofRTLinux
RTLinux – p.16/33
Results
1. Example on AMD SC520 133Mhz.
� Low latency response to events.15microseconds or less.
� Precise scheduling of periodic tasks. 20microseconds or less error.
2. On a standard PC: 19 microseconds and 50microseconds
3. On SOCs we are in the single digits
RTLinux – p.17/33
Programming model
1. For Realtime tasks and event handlers:POSIX Pthreads.
2. For Linux processes connection via POSIXI/O, shared memory, and signals.
As standard as possible with no efficiency loss.
RTLinux – p.18/33
Programming view
1. The hard realtime component of realtimeapplications should run in a simple, minimal,predictable environment.
2. The non-realtime components should run inUNIX until something better is invented.
3. Hard realtime and non-realtime should bedecoupled in operation.
RTLinux – p.19/33
Programming interface
1. "Lean" POSIX threads for RT components,standard POSIX for non-RT components.
2. RTLinux can support alternate APIs.
3. API is programmer convenience: nottechnology fundamental.
RTLinux – p.20/33
Where is it used?
1. Communications: PBX’s, routers, ...
2. Factory automation: machine tools,production lines.
3. Robotics: stepper motors, A/D, ...
4. Multimedia: animations, ...
RTLinux – p.24/33
RTLinux Version 3.0
1. V1 was a research project.
2. V2 was the first production version.
3. V3 is the first industrial strength version. x86,Alpha, PPC, MIPS, smp support, ...
4. V4 on the way.
RTLinux – p.25/33
But why not integrate RT intoLinux?
� Experience shows: performance limits andengineering costs.
RTLinux – p.26/33
Why is decoupling so important?
1. Mars Lander almost broke because a lowpriority non-realtime process was able to locka resource needed by a critical realtime task.The lock was hidden in complex code sharedby all tasks, realtime and non-realtime.
2. RTLinux makes all interactions between RTand non-RT explicit and transparent .
RTLinux – p.27/33
The RTLinux technical synergy.
1. Highly efficient realtime.
2. Connected to a reliable and powerfulnetworked operating system (Linux).
3. Running on standard PCs, servers, andembedded hardware.
RTLinux – p.28/33
The RTLinux cost advantage.
1. The costs of maintaining general purposesoftware – data bases, networks, graphics,development, ... – are shared with server anddesktop companies.
2. Prototype on PCs.
3. Access to source is essential for importantapplications.
RTLinux – p.29/33
Coming in V4
1. RT networking. (for industrial control andcomms).
2. User mode RTLinux functions.
3. Failover technologies.
4. Optimizations.
RTLinux – p.30/33
Finite State Machine Labs
1. Core kernel development and GPL andnon-GPL RTLinux distributions.
2. Training, engineering services and productsupport.
3. Application software in communications andfactory automation.
RTLinux – p.31/33
Why non-GPL development
1. Some of our customers need it: nicheproducts or close hardware/softwareinteraction is common in embedded.
2. We need it: we cannot pay for developmenton contract services.
3. Our non-GPL is source to customers, but norights to remarket our code.
RTLinux – p.32/33