Evaluation and Examples

Evaluating uses of Discovery and examples illustrating its use.

Examples

Examples are the best test cases for evaluating our implementation behind identifying computation structure of a particular application.

The List below is divided into two parts namely hand written regression tests and Real World Applications. We need hand written regression tests to evaluate the correct- ness of our implementation.

Regression Tests

We have regression tests that cover all the different types of InterProcess Communication namely, Fork, signals, shared memory, Pipes, Named Pipes, Sockets and Files. Where: kusp/workspace/discovery/regression/

Fork - MultiThreads

• Why: Identifying the different threads that an application can fork off as part of its computation.
• How: This example creates the stipulated number of threads as provided by the user using the pthread library. Each created thread sleeps for 5 seconds before exiting. The main thread just forks off all the threads and waits until all the threads are finished and then exits.
• Where: multiThreads/multiThreads.c

Signals - Signal Pipeline

• Why: Identifying signals and their types that can be sent among threads in a computation.
• How: As the name suggests, we try to construct a signal pipeline. we fork off as many threads as required and the pipeline is actually seen when the main thread starts sending a signal to the first thread and the first thread then transmits the signal to the second thread and so on. The signal type SIGUSR1 is used in this experiment.
• Where: unified_sigpipe/sigpipe.c

UnNamedPipes - Pipe pipeline

• Why: Ability to identify the unnamed pipe IPC operations that only support communication among tasks related by forking that are part of a computation.
• How: The experiment that we have for testing Pipe IPC is a pipe pipeline where we create as many threads as required and the equivalent number of pipes which connect each thread with the next thread in the pipeline. The main thread initiates the conversation by sending some information through the first pipe and the first thread then reads the information and then writes the information to the next in the line. and so on.
• Where: pipe/pipe.c

Named Pipes - NamedPipe

• Why: Ability to identify computation’s conversation with a named pipe/FIFO. Named Pipes are used when communication among processes not related by forking is required.
• How: The experiment for this is the same as explained in the UnNamed pipe example except we use named pipes instead of pipes for conversation.
• Where: namepipe/namepipe.c

Sockets - Socket pipeline

• Why: Sockets provides two way communication between unrelated processes. There are two types,Local and Remote. Local sockets use the AF_UNIX network type and are often created using a socketpair() system call. Remote sockets use the AF_INET network type and are created using the regular socket() system call.
• How: Socket pipeline is an experiment that represents a pipeline computation using AF_UNIX Local Sockets to communicate among pipeline stages. We have another experiment that is a client server example that shows remote socket connections.
• Where: socket/socket.c

Shared Memory - Shmem

• Why: Identifying threads that connect to a shared memory segment of interest to the application.
• How: The experiment that we have creates a single shared memory segment, a server thread that writes something within the shared memory segment and a set of client threads that read from the shared memory segment.This test demonstrates that discovery can identify when a shared memory segment is created or destroyed and when a thread attaches or detaches from a shared segment. However since system calls are not involved read and write operations are not seen by the discovery framework.
• Where: shmem/shmem.c

Files - Fcntl

• Why: File open/read/write/close and also File locking using the new mechanism such as fcntl(). fcntl() is the preferred and the latest mechanism. This system call takes in different locking flags when compared to that of flock(). fcntl() is successful even on NFS files and will also be able to identify deadlocks.
• How: The experiment creates pairs of threads which fight for locking a particular file so that they can either read or write into it.
• Where: fcntl/fileLock.c

Files - Flock

• Why: File open/read/write/close and also File locking using the old mechanism such as flock(). flock() is the old method. This system call takes in different locking flags when compared to that of fcntl(). flock() will not be able to lock files that are on a NFS and deadlock detection is also not possible.
• How: The experiment creates pairs of threads which fight for locking a particular file so that they can either read or write into it.
• Where: flock/fileLock.c

Real - World Applications

Real World applications are complex software applications that are being used frequently or they represent an important class of application behaviour. These examples demonstrate how much we can learn when we limit ourselves to OS level instrumentation, treating the applications as black boxes. We use information gathered to construct views of the computation structure and perhaps statistical representations of computation behaviour.

Totem

