CS452 - Real-Time Programming - Fall 2011

Lecture 34 - Cyclic Execution

Public Service Annoucements

1. Final demo: Tuesday, 6 December, 2011; Wednesday, 7 December, 2011
   • Demo I starts at 10.00 on Tuesday
   • Demo I ends at 13.00 on Tuesday, say 14.00 because we often run overtime.
   • Demo II starts at 10.00 on Wednesday
   • Demo II groups have 20 hours of exclusive track use from end of Demo I to the start of Demo II
   • Therefore, Demo I groups should have 20 hours of exclusive track use.
   • From 14.00 on Monday to 10.00 on Tuesday only groups showing their demos during Demo I may use the trains lab.
2. Final exam: 10.30, Friday, 9 December, 2011 to 13.30, Saturday, 10 December, 2011.

Cyclic Execution

Voyageur

In continuous operation for 34 years, 2 months, 25 days.

It was designed to have a three-year lifetime!

Computer

6000 word instruction and scratch data memory

62,500 Kbyte digital tape recorder for storage of sensor data

System Software

Cyclic executive

Cyclic Execution

1. Clock ticks
2. Starts executing, in priority order, programs that are ready to run.
3. At end of programs, wait until the clock ticks, then go to 2.
4. If clock ticks before end of programs, then report fault to earth and go to 2.
5. Cycle can be interrupted by receiving input from earth that tells it to jump to boot mode.
   • Checking for input from earth is one of the programs that is run.
   • Boot mode often entails loading a new program from earth. (At present loading takes many hours. Aren't you lucky!)

This is an abstract description: with so little memory it is essential to squeeze out every word.

Most of the programs have the form

1. If input from X, then do A.

We are back at the beginning of the course, but we know much more now.

Real-time Scheduling

Much real-time computing operates in an environment like the following

1. Groups of sensors that are polled with fixed periodicity
2. Sensor input triggers tasks which also run with fixed periodicity

Typical example, a group of sensors that returns

• the rotational speed of the wheels, and
• the exhaust mixture, and
• the torque, and ...

and a set of tasks that

• updates the engine parameters, and
• updates the transmission parameters, and
• passes the speed on to the instrument controller, and ...

Each time a sensor returns a new datum a scheduler runs

1. makes ready any task that the data makes ready to run
2. decides which of the ready tasks to schedule, and
3. starts it running.

Your kernel can handle problems like this one pretty efficiently,

• but you can do better.

Cyclic Execution

Let's make a finite schedule that repeats

                                               A                                       A
  AC  BA    A C  A    A  C A    A B CA    A    C    A    AC B A    A C  A    A  C A    B
  |    |    |    |    |    |    |    |    |    |    |    |    |    |    |    |    |    |
      |                           |                         |                          |
   |          |          |          |          |          |          |          |
________________________________________________________________________________________________________ time

If the times are integers the pattern repeats after a while.

• The total amount of thinking you have to do is finite.
• The thinking you do is inserting into the schedule the amount of processing that needs to be done
  • worst case
• Work it all out so that nothing collides.
  • using heuristics, no doubt

Make it a little easier

1. Make the complete pattern short by making sensor periods multiples of one another. If you can control sensor periods.
   • Underlying clock.
   • sensor i is read once every ni ticks.
   • Master cycle is LCM( n1, n2, n3, ... ) in length
   • Schedule the master cycle by hand (= by brain)
2. Standardize the processing at each point
3. Minimize the interaction between tasks
4. Simple procedure
   1. Processing needed by task i is pi
   2. Share of CPU needed by pi is si = pi/ni
   3. s1 + s2 + s3 + ... < 1. Otherwise you must,
      • get a bigger processor, or
      • reduce the amount of computing needed
   4. Deadline for task i is di after the sensor report. si < di : otherwise
      • you always miss that deadline.
5. Prove some theorems, such as Liu & Layland

Theorems

Important assumptions

• No interaction execpt contention for CPU
• All tasks scheduled periodically
• Task must finish processing event n before event n+1 occurs
• When tasks are ready simultaneously the higher priority one runs

Main idea

• Identify the bottleneck
• We call this the critical instant for a task.

Main result

• A method for deriving priorities from task characteristics
  • rate-monotone scheduling

Subsidiary result

• Maximum possible CPU utilization

Is this of any practical value? Yes, otherwise I wouldn't bother teaching it.

Your project

If your project is correct, but resource limited, the critical instant for the limiting resource is the place where your project fails. For example.

• If your project is CPU limited, it's the point where the maximum computation must be done before the CPU can get back to do the most important new thing.
• If you project is train communication bandwidth limited, then it's the point at which all curent users of bandwidth want to communicate at once.

Your job

Think about how a mobile telephone works.

• It has housekeeping functions that must be done regularly, things like
  • telling the nearest ground station that it's ready to receive a call
  • updating the clock
  • refreshing the memory
• When you are making a phone call, there are phone call functions that must be done regularly
  • collecting packets of audio from the antenna
  • doing signal conditioning on the digital audio they contain.
  • putting the digital audio into data buffers from which they will be send to the speaker.
  • analogous things that intervene between the microphone and the antenna.

When you want to play a game, consult your calendar, browse the internet, etc you want asynchronous response from the phone

• It should slow down, not collapse, when you load it too heavily.
• The easy way to do this.
  • Put all of the regular functions into a cyclic executive, carefully analysing the run-time of each to make certain that everything will always get done on time.
  • In almost every cycle there is some time left over. In this time run an asynchronous OS that supports non-critical features such as
    • managing the UI
    • texting
    • game playing
    • internet browsing
    • whatever else you can find at the app store.
  • The definition of `non-critical' depends on the capabilities of the user. For example,
    • if a UI slows a little the user easily slows his or her reactions to accomodate
    • but if the sound drops out for a second in the middle of a word the user cannot pause his hearing in order to put the two halves of the word together

This sounds easy. Why is it hard in practice?

• It's necessary to share resources.
  • hardware, such as memory and I/O
  • software, such as data structures
• In particular, from the UI the user starts functions, like phone calls, that are synchronous.
  • Synchronous/asynchronous communication is hard to accomplish while meeting tight real-time constraints.

Apps are better if they can install tasks on the cyclic executive

• Why? Apps like games have real-time demands.

But,

• Security is a problem because malicious apps can overrun schedules, so you need admission control
• Performance is a problem because loading too many apps can affect the quality of the telephone function, so you have to involve the user in admission control.

Return to:

• Bill Cowan's Fall 2011 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page