How To Compare Real Time Scheduling To A Scheduled Scheduler On Linux On A Computer System With A Visualization System

Transcription

1 MS project proposal: A comparison of real-time scheduling algorithms using visualization of tasks and evaluation of real-time extensions to Linux Kevin Churnetski Computer Science-RIT 8/21/2003 Abstract: Real-time Systems are computer systems that require responses within specified time limits or constraints. Many real-time systems are digital control systems comprised entirely of binary logic or a microprocessor dedicated to one software application that is its own operating system. In recent years, the reliability of general-purpose real-time operating systems (RTOS) consisting of a scheduler and system resource management has improved. In this project, I will write a real-time simulator (RTS), write a workload generator, write analysis tools, and run and interpret the results. The main analysis tool I propose to develop will be a measurement system that analyzes real-time scheduling strategies. I will also develop a visualization system to display the scheduling decisions of a real-time scheduler. Using the measurement and visualization systems, I will investigate scheduling algorithms for real-time schedulers and compare their performance. I will run different workloads to test the scheduling algorithms and analyze what types of workloads make the best benchmarks. Table of Contents: Description of Project Overview of Project Area Functional Specification of Project Architectural Overview of Project Schedule Principal Deliverables of Project Draft Table of Contents of Final Report References Description of Project: Scheduling algorithms used in a particular application can have a significant impact on the functionality of a real-time system. One effect is accumulation of aperiodic tasks at a point in time in an overloaded system. In this situation, the scheduler may not be able to meet all of the aperiodic and periodic tasks deadlines.

2 In this project, I will develop a measurement and visualization system to display the scheduling decisions of a real-time scheduler. I will try various scheduling algorithms and compare their relative performance using a visualization system. The effectiveness of the visualization system will be determined during experimentation. The data files output by the logger and read by the visualization system will be comma-separated values easily read-in by another application for display or further analysis. The experimental results of the visualization system will be augmented by charts created using data from the log files. In addition to testing several algorithms, I will test several classes of workloads. Usually, several different algorithmic approaches may successfully schedule any given workload [2]. I will test the scheduling algorithms using workloads that push the envelope of schedulability in order to determine which algorithms are the most robust. The research to find these types of workloads will also be applied to finding benchmarks that extensively test real-time schedulers. All workloads in this project will have tasks of two types. Hard real-time tasks must be completed before a chosen deadline to avoid total system failure. Timing results of a missed hard real-time deadline will not be analyzed further than to recognize that a specific algorithm fails to schedule the workload. Soft real-time tasks are allowed to miss deadlines but negatively affect the rating of the algorithm. If time permits, I will investigate the use of KURT, real-time extension to the Linux platform as part of this project. The UTIME and Kansas University Real-time (KURT) extensions to Linux provide on-demand microsecond resolution and real-time scheduling capabilities to the standard Linux kernel [7]. If the KURT/Linux platform proves to be suitable (and if time permits) then I will implement software that interfaces this RTOS with the visualization system. 2

3 Overview of Project Area: Real-time Systems Hard real-time tasks are required to complete computation or execution within the specified timelines. The task must be completed correctly and within the time limits or the system may be considered a total failure. Depending on the specific application, a total system failure could result in catastrophic damages and possibly loss of life. Soft real-time tasks include a time of preferred completion but not a strict deadline. The deadlines of soft real-time tasks may be missed occasionally; in many applications, there are statistical constraints. One example is if the average number of missed deadlines per minute is greater than two then the system is considered to have failed [8]. Example Real-time Applications Typical real-time systems involve a control aspect and a data input aspect [4]. Often, digital controllers and devices provide the interface between the physical environment and more complex real-time computers. These devices may include operator (human) input panels. The interface between a real-time computer s output and the environment may or may not include digital controllers. Examples of hard real-time systems are the flight controls of an airplane and medical applications such as computer assisted surgery or life support. There exist many distributed applications with real-time considerations. The issues introduced by real-time, distributed systems are beyond the scope of this project. It is worth noting that Liu [8] among others claim that single processor scheduling techniques can be generalized to have influenced on research in multiple processor scheduling. 3

