• scheduling
• memory management
• communications stack

In order to accurately measure these entities, the hardware platform will be chosen such that both of these operating system will support. The results of the experiment will be used to demonstrate and analyze the efficiency of commercially and publicly-available operating systems.

Implementation
--------------
Install 2 RTOS RTLinux and Ucos-ii as a dual boot
on a machine. Run certain benchmark applications
to test OS performance.

Challenges
----------
- To get RTLinux and Ucos-ii as a working RTOS.
- Getting a group of applications capable of
  running on both the OS.
- Techniques of setting benchmarks.

Requirements
------------
- A stand alone dedicated machine(We are hoping
  you could get us one).
- Access to computer science account.
- Ucos software

We propose in the time frame of the semester to do
a performance analysis for a choice of select
algorithms varied over multiple systems running on
different CPU and Memory models.

Our proposed languages for comparison are Java and
C/C++. These languages have emerged from a "close
to assembly" paradigm (the C language) to a high
level object oriented model adopted for Java.

Our main objective is to study the strengths and
weakness of these languages through the analysis
of some traditional and some specially geared
algorithm implementations.

Our metrics will be based on (in no particular order): 

[1] Speed of execution.

[2] Memory usage:

[2.1] Algorithm static memory (compiled size)

[2.2] Operation memory (during code execution)

[3] Overheads imposed by choice of language.

[4] Selective features offered by each of the
    above languages and their impacts to
    algorithms (i.e. are the features more Hype or
    a Reality?)

Our initial plan consists of using the Linux and
Windows Operating systems.

We intend to add some variety by experimenting
with *nix-flavors on different CPU and memory
models. (This will vary based on machines the
project team has access to individually as well as
shared computer resources at Columbia University).

NIC drivers for Linux

ne2k-pci.c

ne2k-pci

TULIP

DP83840A for the MII

tulip reference

3c59x.c

Please contact me to send you the technical notes with mail.

3c59x

eepro.c

eepro100

data sheets

pci-skeleton.c

data sheet RTL 8139

Useful Links

NIC info settings

Charles Spurgeon Ethernet Web Site

Networking at layer 1 & 2

What is a simulator for assembly languages? : 

A Simulator is a simple virtual machine that can
directly execute compiled files normally loaded
onto processors. It provides a way for people to
learn the essential lessons of computer
architecture and assembly languages without
getting bogged down in the confusing details and
idiosyncrasies that plague real architectures.

Which Assembly Language : 

I am interested in working with RISC architectures
and would like to build a simulator of the ARM
processor.

ARM [Advanced RISC Machines] processor:

The ARM is a general-purpose 32-bit microprocessor
based on RISC principles. Its instruction set and
related decode mechanism are much simpler that
those of Complex Instruction Set Computers [CISC]
machines. It has two instruction sets:

- The standard 32-bit ARM set

- A 16-bit THUMB set 

Feature List :

Of the two instruction sets, I am going to
concentrate on the 32-bit ARM set. One objective
of this simulator would be to enable developers to
test out their new hardware. The system must be
extensible so that it is possible to add hardware
modules in order to test the new hardware.

The features of an ARM architecture that I would
like simulate are:

- assembler: to generate exact binary/machine code
corresponding to real compiled ARM machine code
for my simulator to execute

- support a smaller number of registers (general
purpose and dedicated, e.g. stack pointer, frame
pointer)

- correct emulation of arithmetic, logical,
memory-data transfer and branch instructions

- use external compiler to generate ARM assembly
from C-code
[http://celab21.pc.elec.uq.edu.au/~tina/arm-gcc.html]

- test simulator against various real-world programs

- have a configurable way of modeling the
Instruction set and/or architecture so that newer
instructions and registers, etc can be
incorporated into the simulation

Optional Features :

If I have enough time, I will incorporate some of
the following into the simulator

- a debugger: with the ability to insert special
breakpoint instructions in the machine code, and
instruction step features

- an integrated development environment that
provides a graphical user interface

Really optional Features :

- Develop a tiny interactive shell program/OS for
the simulator that can accept program names, and
load [from host file system] and execute them on
the simulator 

• Performance comparison on interface synthesis algorithms by Passerone, Borriello, Sun, Gajski, and Akella.
• Extension of interface synthesis algorithm of Passerone to involve asynchronous protocols and streams of data.

• Time display -- both AM/PM and 24-hour modes
• World time display -- ability to show current time in any time zone
• Current date display
• Stopwatch (counter from 0 upwards)
• Timer (counter for a fixed time interval)
• Alarm

At this point, we may ask ourselves, could we go even farther? Of course we can. Once we have the service guaranteed, we work on making improvements. Up to now, since operatives systems have fit perfectly l in embedded systems, we look for quick responses. In that sense, real time operating systems began to be transported onto embedded platforms.

And, again, Linux was there to offer those improvements but with the lively open-source philosophy that makes us free. It is amazing the huge quantity of people that are actually working in the development of real-time Linux kernels (both for embedded or non-embedded systems).

Since I am interested in the Linux world and philosophy, I have thought that this is a good chance to dig deeper into the interesting topic of real time kernels in Linux.

The following describes a rough outline of my project proposal. First, I propose to study the differences between already developed kernels (including both open-source and commercial versions), and see how they are implemented. I will focus on the open-source versions, especially in those developed by Kansas University, Berkeley, Carnegie Mellon, and the Politecnico di Milano. The first step will involve the study of these kernels, their implementation, their ways of dealing with interruptions, their handlers, schedules, etc. As a second step, some testing will be done in order to observe the concordance between the theoretic development of the kernels and their practical performance. Finally, having understood the system, some modifications on the code in order to see different behaviors will be implemented.

Compare real-time and non real-time operating systems. We intend to make comparisons in three ways. First, we will compare the available facilities to support real-time operations. We will look at the types of synchronization mechanisms, task mechanism, and timers. Second, we will measure the times these mechanisms take. We will look at how deterministic the execution times are. Third, we will attempt to show that a program proven to meet its deadlines using Rate Monotonic Analysis will do so on all platforms. Or failing that attempt to explain why it did not.

We will be considering the following operating systems: Windows NT, Linux, RTLinux, and pSOS. The first two are well known non real-time operating systems. The second two are real-time operating systems. pSOS is a tradition RTOS, while RTLinux is a hybrid between an RTOS and a non real-time operating system.

In order to produce our Rate Monotonic Analysis we hope to use a piece of independently developed software. We are still trying to get a copy. This software also produces prototype code that we would then be able to execute on a given platform.