CS 452/652 Fall 2023 - Kernel (Part 2)
(Version: 1)
Due Date: Fri, Oct 6, 2023, noon
Introduction
In the second part of your development of the kernel, you make it possible for tasks to communicate by message passing. You use this capability to create a name server. By the end of this part of the kernel you must have:
- implementations of Send(), Receive() and Reply(),
- a running name server, created by the first user task, and
- implementations of WhoIs() and RegisterAs() as wrappers for Sends to the name server.
The task id of the name server must be known to the RegisterAs() and WhoIs() routines, which are executed by other tasks.
In addition to the kernel primitives, the FirstUserTask, and the name server task, you must program a game server and some game clients. The server is the custodian of a Rock/Paper/Scissors game; the clients play the game against one another by interacting with the server.
Finally, we would like you to measure the time (in microseconds) for Send/ Receive/Reply transactions in 12 conditions generated by compiler optimization (off and on), Send/Receive order (Send before Receive and Receive before Send), and message size (4, 64, and 256 bytes).
Description
Kernel
To accomplish this part of the kernel you must have the following kernel primitives operating:
int Send(int tid, const char *msg, int msglen, char *reply, int replylen),
int Receive(int *tid, char *msg, int msglen), and
int Reply( int tid, void *reply, int replylen ).
See the kernel description for the details of how these primitives should operate.
In addition you must program the FirstUserTask, which initiates the application. It, or its children,
- creates the name server,
- creates the Rock/Paper/Scissors server, and
- creates the Rock/Paper/Scissors clients.
The interaction between these tasks tests your kernel and name server.
The RPS server should be able to support multiple pairs of clients concurrently.
It needs to accept and provide service for the following three types of request.
- Signup. Signup requests are sent by clients that wish to play. They are queued when received, and when two are on the queue the server replies to each, asking for their first play.
- Play. Play requests tell the server which of Rock, Paper or Scissors the client chooses on this round. When play requests have been received from a pair of clients, the server replies to both clients, giving the result.
- Quit. Quit tells the server that a client no longer wishes to play. The server replies to let this client go, and responds to the next play request from the other client by replying that the other player quit.
The RPS server should log requests to the console, so that console output can be used to trace client/server interactions and game play.
Clients that play the game should
- find the RPS server by querying the name server,
- perform a set of requests that adequately test the RPS server,
- send a quit request when they have finished playing, and
- exit gracefully.
RPS clients should log requests and replies to the console, so that console output can be used to trace client/server interactions and game play.
We'll be running your game server and clients and manually reviewing the results, so try to keep your tests both short and informative. If your test is generating thousands of lines of output, that's too much! If there are multiple separate tests, make sure they are delineated in the output (or consider prompting for input between tests so that test runners can control the pace).
Performance Measurement
It is already possible to measure the performance of the most performance critical parts of your kernel. The following describes a few tests that you must do, handing in the results. For this assignment, you need to measure the time taken by a Send/Receive/Reply sequence, under 12 different conditions:
- compiler optimization on (O3) or off,
- execution order (Send first vs. Receive first), and
- message size: 4 bytes, 64 bytes, or 256 bytes.
To perform the test instantiate exactly two tasks: one task sends a message to the other, which receives it and then replies. They should repeat the exchange often enough that you get a good estimate of the time taken by Send/Receive/Reply. Measurements should be reported in microseconds.
Give some thought to measurement precision, and explain your measurement methodology in your assignment document.
Your measurements should be reported in a CSV file with 12 rows, one row for each condition you test.
Each row should consist of 4 comma-separated fields:
- opt or noopt - indicating whether optimization enabled or not
- R or S - indicating receiver first or sender first
- 4, 64, or 256 - indicating message size
- the measured time per SRR operation in microseconds
For example, a row might look like
opt R 64 187
This indicates a measured time of 187 microseconds for an SRR with compiler optimization on, receive before send, and 64-bytes messages.
Notes
- Message size X means X bytes sent and X bytes replied.
- Use task priorities to ensure the order of send and receive.
- Optimization off means no optimization flag; optimization on means using the -O3 compiler flag.
- If your kernel does not work with optimization enabled, record 0 as the measured SRR time for tests with optimization on.
Hand In
Your group should submit a PDF document into the K2 dropbox in Learn by the assignment deadline. The PDF should include the following information:
- The names and student IDs of your group members.
- The name of your group's code repository in Gitlab (git.uwaterloo.ca), and the commit SHA for the repository commit that we should review.
Your commit must have been created before the assignment deadline.
- A description of the structure of your kernel so far. We will judge your kernel primarily on the basis of this description. Describe which algorithms and data structures you used and why you chose them.
- A description of your RPS game test - what it does and what the output should show. (We will be running your test.)
- A description of your performance measurement methology (how do your tests work?) and a brief summary of conclusions you can draw from your test results.
In addition, the following material should be present in your git repository, in addition to your code:
- A README file indicating how to build and run (a) your RPS game test, and (b) your performance measurements. We should be able to build and run your code in the linux.student.cs environment without having to edit any files. We'll be running your RPS game test, and using the description in your PDF file to interpret the results.
- A CSV file called PerfResults.csv, containing the results of your experiments.