Guidelines
Proposals
Final Report
Facilities
Suggestions
Ideas

The purpose of a student-defined project is to permit you to do work that will (1) involve you in ongoing research projects, (2) permit you to leverage your unique background in some way, and/or (3) leverage other work in which you are involved. In general, any special project you propose should be of a caliber that can generate results publishable in reviewed outlets like workshops or conferences (typically requiring some additional work beyond the time spent in this class). You can propose your own project or select one of the projects described below.

To propose your project for this class, you must submit the following materials:

• brief project description:
• purpose
• solution approach you intend to use (experimentation and evaluation must be part of this approach)
• expected outcome/results
• at least three different intermediate project steps, with delivery items and deadlines for each
• final project deadline sometime during the week BEFORE the class' final exam (you propose a concrete deadline)

The first step must include both development (e.g., coding, experimentation) and background work, such as producing a bibliography of relevant papers and having read them and having designed suitable algorithms/approaches and having learned or looked at suitable tools to be used for your project, including target platforms.

The second step, typically after the class midterm, should involve having produced much of the software necessary and having debugged it.

The third step should include not only software testing but also performance evaluation, on the platforms you have chosen. Such evaluations may include theoretical results if you chose to develop a novel algorithm, for instance, but your project must include experimental evaluation in addition to algorithm development.

The final deliverable not only includes the actual software but also a report, which is outlined next.

The on-line final report regarding your project should have the following parts:

• A statement of your approach to the project and the technique used to solve it -- two typewritten pages minimum, 8 pages maximum, including a list of references to related work.
• If applicable, a running program with sufficient documentation so that someone can understand your program without re-running it. Such documentation should consist of comments within the program text and of separate explanations (e.g., readme file). You should be prepared to hand in your program electronically, if requested. Most likely, you will simply schedule a demo with one of us. (please do so!)
• A conclusion, stating the main results of your work. This conclusion might contain a performance evaluation of your program or a list of next steps concerning it (what might be interesting to do next).
• How your work should be extended, what should be done to make it more useful. Maximum 4 pages, minimum 1 page.
• A one page evaluation of what you did: its usefulness in the context of other work and in the context of general research (namely, why did you do this and why was or wasn't it worthwhile doing?)
• A one page discussion relating the work you did to the topics we studied in class. Comment on what papers in class relate to what you did or to extensions of what you did, if applicable.

1. Linux `Hack' cluster: Cluster of up to eight 2-way Linux machines (physically part of the NetLab facility described next):

2. NetLab cluster machine: cluster of over 40 machines, able to emulate arbitrary Internet topologies and able to run multiple operating systems.

3. High end cluster machines, one comprised of 30 dual Itanium IIs, the other comprised of 16 8-way Pentium IIIs. Contact Matt Wolf (mwolf@cc) for more information and machine access.

4. 'Enterprise' computing clusters: (1) a typical  3-tier setup using HP Itanium-based server systems, and (2) a second setup using an IBM blade server as a backend. Contact Matt Wolf (mwolf@cc) or Mohammed Mansour (mansour@cc) for more detail and/or for hardware access.

5. Compaq iPAQ handheld computers using wireless links and new XScale-based (Sitsang) machines:

    * Running Linux (multiple configurations of Linux are available and may be installed there). Both Java and C/C++ programming are possible.
    * Ability to use dedicated base station and/or use campus wireless network, via 11MB WaveLAN wireless ethernet cards.  
    * Ability to attach and use cameras.
    * Contact Matt Wolf or Ripal Nathuji (rnathuji@cc) for additional information.

6. Embedded communication subsystems, using Intel's IXP1200 or IXP2400 network routers:
    * Contact Ada Gavrilovska (ada@cc) for more information on IXPs.

7. Large-scale visualization media, including an Immersadesk and a video wall (contact Matt Wolf for more information).

NOTE: you are not bound by the suggestions. You may interact with the instructor to define other projects.

Project Proposed by Professor Karsten Schwan

You should do the following: guest OSs running with the Xen hypervisor. The object store offers innovative functionality beyond that offered by general purpose data stores, including role based access control (RBAC) through secure labelling and label checking and improved performance isolation through differentiated storage. This project is to add substantial additional functionality to the vOSD (virtual object storage device) in Xen, with options including: (1) distributing the current single-node backend store across multiple machines (the backend uses the pvfs file system, so can be distributed without undue issues) and then cretae and experiment with additional differentiation options; or (2) adding new security functions leveraging labeling, such as data cleaning and tracking; or (3) replacing the current pvfs-based store with one suitable for distributed systems, such as a P2P file system, coupled with alternate differentiation or security policies. Interested students should contact Karsten Schwan.

Capability Adaptation Using Virtual Frame Buffer

People use a variety of input and output devices in their daily life. One problem with all these heterogeneous devices is that they are not always compatible with each other. For example, the resolution and color setting may be different for two different type of displays. People always have a hard time when switching from one device to the other in those cases. One way to solve the above problem is to do capability adaptation for the devices. We can build a capability adaptor for each device to convert the size and color setting of a frame accordingly when we move from one device to the other. However, while customized one-to-one capability adaptors work fine with a pair of devices, a common capability adaptor can scale better for tens or hundreds of devices. If we look at only output devices, the frame buffer may be a good place to implement the capability adaptor. In addition, a recent virtualization system, Xen, supports virtual frame buffer that can convert the frame buffer in the guest operating system to a virtual frame buffer, which then can be mapped to the frame buffer in physical devices. The capability adaptor can intercept the frame buffer and convert it into the right format before writing to physical devices. In that way, we will be able to utilize different devices seamlessly without worrying about their capabilities. In this project, we will first learn the split device driver of Xen and understand how virtual frame buffer works. Then we will need to come up with algorithms for capability adaptor and implement these algorithms using virtual frame buffer in Xen. As a result of the project, a demo application will be shown to demonstrate the capability adaptor is able to migrate frames from one output device to the other by considering their differences. Contact: songx at cc dot gatech dot edu.