Opportunistic operations are functions carried out by leveraging spare capacity on existing devices. We investigate the performance of implementing distributed RF functions, such as spectrum monitoring, as opportunistic operations on groups of radios and RF sensors. We assume that the primary activities of the devices cannot be fully predicted, and that opportunistic operations on a device may be preempted by its primary functions. Therefore there is uncertainty regarding the ability of RF devices to complete assigned opportunistic operations. Moreover, we assume the communications network is intermittent, lossy and low bandwidth. The network limitations create command and control uncertainty. The primary research challenge addressed in this work is to overcome these sources of uncertainty in order to carry out distributed RF operations with high probability of success, while minimizing resource consumption. The approach we have developed is implemented in a middleware layer called Management of RF Network and Tasking Infrastructure (MARTI). We use an analytic model and experiments with MARTI in a wireless testbed to quantify the impact of various strategies for mitigating uncertainty, the tradeoffs between improved communication reliability and its latency and bandwidth costs, and strategies for trading off between result fidelity and network resource consumption.

Teaching students to read and write specifications is difficult. It is even more difficult to motivate specifications---to convince students of the value of specifications and make students eager to use them. This paper describes the Groupthink specification exercise. Groupthink is a fun group activity, in the style of a game show, that teaches students about specifications (the difficulty of writing them, techniques for getting them right, and criteria for evaluating them), teamwork, and communication. Specifications are not used as an end in themselves, but are motivated to students as a means to solving realistic problems that involve understanding system behavior. Students enjoy the activity, and it improves their ability to read and write specifications. The two-hour, low-prep activity is self-contained, scales from classes of ten to hundreds of students, and is freely available to other instructors.

Current shared-memory multiprocessors are inherently vulnerable to faults: any significant hardware or system software fault causes the entire system to fail. Unless provisions are made to limit the impact of faults, users will perceive a decrease in reliability when they entrust their applications to larger machines. This paper shows that fault containment techniques can be effectively applied to scalable shared-memory multiprocessors to reduce the reliability problems created by increased machine size.The primary goal of our approach is to leave normal-mode performance unaffected. Rather than using expensive fault-tolerance techniques to mask the effects of data and resource loss, our strategy is based on limiting the damage caused by faults to only a portion of the machine. After a hardware fault, we run a distributed recovery algorithm that allows normal operation to be resumed in the functioning parts of the machine.Our approach is implemented in the Stanford FLASH multiprocessor. Using a detailed hardware simulator, we have performed a number of fault injection experiments on a FLASH system running Hive, an operating system designed to support fault containment. The results we report validate our approach and show that in conjunction with an operating system like Hive, we can improve the reliability seen by unmodified applications without substantial performance cost. Simulation results suggest that our algorithms scale well for systems up to 128 processors.

Reliabilityand scalability are major concerns when designing operating systems for large-scale shared-memory multiprocessors.In this paper we describe Hive, an operating system with a novel kernel architecture that addresses these issues Hive is structured as an internal distributed system of independent kernels called cells.This improves reliabihty because a hardwme or software fault damages only one cell rather than the whole system, and improves scalability because few kernel resources are shared by processes running on different cells.The Hive prototype is a complete implementation of UNIX SVR4 and is targeted to run on the Stanford FLASH multiprocessor.This paper focuses on Hive's solutlon to the following key challenges: ( 1) fault containment, i.e. confining the effects of hardware or software faults to the cell where they occur, and (2) memory sharing among cells, which is requmed to achieve

The FLASH multiprocessor efficiently integrates support for cache-coherent shared memory and high-performance message passing, while minimizing both hardware and software overhead. Each node in FLASH contains a microprocessor, a portion of the machine's global memory, a port to the interconnection network, The MAGIC chip handles all communication both within the node and among nodes, using hardwired data paths for efficient data movement and a programmable processor optimized for executing protocol operations. The use of the protocol processor makes FLASH very flexible/spl minus/it can support a variety of different communication mechanisms/spl minus/and simplifies the design and implementation. This paper presents the architecture of FLASH and MAGIC, and discusses the base cache-coherence and message-passing protocols. Latency and occupancy numbers, which are derived from our system-level simulator and our Verilog code, are given for several common protocol operations. The paper also describes our software strategy and FLASH's current status.>