For the course project in COMP 730, you may either do the default project, or do a research project.
Let the instructor know your rough topic interests or thoughts by email no later than midnight on Tuesday, 2/21. If your project requires access to a system or other hardware that you don't have, be sure to let the instructor know. You will then refine the idea into a more concrete proposal, which is due to the professor by Thursday, 3/7 at midnight. The final write-up and code are due to Prof. Porter by 5pm on Friday, 4/28.
The default project is to complete Labs 1--3 from OS Implementation (COMP 630), (listed here. If you have already done these exercises, speak to the instructor for an alternate assignment.
For this option, you may work alone or in pairs.
This option is somewhat open-ended. An appropriate project might repeat and extend experiments from a previous paper, evaluate a new research idea, or apply an old idea to a modern system. If you are already involved in systems research, or have a systems-related component of non-systems research, (e.g., for a COMP 991 project) you are welcome to submit a well-defined subproblem as your project for this class. The end product will be a brief written report of your results and a 15 minute in-class presentation (10 minutes of prepared material, 5 minutes for questions and answers).
Projects can be done individually or in groups of any size.
A good project has a mixture of an interesting idea or question, non-trivial implementation, and good quantitative evaluation of the idea or question. There are no fixed proportions, but a proposal that requires little coding should have more experiments, and a coding-intensive project can get by with fewer experiments.
Many systems projects make their source code available. I encourage you to use published code where it makes sense and allows you to do more interesting work more quickly. Be advised that rerunning the exact experiments from a paper with the exact same source code is an insufficient course project. Please document whether you plan to use other's code in your proposal. Also, if you think unpublished source code would expedite your work and would like me to ask an external research group for their code, feel free to ask me.
I encourage you to propose your own ideas. If you have a rough idea of what you want to do and need guidance developing a question or finding related work, please come to office hours. You may also use one of the ideas below.
A highly valuable service to the scientific community is repeating other people's experimental results. Repeated experiments are often publishable in a workshop like WDDD, or even a complete conference for sufficiently remarkable results. Also, if experiments you encounter in reading fail to isolate multiple variables, it might be interesting to "deconstruct" the experiment---testing each variable in isolation.
Unfortunately, most researchers (including graduate students) schedule their time using a shortest-deadline-first heuristic. The obvious weakness of this is that a large project cannot be completed the night before a deadline. For this project, I strongly encourage you to set internal deadlines at 2 weeks to a month granularity as part of the proposal. You are accountable only to yourself for meeting the internal deadlines, but they can help keep the project on track (you are obviously accountable to the instructor for the end result).
You should strongly consider using Git, Subversion, or CVS to perform source code control for your project and the paper you write describing it. I suggest Git or Subversion.
I also strongly suggest writing your course project report using LaTeX. It is the de-facto tool in which most CS research papers are written. While it has a bit of start up cost, it is a tool you will likely need while collaborating with other researchers.
Any group that meets the basic criteria will get at least a B (or P): something reasonable working, reasonable experiments and analysis, and a good in-class presentation. The difference between an A (H) and a B (P) is largely in the quality of the work: more features working, deeper analysis of the performance of the system, and a better in-class presentation.
Part of the feedback you can expect from the proposal are rough guidelines about what would make an A (H) project and what would make a B (P) project. Note that I cannot pre-grade a project at a fine granularity.
Research is a lot like digging for gold: sometimes you find gold and sometimes you just have a hole in the ground. A negative result can easily get an A (H) if it is accompanied by good analysis of why something didn't work. For instance, if you can't reproduce a result from 10 years ago on modern hardware, it would be a fine result to show what performance characteristics of the hardware have changed accompanied by detailed measurements. In general, make it clear that the limitation is fundamental, not simply a bound on what you could accomplish the night before the project is due.
Last updated: 2023-03-02 12:42:58 -0500 [validate xhtml]