CS252: Spring 2001 Project Suggestions <Under construction!>

---

This document is divided into several sections associated with projects.

The IRAM Project

1. Build a performance simulator for VIRAM-1

Suggested byChristoforos Kozyrakis (kozyraki@cs.berkeley.edu)

VIRAM has an instruction set simular to show proper execution of programs, but no performance information. Instead, it produces a trace that can be feed into another program that calculates the number of clock cycles for that program. The original performance simulator was written early in the process, before we had settled on many key parameters, and that student graduated a while ago. The suggestion is to start with a clean slate and build in most of the key parameters thereby considerably simplifying (and speeding up) the performance simulator. Thus this does not need to interpret instructions, just calculate clock cycles. We would still like to vary a few paramters, such as the number of elements executed each clock cycle ("number of lanes"). The VIRAM architecture is online, although you should talk to Kozyrakis before getting started. The old Performance Simulation Manual is also online and available if you are on the Berkeley campus.
 

2. Port Berkeley Multimedia Workload to VIRAM

Suggested by Kathy Yelick (yelick@cs.berkeley.edu)

The Berkeley multimedia workload was developed in order to facilitate studies on architectural support for multimedia. These 16 kernels were written orginally in C and then tuned by hand for all existing SIMD multimedia architectures. VIRAM is a vector computer designed for multimedia, and it comes with a vectorzing compiler.  The first step, after reading the papers above, would be to evaluate try the compiler on these kernels. The next step would be to code these by hand to see the performance improvement over compiled code and to compare to the computers with SIMD extentions. Metrics could include clock cycles, time, code size, power, percent vectorization, and relative performance of compiled vs. hand tuned code. As C does not have language support to express some of the DSP primitives (e.g., saturating arithmetic), you might also suggest what changes would be needed at the language level to be able to express these kernels. Christoforos Kozyrakis (kozyraki@cs.berkeley.edu)has C and VIRAM hand-tuned versions of other media kernels as a place to start on the IRAM version. VIRAM architecture is online, although you should talk to Prof. Yelick and Kozyrakis before getting started.
 
 

The ISTORE Project

1. Availability Benchmarks

Suggested by Aaron Brown (abrown@cs.berkeley.edu)
The availability benchmarks discussed in Chapter 6, and also in a USENIX paper,  can be extended in projects.
• Tools for Availability Benchmarks. The idea is to modify device drivers to be able to precisely insert common failures at the device driver level in software to simulate hardware failures. Aaron Brown can point you at common failures for disks and networks. These are similar to failure breakpoints, but one issue is what mechanisms make sense to specify when a failure should occur. There are probably two projects here: one for networks and one for disks. Linux drivers would be the most likely target.
• Availability Benchmarks on other systems. The Cobalt PCs have a failover mechanism for software servers which consists of shipping data over another Ethernet link to a shadow PC, which can then take over for the master if the master fails. It is called StaQware Cluster. One application is Cobalts Intershop Commerce software which makes it easy to set up a product selling internet site. The idea would be to get it running and then force faults to happen and watching how the system behaves. This data would be plotted against a workload to see what happens, similar to the RAID failure paper.
2. Maintainability Benchmarks

Suggested by Aaron Brown (abrown@cs.berkeley.edu)
Maintainability benmarks are even more challenging, as they tend to involve the human element. Nevertheless, to get started it would be worthwhile reporting on individual experience and then think about what it would take to turn it into a benchmark that many people could try.
• Databases. Commercial databases can generally be downloaded for free for a 30 day basis. Try downloading several, set them up in some standard TPC configuration such as TPC-C, and then see how easy/difficult it is to add a node to the cluster, or add a warehouse to the database. Does this vary by database product? Part of this project will be to think about metrics that you can use

to report/compare the difficulty of these tasks.
• Operating systems.  For Linux and FreeBSD, how long does it take and how hard is it to switch the 'personality' of a node, say from one web server to another or from a web server to a database server? How hard is it to add nodes to scale up the capabilities of an application?
3. Tools for Network Instrospection

Suggested by Eric Anderson (eanders@cs.berkeley.edu)
It seems strange that we connect a network manually and then by trial and error see if we connected it as we expected. Why can't the system discover topology automatically, and then analyze it for failures? For example, if this switch fails, the network is partitioned. Write a program that can discover state, such as the topology of a switched LAN, using whatever tools are available: e.g., SNMP. Can you find single points of failure?
4. Making NFS More Robust

Suggested by Aaron Brown (abrown@cs.berkeley.edu)
Most software does not detect and report failures up to the application, thereby preventing the application from reacting to failures. This project would be to look at the APIs of NSF, and possibly modify the client-side NFS implementation in Java that Sun provides. If time permits, a simple application would use that interface to handle an inserted failure.
5. Visual Google (Voogle? Goggle?)

The Putting It All Together section of Chapter 7 lists the hardware required to run Google, which does searches and indexes for text on the WWW. This section also gives the cost of collocation space and bandwidth for that equipment. This model would be to look at an equivalent service but for images. The first step would be to get some estimate of how many images are on the WWW, and what is the rate of growth. The second step would be to calculate the storage capacity required to keep local copies of images, so that they could be indexed and offered as cached copies. The third step would be to calculate the time to index the images using image recognition technology. David Martin (dmartin@cs) has been investigating what it takes to process images, and so he would be a good person to contact. (The algorithms still need to evolve to get greater accuraccy, but for the purposes of this project we  assume that they are a good estimate of how much processing will be needed by the evnetual version of the algorithms.) What are the relative amount of machinery, cost of space and bandwidth for a Voogle vs. a Google? How good a match is ISTORE to the needs of Voogle?
6. Survey the products that support "3 tier applications" How dynamic are they? How well would they run on ISTORE? One starting point might be Cobalts Intershop Commerce software.