University of Pennsylvania Department of Electrical and Systems Engineering Digital Audio Basics ESE250 Spring 2013 Lab 9: Process CPU Sharing Friday, March 15, 2013 For Lab Session: Thursday, March 21, 2013in Moore 100 and Ketterer lab. Due: Wednesday, March 27, 2013by 12:00pm. Collaboration: Work in lab in teams of 2. Perform individual writeups. See course collaboration policy in the Administrative Handout. Objective: Observe and quantify impact of process sharing on a single CPU system. Prelab Requirements: download and read this entire lab assignment. Optional: Bring your headphones. Bring two.wav file at least two minutes long for use. in encode benchmarking. Deliverable: Answers to the prelab question. Answers to labeled questions that accompany the experiments. Handin: All labs will be turned in electronically through the Penn Blackboard website. Go to the assignment submission link and follow the instructions. Please submit all your files as one zip file. Also, remember that your writeup should be a PDF file. Exit Ticket: Show your scheduling observations to the TA 1
Motivation Physical processors are usually time-shared between multiple running processes. This is done in order to give the user the illusion of running multiple applications at the same time or to allow a number of tasks to be done simultaneously. This is usually achieved by using a operating system to act is a resource manager that dictates which process gets to run in the processor at any given moment. In this lab, you will experiment with multiple processes running on a single processor. Lab Procedure Guide You should keep track of time as you work through the lab; the tasks you will carry out are not particularly complex, but may take a while to complete. Make sure to collect all the required information in order to do your analysis and respond to the questions for the writeup. You may find it useful to refer back to last week s lab appendix, which summarized useful unix commands. Two additional commands you may find useful this week: ps list running processes (by default, only the ones you own). kill kill a running process identified by process id. Timing Tasks 1. Login to your linux machine. 2. Start a terminal. 3. Use cpu status to determine the state of your workstation and set it into single processor state. The linux machines in Ketterer and Moore 100 are 8-core (eight processor cores on the same integrated circuit die) machines. You can see which of these cores are active by entering cpu status get into a terminal. 4. In order to make sure this lab is focused on the sharing of just a single processor, we want to limit the number of processors running during this lab. (If there is time left at the end of the lab, you may want to rerun some of the experiments with the second core enabled and observe the difference.) You can limit the number of running processor cores to one by entering cpu status set single into a terminal. For other options, just enter cpu status. 5. Use time250 to time the execution of lame encoding a.wav file. 1 You can do this by: 1 The system is now set up to let you run lame directly, without the need to be in a particular directory. 2
time250 <command-to-encode-file-with-lame> where <command-to-encode-file-with-lame> is the command you used to encode files with lame in lab 8. (For reference, it is./lame <your-wav> <newly-created-mp3>, where <your-wav> is the.wav you d like to encode, and <newly-created-mp3> is the name of the mp3 that lame will create.) As with previous labs, you can download a suitable.wav file from the ESE250 website. We have configured time250 to report the percentage of the CPU the task used during execution, three times (user, system, and elapsed) along with the number of voluntary and involuntary context switches the task did during execution. user time spent directly running this task system time spent in the kernel running OS service operations on behalf of this task elapsed elapsed wall-clock time between start and finish of this task. If nothing else runs during this task, elapsed time and user time will be close together. However, when the task is slowed down by other tasks (or by bottlenecks in I/O), the elapsed time may be larger than the user time. voluntary context switch Number of times that the program was context-switched voluntarily, for instance while waiting for an I/O operation to complete. 2 involuntary context switch Number of times the process was context-switched involuntarily (because the time slice expired). 2 Record the execution times and context switches for the lame encoding operation A1. 6. In a terminal, start the htop command. You will leave this running for the remainder of the lab. htop shows you the status of tasks running on your machine. At the top of the display are some general statistics about the machine. Below a column header line, there are statistics associated with each of the running processes ordered by the fraction of the CPU capacity the tasks are utilizing. There may be more tasks running than what you see, using the arrow keys, you can scroll down to see these other processes. The top line (starts Cpu ) shows how busy the CPU is and how that is divided between user jobs (in green) like yours, system tasks (in red) for the operating system kernel, and niced user jobs (in blue). When you first bring it up, the system should be mostly idle. For the process rows, here s a brief description of some of the fields: PID process ID, a unique identifier assigned to the process USER user who owns the process PRI priority NI nice level (you ll experiment with this later in the lab) Process priority. S process status, R for a running process, S for an idle process. CPU% percentage of the CPU time used by this task 2 Source: time250 man page 3
MEM% percentage of the memory used by this task TIME+ elapsed runtime on this job since it started Command the command that started the process You can sort by a different column by pressing F6, choosing the column and pressing return. Use the man command to get more information on htop. Real-Time Tasks 7. Observe the behavior of a set of real-time tasks: (a) Keep the htop terminal open and start three new terminals. (b) In the other terminals, start the following: Run playbigbuckbunnies to get four copies of mplayer playing the video clip Big Buck Bunny. 3 Run atlantis, this will run a windowed version of a screen saver. Run circuit, this will run a windowed version of a screen saver. (c) Resize the screen saver windows so that you can see all 4 videos, 2 screen savers and the htop window. (d) Record the overall CPU capacity consumed by running the tasks A2 (moving the mouse or typing will consume CPU capacity, so make sure to let your machine settle down before making a measurement!) (e) Observe the tasks and note if any performing poorly (i.e. they are performing worse than they would if they were the only task running) A3 (f) For each of the tasks started above, record the fraction of the CPU capacity and memory capacity the task is using. A4 8. Observe the impact of a best-effort task along with the real-time tasks. (a) With all of these tasks still running, in a new terminal, use time250 again to time the execution of the same lame encoding. Pay attention to the htop output and the performance of the ongoing tasks. (b) Record the execution times for this run A5. (c) Record the impact of the lame run on the other tasks, both qualitatively (not any change in performance from before) and in CPU usage (note in change in the fraction of CPU usage) A6 Stop all the real-time tasks you were running so the machine is again idle. If you need to stop the four mplayer movies, click on each one and press Q. 3 (c) copyright Blender Foundation from http://www.bigbuckbunny.org/ 4
Best Effort Tasks 1. Use two different.wav files for this experiment. 2. Run timed encodings for these two files sequentially as a basis for comparison. Use a semicolon to separate both commands on the same command line. The semicolon will cause the first command to run to completion and then run the second command. This way your typing speed does not effect how quickly the subsequent jobs are started after the earlier ones. Your command should look like time250 <command-to-encode-file1>; time250 <command-to-encode-file2> 3. Watch htop during execution. 4. Record the CPU times for the two runs A7. 5. Run these two timed encodings simultaneously; to be able to see the output of both time250 commands, run lame with the --quiet flag for both. To spawn two encodings simultaneously, use an & at the end of each command without the semicolon. When you add an & at the end of a command, it tell the OS to begin the command and not wait for it to finish. Your command should look like time250 <command-to-encode-file1>& time250 <command-to-encode-file2>& 6. Watch htop during execution. 7. Record the CPU times for the two runs A8. 8. Use nice to change the priority of jobs. (a) Rerun the pair of simultaneous lame jobs using nice to run one of them at a significantly lower priority. nice -n nice-level command-to-run Larger numbers represent lower priority (greater attempts to be nice to other processes). The maximum value is 19, so you probably start try 10, 15, and then 19. (b) Observe difference in percentage of CPU time assigned to each routine in htop and report A9. (c) Record the time250 output A10. 5
Observing Scheduling 1. Go into the ese250-lab9 direction, which should be in your home directory. 2. Decode the first 100 lines of the compressed file fb.comp by using a modified version of lab 3 s decoder, redirect the output to a file: java coding.decoder fb.comp fb.dic 3804 > fb.txt 3. Look at output file fb.txt 4. Run ourwc on the file fb.txt by redirecting standard in as follows:./ourwc < fb.txt. ourwc is similar to the system s wc (word count) command but we ve modified a little bit to show an incremental count at each line. 5. Run the pipelined operation: java coding.decoder fb.comp fb.dic 3804./ourwc The pipe connector ( ) tells the operating system to feed the output from the preceding program to the input of the following program. Pipes can be used to communicate between simultaneously running processes. 6. Observe the console output of this pipelined run and the individual runs A11. Cleanup and logout. 1. save away any data you need to complete the lab 2. remove any files you have created 3. end any remaining running tasks 4. logout Lab Writeup Guidelines Theory: Pre-lab Question 1: One of the OS s jobs is to oversee sharing of the processor between multiple processes. Briefly describe three (3) different ways in which the OS could decide to do this. State any assumptions that you make about what the OS can know and discuss at least one advantage and one problem with each method. Remember that all tasks are not created equal: different tasks take different amounts of time to run to completion, some tasks do more important things than others (higher priority), and some times have strict timing associated with them (they must start running by a particular time and finish executing by a particular time after they start running for their execution to be correct better never than late). 6
Analysis Question 2: Report your observations A1 A11. Real-Time Tasks Question 3: Form your observations in A2 and A4, what can you say about the resource requirements for the real-time tasks? Question 4: Form your observations in A3, how well is the CPU managing to run the real-time tasks? (Is it handling the job perfectly, or is it failing in some way?) Question 5: Form your observations in A5 and A6, how well is the CPU managing to run the real-time tasks alongside the best effort task? What was the impact on the real-time tasks? What was the impact on the best-effort task? Best Effort Tasks Question 6: What happens to the elapsed time for each encode when run simultaneously with another encode? Question 7: What happens to the elapsed time for the encode that was run with nice? (i.e. when the process is given a niceness of 0?) Question 8: How does the total time for both encodes compare between the sequential and simultaneous cases for the case without nice? Question 9: How does the total time for both encodes compare between the sequential and simultaneous cases for the run with nice? Observing Scheduling Question 10: How does the pipelined (piped) run output compare to the individual run output? 7
Conclusion Question 11: From your observations, describe how the operating system is running the tasks on the processor. (Is it similar to any of the schemes you described in your prelab?) Further Thought This section is not part of your required assignment. Due to the nature of this course, we can only begin to glimpse the depth and richness of each of the topic areas. This question is intended to offer some headings to contemplate in more depth; feel free to append your answer to your report. The idea that processors are expensive is rapidly becoming dated. Multicore chips with 100s of small processors are already available, and we will soon see chips with either 1000s of small processors or 10s to 100s of large processors. How does the role of the OS change? What functions become less important or go away? change in nature? become more important? 8