Design Project 1 Proposal Grading Notes: updated $Date: 2004/03/11 23:20:00 $

• Your proposal should have included a block diagram showing the modules and communication channels. Yes, it's true that we didn't tell you to include a diagram, but this is a complicated system and a good diagram goes a long way toward explaining what you are doing.
• Every hard-coded constant in your proposal needs to be justified. For example, if you assert that there will be 10 processes running the transcoder, you need to explain where that number 10 comes from and what factors went in to its calculation. In general, you should be very suspicious of hard-coded constants.
• Closely related: Don't try to prematurely optimize this system before you know its performance characteristics. For example, it would not make sense to declare by fiat that you will have 20 processes, each with 50 threads, to read the 1000 cameras. Why 20 processes? Why 50 threads? Why a mix of threads and processes, rather than 1000 processes or 1000 threads.
• If your web server is based on SPED, be sure to indicate what changes (if any) are needed in the operating system kernel to support a SPED-based web server. If your webserver is based on AMPED, you need to explain what benefit this more complicated design provides over SPED, in this context.
• You can't just assert that one module communicates with another: you need to describe how that communication is performed. RPC, shared memory, network primitives, and pipes are techniques that have been discussed in class.
• If your system uses RPC, you should explain (briefly) how the RPC interface is built on top of the kernel primitives provided in the assignment.
• If your system is based on shared memory, be sure to indicate how you will control access to this shared memory and handle synchronization issues.
• If your system shares memory pages between processes, you need to define a kernel interface to map these shared pages (e.g., shmget/shmat). This isn't necessary for sharing memory between threads, since threads normally share all their memory.
• Remember that the transcoder and the vision module are provided as subroutine libraries, not processes. The system will need additional code that calls these functions.
• For your web server, you need to discuss how the spotters will connect to the system, how images are chosen to send to spotters, and how the spotters' responses are correlated back with the images.
• Your proposal should explain how images that are received from the cameras end up being served in response to Web requests from the spotters. There must be a "handoff" stage in the middle where images pool so that the camera client(s) can continue to process incoming video while the Web server waits for requests.
• Say you have a pool of 1000 images. One has threat level 0.99, another has 0.98, and the rest have 0.1. You probably don't want the system to serve only the 0.99 image to every spotter who makes a request!
• Round-robin is an interesting scheduling algorithm, but you need to be careful about its use in this system. If you have 1000 cameras and decide to take 10 seconds of video from each camera, in order, then you will have a 10,000-second gap between the first time you sample video from Camera #1 and the second time. A lot can happen in 10,000 seconds.
• Because the transcoder and AI programs are likely to crash, you need to describe how your system will tolerate such a fault.
• When a response comes back from a spotter, you need to be able to match that response up with the image and the camera that generated it.
• It's better to throw away data at the beginning of your pipeline than at the end.

• If a pipe connects from process A to process B and process B dies, then A will get an error when it attempts to write to the pipe. If A dies, B will receive an end-of-file from the pipe.
• If a process dies, it does not need to be "deleted" by the operating system or another user program. Processes which exit normally or abnormally (e.g. due to a memory fault) are cleaned up automatically by the kernel.
• If you are reading from a TCP connection with 1000 byte chunks and you need to slow down the rate that the data is coming into your computer, it won't help to start reading in 1 byte chunks. This increases the overhead of reading each byte, but it won't make a meaningful difference on the rate that the data is coming in. A better approach would be to set a timer and simply stop reading on that connection for a few seconds. Once the data backs up, this will cause the computer on the other end of the TCP connection to stop sending new data.
• If your computer is running slowly at a particular task, forking off more copies of this task will not make it go faster, since all of the processes will have to share a single CPU. To the contrary, the additional context switches will add to your overhead.
• If a block of data makes the transcoder or vision software crash, then restarting the process and giving it the same block of data is likely to produce the same results. Your design should not do this.

• Your name should be at the top of every page!
• Every page should be numbered.
• You should not print pages double-sided that you are handing in. It makes them a pain to photocopy or fax.
• On a two-page paper, you should not spend 1/2 of the first page on introductory filler.
• Misspelling your TA's name is bad form.
• Turning in an 8-page paper for a 2-page assignment is bad form.
• Illustrations should illustrate the text, and the text should explain the illustration.

Your grade on the DP1 Proposal is not a contract! Your grade on DP1 is independent of your grade on the proposal. It is entirely possible for you to get an A on the proposal, and to receive a C on the DP1 assignment itself. Alternatively, it is possible for you to get a C on the proposal, seriously consider our comments, address our concerns, and then get an A on the DP1 assignment itself. (We hope that you do!) However, even if you address all our comments on your proposal, you aren't guaranteed an A on the final report; you must take an active role in flushing out flaws in your design.