The Systems Research Group

Networks and Operating Systems

Part II/Diploma Project Suggestions, 1998-1999


Operating Systems Related Projects


QoSbars for Linux

Implement an atropos-like process scheduler for another operating system (e.g. Linux) and see how reliably it can give cpu ``guarantees''. Maybe some other ``nemification'' of Linux would also be plausible.

Foreign Library Loaders

Some useful code is available only in binary form, for example 3D card device drivers. It's usually packaged in the form of a shared library - either a Linux ELF .so file, or a Windows DLL. It would be nice to be able to load and use these libraries under Nemesis.

The project would consist of loaders for ELF and Windows DLL files (documentation for these file formats is available). The loader may have to mess around with virtual memory if the libraries are linked for a particular virtual address and do not include relocation information. You may also need to generate stubs to translate calling conventions between modules.

Resource Estimation and Admission Control for Multimedia Operating Systems

A project related to Measure, named Entropic, has developed a toolkit which incorporates statistical estimators which are capable of taking an input stream of data measurements, and computing the effective resource requirements of the traffic. Bursty multimedia applications consume system resources such as CPU and memory, in a similar way to their bursty consumption of bandwidth when they transmit multimedia data on a network. We need to measure the performance of a range of multimedia applications, such as a motion JPEG video application, and others, to determine how well our estimators are able to gauge the effective resource requirements for these applications.

The project will involve the instrumentation of a set of multimedia applications, and possibly the development of new applications. Using kernel and device instrumentation in Nemesis, the project will take traces of system activity and will send these over a network to the Measure Toolkit, Mtk, where the estimation of resource requirement can be done. The estimates could be fed back to the QoS manager on Nemesis to allow the OS to decide whether or not to start additional applications, and how to partition its capacity amongst the contending applications.

Signalling on the Nemesis Operating System

DCAN starts from the premise that control/management functions of the various devices that make up such a network - typically ATM switches - should be extracted from the devices themselves and be delegated to external workstations dedicated to that purpose. There is an implementation of the DCAN control architecture that allows users to set up connections between two endpoints in an ATM networks (signalling). The control architecture uses either DIMMA on top of CORBA or the ANSA/RT distributed computing environment. It would be very useful if it were possible to access the DCAN Control Architecture from Nemesis machines. Note that it is not essential that the whole DCAN Control Architecture is ported to Nemesis, because the signalling is not thought to be a real time task.

The project could start with accessing the control architecture using ANSA/RT. There exists a very basic and incomplete implementation of this in the Nemesis world already. This could be used to 'do things properly'. When this is finished we could take this a step further by implementing DIMMA on Nemesis and providing means to access the control architecture via DIMMA.

VNCFB

Implement a framebuffer device driver for Nemesis that outputs to a remote VNC client. This should be quite easy, except that TCP is a prerequisite...

3dfx window manager

3d graphics cards provide support for mapping bitmaps from texture memory into the framebuffer under a variety of transformations. One amusing way to build a window system would be to render the contents of windows into texture memory, and use the 3d card hardware to perform clipping, manage the stacking order, etc. It should be possible to support things like alpha-blended windows, distorted windows, etc. at little extra cost. This project depends on the availability of programming information for 3d cards.

Font management for Nemesis

At the moment, all Nemesis applications have access to only one, bitmapped font. There are a number of freely-available font rendering programs that could be adapted to Nemesis (for example FreeType). Beyond the simple matter of porting it, there are some interesting things to think about: how do you manage a cache of rendered fonts shared between several clients? Whose processor time is used to do the rendering? Do you trust a font that's been rendered by a different domain? When do you throw away a cached font?

I've come up with an interesting way of managing a shared cache of rendered fonts using the experimental Nemesis memory system. Contact SDE for more details.



Project enquiries to:

Austin Donnelly, Cambridge Computer Laboratory, Austin.Donnelly@cl.cam.ac.uk
Stephen Early, Cambridge Computer Laboratory, Stephen.Early@cl.cam.ac.uk
Dickon Reed, Cambridge Computer Laboratory, Dickon.Reed@cl.cam.ac.uk

HTML gripes to:

Richard Mortier, Cambridge Computer Laboratory, Richard.Mortier@cl.cam.ac.uk


Last updated: $Date: 1998/09/10 13:54:47 $