4 Examples of soft real-time systems are online database systems and transaction systems. These examples are also known as mission-critical or business application critical. Another example is user interfaces. Most user interfaces have soft real-time constraints because the human user is interacting with the system directly and prefers timely responses. Real-time Scheduling Real-time scheduling algorithms have been an active topic of research since the late 1960 s. Real-time scheduling algorithms work either dynamically or statically. Static scheduling algorithms and techniques have more computer time to devote to scheduling because scheduling is completed before the target system begins. As you might expect, unless all information about all tasks is known before the system is brought online, the system may not use a static scheduling algorithm. The dynamic scheduling algorithms are further divided into static priority and dynamic priority [8]. As you might expect, unless all information about all tasks stays unchanged throughout each of the tasks lifetimes, the system may not use a static priority algorithm. This classification is not exhaustive in depth or detail. \ Classification of Real-Time Scheduling Algorithms: static dynamic dynamic priority static priority Many dynamic scheduling algorithms studied in research use a simple heuristic. Example dynamic priority scheduling algorithms are the Earliest Deadline First (EDF) and First- In First-Out (FIFO). An example of a static priority dynamic scheduling algorithm is the Rate Monotonic (RM). The RM schedules the tasks in order of increasing period, where period is 4

5 equal to the amount of time between requests. In dynamic scheduling practice, techniques that combine simple heuristic algorithms may be used. The RM is the optimal static priority dynamic real-time scheduling algorithm and any periodic task set of any size will be able to meet all deadlines all of the time if the rate monotonic algorithm is used and the total (processor) utilization is not greater than.693 [2]. The application of the RM results have proven to be effective when used in combination with other techniques for scheduling periodic and aperiodic task loads as well [3]. Real-time Operating Systems Real-time Operating Systems are available in open-source and commercially in all price ranges. They differ in size (memory space), and in available options/features. RTOS that are more expensive typically require expensive software tools to complete development of applications. Examples of RTOS are VxWorks, RTLinux, LynxOS, QNX, and Windows CE. Embedded platforms are more frequently the target for RTOS. Relatively few RTOS have been written for the PC (there is a version of QNX that runs on the PC). A recently available opensource RTOS for PC s is KURT [5]. 5

6 Functional Specification of Project: The software will reside in a specific directory structure reflecting JAVA packages. A diagram and description of an example directory structure is displayed below. The directories in the resulting final project will be described in the final user manual. (This section of the proposal is a draft user manual intended to show layout and all specific information is tentative.) Directory structure maintained by the user: RTS application scheduler visualization Directory name: application scheduler visualization Contents: data files for example workloads, application software RTS and scheduling algorithms visualization software, log files (output of RTS, used by visualization application in playback mode) There is a simulation mode and a playback mode. Two different commands are entered by the user begin execution of the two different modes. Commands entered by the user: 1. rts <filename>: Runs the application, the visualization system and the RTS (the application software communicates output data to the RTS, filename is the name of the workload input file) 2. runvis <filename>: Runs the visualization system in playback mode (filename is the name of the log file to display the data) 6

7 Architectural Overview of Project During development and experimentation, the RTS will simulate the workloads by interfacing with the application. Results will be communicated to the visualization system. Architecture during development and experimentation: scheduling scheduling application requests RTS results measurement and visualization system development platform As a tentative plan, the deployed visualization system will be running on the same platform as the applications of the RTOS (included if time permits and subject to change). Architecture during deployment: application measurement and visualization system RTOS platform 7

