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
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
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 $