CS 3733 Operating Systems

• Objective of part I: to show that when I/O was small, turnaround = duration * number of processes.
• Strategy for part I: vary the number of processes for fixed CPU burst and duration and show the relationship holds when the I/O burst is small. Then do a second experiment where you increase the I/O burst and see at what point the relationship no longer holds.
• Many people didn't vary the number of processes at all in this.
• Memorable bad choices of parameters:
  • Running it for 1, 2 and 3 processes. (You probably need at least 20 processes to get statistically significant results.)
  • Extensive study of I/O burst time between 1 and 2 with different distributions when the CPU burst time is 50. Another person studies burst times between 5 and 20 when CPU burst is 50. (These burst times look tiny to any algorithm...more reasonable choices might be 1, 10, 100, 1000, 10000, etc.)
  • Setting a duration of 15 and a CPU burst time of 50. The scheduling algorithm has no influence at all in this case. You should pick a reasonable duration so that the processes have at least 10 bursts (duration / average cpu burst) > 10. Varying the duration just tells you when the statistics are significant. You should be trying to keep the number of burst times approximately constant for this.

• Objective of part II: explore how variability of CPU burst time affects performance of SJF.
• Strategy for part II: Run a few SJF and FCFS with constant CPU and I/O bursts and show that they give same results. Then introduce variability into the CPU burst times and see how that influences average waiting time. Variability can be measured by fixing the average for the uniform distribution and increasing the interval around the average. Surprising, any variability has the same effect as a lot of variability on SJF. Only one person in the class ran the correct experiments on this.
• Most people didn't understand what variability of process is.
• A good exploratory topic for part II is to determine how accurate SJFA is compared with SJF.
• Memorable bad choices of parameters for part II:
  • Small durations or number of processes as in part I.
  • Thinking variability meant running experiments with different constant CPU burst times.
  • Introducing different distributions which had different averages so that you weren't looking just at variability (e.g. constant 50, uniform 50 100, uniform 100 150, uniform 150 200).

[2/20/98] Critique of Assignment 2 Part I:

• Returned 0 or size of the last block read.
• Opened the audio device inside of play_file
• Opened the disk file in the main program and passed a file descriptor rather than a file name.
• Allocated a buffer in the main program and passed it in.
• Used system.

• Didn't include necessary header files (as indicated by lint).
• Allocated a 1 byte buffer (using sizeof(char)).
• Didn't free the buffer that was allocated by malloc.
• Didn't close the disk file when done or neglected to close it when returning with an error.
• Read the entire audio file into memory and then outputted the entire thing to the audio device at once. (NO WAY! Remember audio files can be many megabytes long.)
• Read and wrote only the first 8010 bytes.
• Used fgets to read and write. The audio file is not an ascii file. You have no control over where the zero bytes are in this file.

• Didn't trap for errors on system calls.
• Used printf for error messages (remember buffering)
• Left debugging messages in without enclosing in

       #if DEBUG
           ...
       #endif
  

• Didn't output the number of bytes written to the audio file so how could you know that play_file was working.
• Exited from play_file rather than returning an error.
• Put the main program into the library file.

[2/17/98]Question

Just so I am sure what it is I am seeing, can you give a brief description of what each of the performance monitors is?

Answer:

Actually the performance meter has a man page under perfmeter which you may want to look at.... here is an excerpt:

          cpu     Percent of CPU being utilized.
          pkts    Ethernet packets per second.
          page    Paging activity in pages per second.
          swap    Jobs swapped per second.
          intr    Number of device interrupts per second.
          disk    Disk traffic in transfers per second.
          cntxt   Number of context switches per second.
          load    Average number of runnable processes  over  the
                  last minute.
          colls   Collisions per second detected on the ethernet.
          errs    Errors per second on receiving packets.

Can "system" be used in our programs to "cat" the audio files? Can "system" be used to call audioconvert? I was unable to find an audioconvert library function.

Answer:

This is a lab on device independent I/O. You may not use "system" in your program. By the way, "system" forks a child to run the program. In real life this is a very high-overhead approach.

You should use audioconvert as follows. Initially you can use it to remove the headers from your recorded digit files so that you can play them. (You will save the raw files to disk and use those as input.)

Once you get that working, you should compare the raw file and the file with the header to see what you have to do to take off the header yourself.

[2/10/98] Question:

In the assignment due on Wednesday, one of the functions we must write is supposed to remove the "audio header" from a file before sending it to the audio device in a write. I have looked through the book, man pages, and answerbook to find out what the audio header is. I looked at the first few lines of an audio file and found a .snd string before everything became giberish. Can you point me in a direction on this header.