8 The software modules form a library the components of which being modifiable for use in a similar software system either in their entirety or individually. All software will be written in JAVA and be runnable from Unix scripts. Software Modules: A. RTS procedure calls B. application interface C. scheduler D. logger interface text log file E. application text data file F. visualization system A. RTS: Module contains the job ready queue, task data structures and methods that schedule tasks. Two methods that this module will contain (software code may not use these exact identifiers): 1. ScheduleAperiodicTask (taskname, requesttime, type, deadline, Runtime) Tasks with type zero have hard real-time deadlines. Tasks with type one have soft real-time deadlines. Runtime is the worst-case runtime of the task. 2. SchedulePeriodicTask (taskname, requesttime, type, deadline, Runtime) Same as above except that the task will repeat requests at a regular interval equal to the period. For simplicity, the period will be equal to deadline request time. Therefore, requests will repeat in the following fashion: requesttime, requesttime + period, requesttime + (2 * period), requesttime + (3 * period) etc. Period is the time between release times for periodic tasks. Release time for a task is the moment the task becomes available for execution. B. Application interface: Module will interface to an application which will request tasks C. Scheduler: Module contains a comparison routine used by the RTS to determine which tasks have priority over one another. D. Logger interface: Module outputs the data from the real-time simulation in a user-friendly format. E. Application: Module simulates the example real-time application. F. Visualization System: Module displays data directly output by the logger interface of the RTS. The visualization system can also be run as a stand-alone application in which case it plays back the data of a saved log file. The execution of two modes will be specified by command line option. 8

9 Week# week begin Work 1 7/14 Literature Research 2 7/21 Literature Research 3 7/28 Literature Research Proposal Schedule 4 8/4 Meet with committee Literature Research Code RTS Proposal 5 8/11 Code User-interface for visualization system Write and code a simple, example scheduling algorithm Proposal 6 8/18 Study of Scheduling Algorithms Code application software Meet with committee Proposal 7 8/25 Code scheduling algorithms Complete Proposal 8 9/1 Run experiments/collect data Analysis of experiments begin final paper 9 9/8 install real-time extensions to Linux on platform Meet with committee 10 9/15 work on real-time extensions to Linux write final paper 11 9/22 Write final paper 12 9/29 Prepare presentation draft of final paper to committee Meet with committee member(s) for practice presentation 13 10/6 Meet with committee (review final paper comments) Date Presentations 8/5 Presentation to MS project seminar class 10/1 Presentation to committee member(s) 10/8 Defense 9

10 Principal Deliverables of Project: 1. Source code a. RTS b. Implementation of several scheduling algorithms c. Application d. Measurement and visualization system (displays scheduling decisions) 2. Data files (input files representing example workloads) 3. Log files (data collected from experiments on example workloads) 4. Technical Report (see draft table contents below) 5. User Manual Draft Table of Contents of Final Report 1. Abstract 2. Description of real-time scheduling a. Theoretical b. Application 3. Description of scheduling algorithms implemented 4. Description of application/example workloads a. Used during testing of algorithms b. What workloads are the most difficult to schedule c. Which workload characteristics are preferred for benchmarks 5. Results and analysis of different scheduling algorithms a. Visualization system b. Quantitative analysis from data in log files 6. Evaluation of usefulness of visualization system 7. Conclusion Appendix A. User manual 10

11 References [1] Ghosh, K., Mukherjee, B., Schwan, K. A Survey of Real-Time Operating Systems Preliminary Draft, Technical Report Georgia Tech. College of Computing, Report No. GIT-CC [2] Liu, C. L., Layland, J. W. Scheduling algorithms for multiprogramming in a hard real-time environment, Journal of the ACM, 20(1):46-61, January [3] Lehoczy, J., Sha, L., Ding, Y. The Rate Monotonic Scheduling Algorithm: Exact Characterization and Average Case Behavior, Proceedings of 8th IEEE Real-Time Systems Symposium, pages , IEEE Computer Society Press, December [4] Laplante, Phillip A. Real-Time Systems Design and Analysis: An Engineer's Handbook, Wiley-IEEE Press, 2nd edition, March [5] KURT-Linux: Kansas University Real-Time Linux (website) on 7/11/2003 obtained from: [6] NIST Special Publication (Draft-yet to appear), Technology Administration, "Requirements for Real-time Extensions for the Java Platform" Real-Time for Java Expert Group, on 7/8/2003 obtained from: [7] Dinkel, W., Niehaus, D., Frisbie, M., Woltersdorf, J. KURT-Linux User Manual ; on 7/28/2003, obtained from: [8] Liu, Jane W. S, Real-time Systems, Prentice-Hall,