Using SHRIMP

The SHRIMP setup may change over time. If you discover that this page contains out-of-date information, please send mail to felten@cs.princeton.edu.

There is a mailing list for people interested in using the SHRIMP systems. To join, send mail to majordomo@cs.princeton.edu, containing the line "subscribe shrimp-sys".

General Information

Machines

There are presently eight machines you might consider using. Except as noted, all are PCs running Linux. shrimpfs is the SHRIMP fileserver; it exports an NFS filesystem that is mounted on all of the other machines. node1, node2, node3, and node4 do not contain SHRIMP network interface boards; you should use them if you want to run the SHRIMP simulator.

Using SHRIMP Hardware

There is presently a two-node SHRIMP system set up; its nodes are called shark and anchovy. The Intel routing backplane of this two-node SHRIMP system is booted and controlled by a "diagnostic station" called fishnet. (Fishnet is a PC running System V Unix.)

You might not be able to rlogin or telnet directly to all of these machines. You should, however, be able to reach shrimpfs.cs.princeton.edu from anywhere, and you should be able to reach any of the other machines from shrimpfs.

Compiling and Linking SHRIMP Programs

Your program will use SHRIMP by making calls into the SHRIMP Basic Library (SBL). There is a hypertext manual for SBL. Some sample programs that use SBL are found in /u/dubnicki/examples.

Programs that use SBL should #include the file /u/shrimp/include/hw/sbl.h, and they should be linked with the library /u/shrimp/lib/hw/libsbl.a.

Trouble-shooting and Resetting the Hardware

A few crude tools are available for trouble-shooting and rebooting the hardware. All of these tools require that you be logged in as root. (No, I won't put the root password here; ask somebody.)

The program /u/shrimp/bin/hw/peek displays the current status of the local network interface board. If the last line of the output says "LOOKS GOOD!!!" then the board is probably in a good state. You can run peek any time without affecting any ongoing computations.

The program /u/shrimp/bin/hw/show gathers more information about the local network interface board, but it disrupts any packets that are passing through the board, and hence it will probably screw up any programs that are using SHRIMP. Again, everything is probably OK if the last line of the output is "LOOKS GOOD!!!".

Note that both peek and show provide information only about the local board; they don't say anything about the global state of the system. At present there is no way to do a system-wide integrity check.

If the SHRIMP hardware and/or software are hung or otherwise messed up, there are three levels of rebooting available. I will now describe them, in order of increasing power. Needless to say, rebooting will do nasty things to anybody else who is using SHRIMP at the time.

The first level of rebooting restarts the SBL daemons, which are the software processes that control the network interface hardware on each node. To restart the daemons, on anchovy run /u/shrimp/bin/hw/restartsbld.

The second level of rebooting resets the routing backplane, resets all of the network interface boards, and restarts the SBL daemons. To do this, you must have separate windows logged in to shark, anchovy, and fishnet. You should be logged in as root on shark and anchovy, and as guest on fishnet. (Ask somebody for the guest password on fishnet.) First, run "start -r" on both shark and anchovy. Both machines should stop and ask you to hit return. Before hitting return, run "r" on fishnet. Then run "stream" on fishnet. (This puts the routing backplane in streaming mode, which gives better performance than the default mode.) When that is finished, hit return in both the shark and anchovy windows, and wait for the "start" program to finish on both machines. Now restart the daemons as described in the previous paragraph.

The third level of rebooting power-cycles the routing backplane. You shouldn't do this unless you know what you're doing; in any case, you need physical access to the machine to do it. If you think a power-cycle is necessary, try to get a knowledgeable person at Princeton to do it.

Monitoring the Daemon

You can display clients joining and leaving the daemon, as well as the creation and destruction of mappings, all in real time.

The files /u/shrimp/tmp/sbld.out (for shark and anchovy).

The ideal technique for viewing these files is to run, in a separate window on shrimpfs,

	tail -f /u/shrimp/tmp/sbld.out 

(Running on any other node will only make you aware of annoying delays in NFS.)

Using the SHRIMP Simulator

There is a software simulator that behaves somewhat like SHRIMP. It runs on the four machines node1-node4. The software simulator sends its messages across TCP sockets over the ethernet, so it is much slower than the real hardware. However, the simulator can be rebooted faster than the hardware, so it is a good place to debug your programs.

Compiling and Linking SHRIMP Programs

To use the simulator, #include the file /u/shrimp/include/sim/sbl.h into your program, and link your program with the library /u/shrimp/lib/sim/libsbl.a.

The simulator does not support automatic update. If you try to link a program that uses automatic update with the simulator, the linker will fail to find the SBL_AUMap function.

There is no way to check the status of the simulator.

To reboot the simulator, on node1 run /u/shrimp/bin/sim/restartsbld. You must be logged in as root or shrimp to do this.

Monitoring the Daemon

You can display clients joining and leaving the daemon, as well as the creation and destruction of mappings, all in real time.

The file /u/shrimp/tmp/sbldsock.out (for the simulator) log the activity of the SBL daemon.

The ideal technique for viewing these files is to run, in a separate window on shrimpfs,

	tail -f /u/shrimp/tmp/sbldsock.out

for the simulator. (Running on any other node will only make you aware of annoying delays in NFS.)

Good luck!