Answer:

Do a man on audioconvert. With the -raw option this filter will remove the header.

• Mistakes concerning stat:
  • Most people did not follow the specification which was to use stat to detect NEW files. To do this, you must actually read the stat structure and see whether the file has been modified since it was last read.

  • Some people did used the size field in an attempt to detect new mail. This can fail since the mail could be read and new mail could come in and if the size is less than the original it won't be detected.

  • Some people closed the file descriptor corresponding to the return value of stat. (This means they closed standard input if stat returned a success.) BTW on some systems, close causes a core dump if you try to close a non-existent or already closed file.

• Mistakes concerning allocation of a buffer to hold the path name:

  The problem of how big a buffer to allocate to hold path names is a problematic. Members of the class allocated buffers ranging in size from 18 bytes to 32K. (This is a little bit like Carter's Liver Pills isn't?) Many people put an actual number in the declaration instead of defining a constant at the top. Some people just defined a pointer to char for their buffer without allocating any space at all. (This shows up in the lint as "variable used before set".)

  There are two acceptable approaches to this issue:

  • Use a system-defined constant like _POSIX_PATH_MAX. (In this case you should really make sure it is defined and set a default value if it isn't).

  • Figure out how big a buffer you need by looking at the strings and then allocating it.

    Among the mistakes made by people who used this approach were:

    • Not checking for a return error on malloc.
    • Forgetting to allow space for the trailing null.
    • Assuming characters are of size one byte and not including a sizeof factor.

• Mistakes concerning getopt:
  • A lot of people forgot to put : after both s and p. You can't have a parameter on the option unless the colon is after it.
  • getopt can return ? Some people didn't include that as an option in their switch.
  • My feeling is that you should ALWAYS put a default on switches.
  • Several people had the command line parsing in the wrong place. It should go last since it overrides the other choices.

• Mistakes concerning getenv:
  • Some people didn't test the NULL return case.
  • One person tested for the string that contained a '\0' rather than a NULL return value.
  • Also, I feel that you should do an explicit == NULL test rather than detecting whether pointers are 0.

• Mistakes concerning error messages:
  • Some people wrote some of their error messages to standard out.
  • When you give a usage message, you shouldn't hardcode in the program name. Always use argv[].

• Testing:

  Some people thought putting a statement of the form "I tried a lot of values and it seemed to work" was sufficient.

  I would recommend that you make a table of test cases:

  
        Command line       MAIL     MAILCHECK    MAILPATH   Result
  

  and organize your testing in a table. You should have your table prepared in advance of sitting down at the terminal or your testing won't be systematic.

  I was also curious about how some testers distinguished between taking the time interval from the default, command line or MAILCHECK when they set each instant to 10 or something close to 10.

• Documentation:

  There wasn't much. You should at least have each function and main program identified with a brief header.

[1/21/98] Question: I copyed the program 2.10 and changed "oshacker" to my name. No matter what, it beeps every 10 seconds. Even if I do not have any incoming mail. Could you please tell me why?

Answer: The mybiff program in the text beeps as long as your mail inbox is not empty. I recommend that you use mailx to read your mail. When you save a message (s) or reply to a message (r) or explicitly delete a message (d) or read the message and then quit from mail (q) rather than exit from (x), the message is removed from your inbox. If you x from mailx or don't read the message, it is still there the next and the file still exists.

[1/20/98] Question: The lint output on my code keeps generating messages about some external variables that are not initialized or used. The -m and -u options are not turning these messages off. I tries the -x option and it did turn them off; however, this is not in line with the specs on the assignment. Also, the lint output includes messages regarding return values for fprintf, close, and sleep (obviously, I failed to error trap those statements). Questions: Should we not get the external variable messages with the -m option; and, if not and we still do, can we use -x? What else does -x do? Are we to error trap the fprintf, close, and sleep statements?

Answer: You may also use the -x option. You do not have to trap errors for fclose and fprintf but you must for fscanf and you probably should for sleep.

Answer: Program 2.10 hardcodes in the path (/var/mail) and the user (oshacker). These are used to get the username to replace oshacker.

[1/20/98] Question: I have tried printing a "New mail for:" message; however, since the process is running in the background, you do not get a new prompt after the message. It can really be irritating and confusing. I suppose the process could fork() and have the child write the message. Or there could be another option flag that allows the user to choose whether to have the message written to the screen.

Answer: Well forking a child isn't a bad strategy, but you shouldn't be printing a message unless you are guaranteed that you are starting mybiff from the console window. This isn't in the spec which is to just ring the bell.