• Why: Example of a client-server architecture on the local system, where the xserver acts as the server in this computation. It is also interesting to find what totem is up to when playing music and so on.
• How: There are various scenarios that we would like to test so that we can identify the differences in the computation structure if any. Some of the scenarios are listed below:
  • Basic test - starting and stopping totem.
  • Playing a music file having visualization.
  • Playing a video file.
• Demonstrates: With these scenarios we are trying to show what kind of relationship it is trying to have with the xserver, sound module. We also get a lot of other statistics such as the shared libraries it is trying to use, files it is trying to open and so on. Amount and pattern of data traffic to the xserver. Identifying the gstreamer setup for playing music and video.

EECS 678 PA - 1

• Why: This is another example of a client-server architecture. This example can also be used to identify remote connections being made as part of its computation. Its comparatively a very simple experiment with respect to the totem example.
• How: There are three scenarios that could be tried out here.
  • Run traceme on the server code on a differenct system where the client/clients are not running.
  • Run traceme on the client code on a different system where the server is not running.
  • Run traceme on the server code on the same system where the client/clients are also going to be executed vice versa.
• Demonstrates: This example can be depicted as a mini version of a web server. we are also showing what the computation is trying to do when it is trying to make a call to another computation on remote machines. When running on the same machine we are showing that how we are able to identify the relationships between two separate processes.

Firefox

• Why: This application is being used very frequently by almost everyone in today’s world, so it would be very interesting to know what the browser is upto when it is doing its service.
• How: The list of scenarios is given below:
  • Just open firefox and close it.
  • Open firefox and open three or four tabs with static html pages.
  • Open firefox and open a page that has a flash application embedded in it/ or a video streaming website such as youtube.com
• Demonstrates: we are trying to show the multi-threaded nature of firefox, amount of network traffic and the number of connections associated with open pages. We will also be able to show the different helper applications that are trying to make things work in these web pages.

Java - Virtual Machine

• Why: Its a process virtual machine and it would be interesting to know what a virtual machine is upto when you are actually executing Java applications.
• How: The JVM is a complicated system by itself. so the degree of discovery has to go from a simple application to a complex one.
  • Basic HelloWorld Application.
  • html editor applet that could be executed from the command line.
  • fire up firefox and have the html editor to execute there.
  • openoffice.
• Demonstrates: we are able to demonstrate how the JVM works to make sure the Java application executes correctly and also we will be able to identify what the Java application is upto as well. The applet example will help us to identify the relationship that the application is having with the xserver.

Select bitmask Programming Model

• Why: Its interesting to know and also the oppurtunity to correctly control a computation iwhich relies on a bitmask pattern to service its clients that are connected to it.
• How: We are planning to have our own experiment that has a server component and a client component and the server component services its client using the sys_select().
• Demonstrates: It demonstrates that we would be able to identify client-server computations that have a bitmask pattern of servicing clients. It is also the first step before we venture into tackling the xserver, which is complex computation by itself.

System-Monitor Examples

Until now we were looking at examples that would expose the various features of our discovery framework related to a single computation under the scanner. In this section we would be looking at experiments that would showcase the use of the systemMonitor tool.

Ths systemMonitor tool is used to gain an insight about the system as a whole. In other words, it constitutes the OS’s point of view about the various computations executing in the system.

The different experiments/scenarios that we would like to showcase is given below:

Daemon Tracing

• Why: Trying to identify what are the different applications that are connected to a particular system component which is shared among other applications either simultaneously or serially, like the xserver, dbus daemon etc.
• Demonstrates: With this scenario we would be able to identify the different applications that try to connect to a particular system component. It is possible for us to know the computation structure of the connected computation from the point it had connected to the system component and also the ability to control it.

System Resources

• Why: To know what applications use a specific or a set of system resources such as shared libraries/ system calls/modules.
• Demonstrates: The ability to know what are the actual set of system resources that are actually required so that the user is better informed in the requirements rather than overloading the system with a lot of resources that are not required. We are also trying to subsume the basic functionality of strace into a single tool.

User Application Usage

• Why: To know the list of applications that are being used by a particular user.
• Demonstrates: The ability to know all the list of applications that a particular user alongwith its frequency information. Knowing this information will help us in giving better scheduling semantics for the applications that are being used by the user.

Discovery of Multiple Computation structures

• Why: To showcase the capabilities of both the tools namely the systemMonitor and the traceme in conjunction with each other.
• Demonstrates:

To be Continued.