5.1 Building NetTV

This section describes the structure and modules of the NetTV appliance, how paths are created, and what attributes are involved in path creation. It also provides evidence that the performance of NetTV is reasonable given the hardware that it is running on.

5.1.1 Module Graph

The complete Scout module graph of NetTV is shown in Figure 24. A brief explanation of the modules appearing in this graph is given in Table 12. In the figure, each arc is labelled by the pair of interfaces that are used to communicate along the arc. If this label contains just a single name, it means that the interface by that name is used to communicate in both directions (up and down). If the label contains two names separated by a slash (/), the first name refers to the interface used when communicating from the module above to the one below, and the second refers to the interface used in the reverse direction. For example, the label framebuf/<null> near the arc between WiMP and TGA indicates that TGA provides a framebuf interface to WiMP and that WiMP does not provide an interface to TGA. A description of interfaces appearing in the graph is given in Table 13.

The operation of most modules is readily understood from the descriptions given in Table 12. The MPEG decoder deserves additional attention, however. MPEG expects the compressed video messages to contain an integral number of MPEG macroblocks. The number of macroblocks per message is expected to be small enough so that the message size does not exceed the maximum transmission unit (MTU) of the network link. This kind of application-level framing (ALF) [16] ensures that the MPEG decoder does not reach the end of the message in the middle of a complex operation. This simplifies the MPEG decoder, reduces queuing inside video paths, minimizes the number of context switches required to process a message, enables integrated layer processing [16], and enables early load shedding, as will be explained later.

Another aspect of the module graph that may not be entirely obvious is that STDIO is connected to TERM by three separate arcs. The former module implements C standard I/O library functions such as fopen and printf in terms of Scout paths. These functions can be called by any other module in the graph and are provided as a convenience and to facilitate porting existing software to Scout. To implement these services, STDIO has one service access point that it expects to have at least three connections. The first connection is used for standard input (stdin), the second for standard output (stdout), and the third for standard error output (stderr). In the NetTV example, these are connected to TERM, so all standard I/O occurs through a terminal emulator window. If more than three connections are made, then paths through those additional connections can be created by calling fopen with a path name that starts with the module name to which which the connection leads (if multiple connections lead to the same module name, the first one is used).

5.1.2 Paths

Given the module graph, how are paths used in the NetTV appliance? As discussed in Chapter 2, an initial set of paths is created at system boot time. The initial paths for NetTV are shown in Figure 25. As the figure shows, module STDIO creates three paths to TERM---one each for stdin, stdout, and stderr. These paths are created so error logging and keyboard I/O can be performed through the windowing system (by default, standard I/O is connected to the boot console, if there is one). Module TERM realizes this I/O by creating a path to WiMP. This path provides a window on the output side and provides access to keyboard and mouse events on the input side. WiMP itself creates paths to TGA, KBD and MOUSE so it can access the graphics frame buffer and receive raw keyboard and mouse data, respectively. In the networking subsystem, ICMP creates a path through IP to handle ICMP requests. Module IP creates a path to ARP so it can translate IP addresses into link-level (Ethernet) addresses. ARP creates a path for its own use through ETH to be able to receive and respond to ARP messages and, finally, module SHELL creates a path through UDP so it can receive commands from the network.

5.1.2.1 Shell Commands

Once the shell module has created its path through UDP, it simply waits for command messages to arrive. When such a message arrives, it interprets the command and executes it. In Scout, interpretation involves translating the command and optional parameters into appropriate attribute sets, and execution corresponds to making pathCreate and pathExtend calls as necessary. Note that in this configuration, shell commands come in from the network, not from a user typing at the keyboard.

The syntax of shell command messages is similar to UNIX-style command lines. Each message simply contains a text string that is interpreted as a command with a list of associated parameters:

command-name (option-name[=option-value])...

Note that the shell needs to have explicit instructions on how to translate each command into one or more appropriate paths. In a sense, these instructions most closely resemble what is traditionally regarded as the application---the modules in the paths that are providing the desired semantics are generally unaware of, and do not have to know about, how they are being used. That is, the majority of modules are expected to resemble simple filters.

5.1.2.2 Video Paths

Figure 26 shows a typical NetTV video path. One such path is created for each video to be displayed on the appliance. Each video path starts at the Ethernet device driver (TULIP), goes through the network subsystem, the flow-control protocol (MFLOW) and the MPEG decoder, and then through the window manager (WiMP) to the graphics frame buffer (TGA). For simplicity, only the main queues are shown: the input queue in module TULIP and the output queue in TGA. Both queues are serviced by interrupt handlers. In the Ethernet device driver, the queue is filled in response to receive interrupts, and in the frame buffer module, the output queue is drained in response to interrupts that indicate the beginning of a vertical synchronization period. Output to the display is synchronized to this signal because there is no benefit to updating the display at a higher frequency.

There are three points worth emphasizing about these path. First, there are no queues other than the ones in the device-drivers. As mentioned above, this is due to MPEG's use of ALF. Second, ALF---along with explicit paths---enables integrated layer processing. Since MPEG reads the network messages in units of 32 bits, it would be straight-forward to integrate the (optional) UDP checksum with the reading of the MPEG data, for example. This would require a path-transformation rule that matches MPEG being run over UDP. If this pattern were to match, the path could be transformed by replacing the UDP and MPEG receive processing functions with functions that implement the UDP checksum computation as part of MPEG's reading of the packet data. Third, without queuing in the middle of the path, scheduling is simplified---if the output queue is already full, there is little point in scheduling a thread to process a packet in the input queue. This implication would not hold in the presence of additional queues.

5.1.3 Base Performance

It is interesting to compare the base performance of Scout NetTV to a general purpose operating system running on the same hardware. To this end, Table 15 shows the maximum frame rate that Scout and a Linux-based video decoder can achieve for various short videos. Along with the maximum frame rates, it also lists the length of the video in number of frames. All measurements were performed on a first-generation 21064A Alpha running at 300MHz. The Scout and Linux MPEG-decoder were derived from the same code base [74], so the only significant difference between the two systems is that Linux requires a context switch to move a video frame from the MPEG decoder process to the windowing system (X11). Since almost no time is spent in the networking subsystem, the performance of that subsystem does not significantly influence overall performance (in fact, separate measurements yielded roughly the same maximum frame rates when sourcing the video from the local disk, or more precisely, the disk cache).

As the table shows, the Scout appliance consistently outperforms the Linux based system by 20-34%. Of course, this is to be expected given that Linux is a general purpose system and the Scout appliance is relatively custom built for the purpose. For this reason, it would not be fair to say Linux is slow (indeed, it performs quite well), but the comparison does show that Scout achieves a performance level that is at least consistent with the machine it is running on.

The comparison also illustrates that if the goal is to build an information appliance that displays MPEG encoded video, and nothing else, then a configurable system like Scout might indeed be the better choice. A simple application like this one results in a Scout kernel that is both small (roughly seven times smaller than the Linux kernel) and fast (20-30% faster than Linux for the benchmark videos).