|
SRG:
NetOS: Student Projects |
Student Projects on PegasusBelow is a list of possible Part II student projects involving the Nemesis operating system. If you feel interested in any of these, you should get in touch with one of the named contacts in the first instance. They will be happy to discuss the project and suggest suitable supervisors. Other SRG network-related Part II projects can be viewed at the these project pages. A list of previous Nemesis projects is also available.
Each of the below projects has an associated rating; these were compiled from the opinions of the various members of the groups, which in some cases varied wildly. Click on the relevant link to get the individual ratings.
DISCLAIMER: simply completing one of the projects listed below does not in any way guarantee a good result. Many of the projects are open-ended, and others are simply vague. In all cases, a discussion with one of the contact persons will aid in understanding the scope and degree of computer science required for a project.
For more details on Nemesis see the Pegasus area on the laboratory's anonymous ftp server, and also the Pegasus WWW area. In previous years a short seminar has been given by members of the Pegasus group for the benefit of Part II students interested and considering a project in the group. Details are yet to be announced. Last year a number of students worked in this area and went on to be Research Students or Research Assistants working in the group.
For all Nemesis projects the special resources "a computer lab account", and "access to pegasus group workstations and hardware" will be necessary. The group will provide sufficient disk space on its servers. There are some conditions to working on Nemesis; further information can be found in discussion document 15.
Nemesis provides an environment in which continuous media streams can be handled efficiently. An audio processing suite could be implemented, perhaps including some of the following:
Contacts:
Stephen Early,
Dickon Reed.
Currently Nemesis provides mechanisms for Quality of Service, but no policies. It would be interesting to construct a system which tracks where the user is looking and gives the best quality of service to that application. This can be done using an infra-red LED and a camera; light from the LED is reflected from the eye, and a program works out the relative positions of the reflection and the pupil. Gaze information could then be integrated with the window system and QoS allocation mechanisms of Nemesis to move resources around based on which window the user is currently focused on. e.g. between multiple video windows.
This is likely to be a difficult project. Here is a current commercial version.
Contacts:
Paul Barham.
Contacts:
Dickon Reed.
Nemesis is designed for the processing of continuous media. One application of this is to arrange for a video camera to track interesting objects, where "interesting" might include an individual, any circular object or any yellow object!
Ideally this project would include driving a "pan and tilt" unit to keep the subject centered in the camera's field of view. However it is not yet clear that such an item will be available. Nonetheless, the difficulty and computer science in this project involves the determining of the subject's location and computing its motion vector.
Contacts:
Dickon Reed,
Stephen Early.
A key feature of this project should be to exploit the QoS guarantees of Nemesis to allow these processing elements to degrade or adapt in the face of resource scarcity.
Contacts:
any.
Write an application to monitor many video streams. If anything interesting is detected, record it and display it at the same time. This is completely open ended! Perhaps the application could recognise various well-known people. Perhaps it could "track" perpetrators around the room. Perhaps it could invoke some sort of high powered laser server to eliminate said perps. The choice .. is yours.
Contacts:
Stephen Early,
Dickon Reed.
Recently, a number of tools have evolved for real-time profiling of operating system code (e.g. etp, ATOM). This project would involve applying either one of these tools, or a new one developed by the student, to profiling the Nemesis operating system, followed by analysis of the results.
Contacts:
any.
Nemesis, along with other real-time operating systems, is designed to enable fine-grained quality of service guarantees to be made to applications. This means that the processor must context switch between different applications at a much higher frequency than on conventional operating systems.
Modern processors are not designed to do this- they are pretty fast but they can't turn corners. They contain internal state that records past behaviour of a program in order to optimize current execution (instruction, data, branch prediction, and jump target caches etc.) Unfortunately, context switches typically cause all the accumulated state to be discarded.
The aim of this project is to measure how context switch frequency affects the performance of modern processors like the Alpha 21164 and Pentium Pro. This can be done by devising suitable experiments in which multiple applications (such as those in the SPEC benchmark suite) are run in parallel on a single processor. The end result could be a new set of Operating System and processor benchmarks which give an indication of how well the CPU can be multiplexed between a number of concurrent tasks.
This project is research. It requires some good experimental computer science, but needn't be particularly difficult for someone with reasonable knowledge of C and the operation of microprocessors.
Contacts:
Ian Pratt,
Steve Hand.
Nemesis is supposed to provide an environment for soft-real-time processing of audio and video streams etc. Standard benchmarks measure batch jobs and so are inappropriate. This project would develop some soft-real-time benchmarks such as context switch time, interrupt latency, device driver performance and so on and use them to measure (and perhaps improve) Nemesis.
Contacts:
Paul Menage,
Steve Hand.
The Nemesis operating system is structured around a set of interface types, resulting in a strongly object-based style of programming. Currently C is used throughout, with certain restrictions on its use.
The investigation of how C++ can be mated to the Nemesis model of objects could form a student project. The project would involve design work on mapping the MIDDL interface definition language and type system onto C++, followed by the implementation of a C++ back end to the middlc compiler and a C++ runtime system over Nemesis.
Contacts:
Dickon Reed,
Steve Hand
The Nemesis operating system is structured around a set of interface types, resulting in a strongly object-based style of programming. Currently C is used throughout, with certain restrictions on its use.
The investigation of how Modula-3 can be mated to the Nemesis model of objects could form a student project. The project would involve design work on mapping the MIDDL interface definition language and type system onto Modula-3, followed by the implementation of a Modula-3 back end to the middlc compiler and a Modula-3 runtime system over Nemesis.
Contacts:
Paul Menage,
Dickon Reed.
Contacts:
Dickon Reed,
Austin Donnelly.
This project will involves designing and implementation a suitable selection of thread schedulers incorporating various QoS and scheduling policies.
Contacts:
Paul Menage,
Steve Hand.
The Nemesis operating system defines a method of raising and catching exceptions, in a manner similar to that of Modula-3. This is currently implemented rather inefficiently using C setjmp() and longjmp() facilities.
A better system would be to use PC-range tables for working out where exception handling clauses in the code are positioned when unwinding the call stack after an exception has been raised. Some code for this already exists.
Contacts:
Herbert Bos,
Paul Menage.
Nemesis is written in a way which means that device drivers can demultiplex data directly from the network to the application memory - the protocol code is located in the applications for Quality of Service reasons. This is achieved using "packet filtering". One means of specifying a packet filter is by using a program written in a (often overly) restrictive bytecode which the device driver executes. These "programs" must obviously change when a network connection is created or deleted.
Whilst this bytecode is a simple means of describing a packet filter, it is often hideously inefficient. A more sensible implementation would be to dynamically synthesize native code. Common packet filters could be "hand-crafted" so long as they conform to the same MIDDL interface.
You should be competent at assembly language programming before attempting this project.
Contacts:
Neil Stratford,
Austin Donnelly.
Nemesis uses an Interface definition language (similar in concept to Modula-3) called MIDDL to specify all major interfaces within the operating system and between clients and servers. A compiler written in the python scripting language converts this into Remote Procedure Call (RPC) stubs which transparently marshal arguments and results of a procedure call and perform the remote invocation.
Currently it is the case that all necessary marshaling code and RPC stubs must be compiled into the boot image or explicitly loaded by application code. This is both inconvenient and can take up a lot of memory. An alternative would be to have a single marshaling engine which operated on a compact "bytecode" representation of the MIDDL interface. RPC stubs could then be dynamically synthesized whenever required. The same representation would also be useful for communicating MIDDL interfaces between interface repositories on different Nemesis machines.This project would design the byte code, write the marshaling engine, and change the python to generate the byte codes instead of the C stubs.
You should be happy doing assembler programming to attempt this project.
Contacts:
Dickon Reed,
Richard Hayton?
Since Nemesis runs within a single address space, it is possible to run it as single process under Unix. This project would take Nemesis and add support for running over the "virtual hardware" provided to a Unix process: for example, timer interrupts can be emulated using alarm signals, mprotect(2) to emulate the MMU, etc. Once the basic features work, some device drivers might be written, e.g. a frame-buffer using X11, or a network driver using SOCK_RAW sockets.
Contacts:
Stephen Early,
Austin Donnelly.
The Alpha based Nemesis machines are more than powerful enough to deal with a 155Mbit/sec ATM network at full load in both directions. This project would modify the device driver so that the network receiver all cells and then writing some software that would use this machine as an ATM network debugging tool doing this like:
An alternative might be to attempt to measure the kinetic entropy of passing traffic which is of substantial research interest.
Contacts:
Ian Pratt,
Simon Crosby.
As bandwidth gets cheaper it may become feasible to play games remotely - rendering would be done at a central location, and the video would be distributed to the players. Latency would be the biggest problem. To investigate this, a "remote play" system could be constructed to enable a console in Glasgow to be used from Cambridge over our ATM link. It's pretty simple to cut the end off a controller for a Sony Playstation and send the 8 bits of data across a network, but how do you send the data from a "light gun" across a network so that it means something to the other end?
This project would probably involve building a small amount of hardware and programming microcontrollers.
Contacts:
Paul Barham,
Stephen Early.
At the moment Nemesis enforces no single high-level security abstraction. At the lowest level, of course, the operating system ensures that peer-to-peer communication bindings (event channels) can not be 'faked'. Over the top of these mechanisms it should be possible to efficiently implement a number of security and acces-control schemes.
One interesting example is the security model developed by Richard Hayton as his Ph.D. thesis. This project would port his code onto Nemesis and apply it to application-level RPC/IDC service binding so that clients could only bind to servers "if permitted".
Contacts:
Paul Menage,
Richard Hayton?
Traditional UNIX file systems are not in general capable of delivering consistently quality bandwidth data streams to and from hard discs. Nemesis provides a platform upon which device drivers present applications with a guaranteed Quality of Service (QoS) and so a general purpose filesystem could be designed so as to be equally suitable for multimedia and conventional data storage.
Contacts:
Paul Barham,
Neil Stratford.
