scispace - formally typeset
Search or ask a question

Showing papers on "Testbed published in 1982"



Journal ArticleDOI
TL;DR: Experimental results, how well various algorithm structures exploit the potential parallelism of the Cm* hardware and software, and the results of extended measurements on the hardware itself are described.
Abstract: Interest in multiprocessor architecture has grown steadily over the past ten to fifteen years. With VLSI technology we can build multiprocessors that are substantially larger than present computers to solve problems that cannot be solved today. Yet despite the substantial number of multiprocessor designs, only a few multiprocessors have been built with a high degree of parallelism, say thirty or more processors. Although multiprocessors appear to have cost/performance and reliability benefits, the computing community has relatively little experience in their actual use. Consequently, little is known about how well the potential of multiprocessors can be realized, which is exactly the thrust of the Cm* research project. We can view a distributed system as being composed of an architectural component and a behavioral component. The first component consists of hardware, firmware, and software elements, and the relationships between them. The behavioral component is characterized by the way the architecture acts in the presence of a workload. The architectural component should be flexible, and the behavioral component should provide a controllable and measurable behavior. These two characteristics are embodied in the Cm* testbed, which has a programmable interconnection network for hardware-architecture flexibility. The two operating systems StarOS and Medusa provide adaptable mechanisms and policies for running experiments with application programs. The workload, the measurement tools, and the experimentation control are integrated into an experimentation environment, which complements the other support programs such as compilers and loaders with facilities for specifying, monitoring, and analyzing experiments. TheCm * project has successfully constructed a 50-processor multiprocessor and two operating systems, thus demonstrating the feasibility of several aspects of multiprocessing. In this article we describe not only Cm* hardware and software but also experimental results, how well various algorithm structures exploit the potential parallelism of the Cm*, and the results of extended measurements on the hardware itself.

44 citations


Journal ArticleDOI
TL;DR: A flexible distributed testbed is described that is being developed to support the development, analysis, test, evaluation, and validation of research in distributed computing for real-time applications and provides the resources for experimentally obtaining quantitative results.
Abstract: The complexity and sophistication of the real-time data processing problems encountered in computerbased weapon systems severely tax all aspects ofadvanced data processing technology. Typically, these systems impose requirements in reliability, availability, cost, performance, and growth that stress today's data processing technology.I Furthermore, data processing solutions are required for a wide range of system concepts and operational environments.2 Although proven conventional techniques such as pipelining and cache memory have significantly improved computer performance and advances in circuit technology have increased processor capacity, current and projected needs still represent significant challenges. In real-time systems such as those for ballistic missile defense, the data processing problem is dominated by the necessity of meeting port-to-port response times while achieving total system throughput requirements. Response times may be as low as a few milliseconds with throughput requirements ranging up to tens ofmillions of instructions per second. Frequently, the data processing system must also remain dormant for months, activate on minutes' notice, and operate unattended with ultrareliability for periods ranging from a few hours to several days. Distributed computing promises to satisfy the requirements of these systems by utilizing moderately priced, contemporary hardware in networks. To achieve this promise, research and development is being pursued in all aspects of real-time distributed computing technology.3'4 Many techniques have been proposed for achieving reliability through redundancy, detecting and recovering from errors, distributing and managing shared data, communicating reliably between processes, allocating and scheduling resources in the presence of failures and overloads, and achieving high throughput through architectural innovation. These techniques must be proven experimentally before they can be used in a real-time system. Individually and collectively they impose overheads that create problems in satisfying real-time requirements. As a result, solutions to the problems of real-time distributed computing must be proven in a realistic environment for the specific real-time application. Two approaches can be considered for the development, evaluation, and demonstration of candidate solutions to the problems of real-time distributed computing. The first uses dedicated hardware and software resources for each application. This approach provides highfidelity results, but the diversity of applications and candidate architectural, hardware, and software solutions makes it prohibitively expensive and time-consuming. The second approach uses a highly flexible testbed that enables rapid, realistic investigation of a variety of candidate solutions for the specific application. This approach, although initially more expensive, is now costeffective because of the availability of (I) low-cost, 16-bit microcomputers that can be used to develop flexible multi-microcomputer systems and (2) well-supported minicomputers that act as centralized coordination facilities for software development, interactive access, and experiment control and monitoring. This article describes a flexible distributed testbed that is being developed to support the development, analysis, test, evaluation, and validation of research in distributed computing for real-time applications. The testbed not only provides the resources for experimentally obtaining quantitative results, but also serves as a focal point for the research, integrating related research activities and providing a mechanism for technology transfer to associated research efforts.

28 citations



Journal ArticleDOI
Brayer1, Lafleur
TL;DR: The Mitre routing system measured the performance of their routing system on the actual nodes, and found that it performed better on the real nodes than in the simulations.
Abstract: ideal simulations can 't predict real performance, but with this method Mitre didn't have to guess. They measured the performance of their routing system on the actual nodes.

19 citations


Journal ArticleDOI
Franta1, Berg, Wood
TL;DR: A distributed system testbed-a vehicle for experimentation-is distinguished from a distributed system by facilities that allow the distributed system topology to be varied and the behavior of the distributedSystem to be readily observed and recorded.
Abstract: Computer system development requires a variety of modeling and analysis techniques. These include queueing networks for mathematical analysis, Petri nets for concurrency descriptions, state transition assertions for program verification, and simulation models for investigations of operational behavior. When theoretical or simulation postulations appear inappropriate, hardwarebased experimental studies are often used. Hardwarebased experiments for computer system development focus on assessing system and component behavior, and experimental investigations require an environment that facilitates the observation of that behavior. Experience gained in the development of experimentation environments for centralized computer systems has been used to establish methodologies and tools for centralized system experimentation. For distributed computer systems, however, there is not yet a rich experience base for developing tools and methodologies to provide an experimental environment. A distributed system testbed-a vehicle for experimentation-is distinguished from a distributed system by facilities that allow the distributed system topology to be varied and the behavior of the distributed system to be readily observed and recorded. This difference gives rise to the logical structure of a distributed system testbed. It generally contains three major components: a multinode experimentation subsystem, an instrumentation subsystem, and a support subsystem. Each node in the multinode experimentation subsystem contains a computer with an autonomous control nucleus, interfaces to the communication network, and input/output facilities. The physically separated experimentation nodes retain processes and resources that are fragments of overall system processing activity. A node does not need access to the (disjoint) memory spaces of other nodes, nor does it need systemwide control authority. Rather, system control functions and state inHelmut K. Berg and William T. Wood Honeywell Corporation

16 citations



01 Jan 1982
TL;DR: This chapter contains sections titled: Intelligent Support Systems for Analysis, The Prototype Testbed, Reasoning in frames systems, Extending the Model, References.
Abstract: This chapter contains sections titled: Intelligent Support Systems for Analysis, The Prototype Testbed, Reasoning in frames systems, Extending the Model, References

4 citations


Proceedings Article
01 Jan 1982
TL;DR: Manage the CS digital logic design and computer networks labs and Advisor for Undergraduate, Ph.D. and Master’s students.
Abstract: • Service: o Member of UAH Faculty Senate (2004-2006) o Member of UAH Undergraduate Curriculum Committee (2004-2006) o Member of UAH Patents and Copyrights committee (2005-2007) o Manage the CS digital logic design and computer networks labs. o Advisor for Undergraduate, Ph.D. and Master’s students o 4 Master’s Thesis students have graduated under my direction. o Chair, Huntsville IEEE CS Chapter (2004-2005), Program Chair (2002-2004)

4 citations


Proceedings ArticleDOI
01 Jan 1982
TL;DR: The MICRONET network computer at SUNY/Stony Brook is being built as a testbed laboratory to experiment with decentralized control techniques, distributed programming languages, and distributed real-time monitoring.
Abstract: Low cost, compactness, and surprising compute power combine to make microprocessor computing elements attractive as building blocks for large parallel computers. Many applications ranging from brain simulation to real-time traffic control can be solved by using inherently parallel techniques executing on loosely-coupled ensembles of microcomputers known as network computers. However, network computer technology is still in its infancy. The main technical problems that remain to be solved relate to software control in distributed operating systems. The MICRONET network computer at SUNY/Stony Brook is being built as a testbed laboratory to experiment with decentralized control techniques, distributed programming languages, and distributed real-time monitoring.

3 citations



01 Jan 1982
TL;DR: The background and current status of the Image Understanding Testbed are described and a brief overview of the major software contributions are given and selected results of the evaluation process are presented.
Abstract: : The background and current status of the Image Understanding Testbed are described. We give a brief overview of the major software contributions and present selected results of the evaluation process. We also discuss the user programs and user interfaces supported in the Testbed environment and present tentative plans for the future evolution of the Testbed. (Author)

01 Jul 1982
TL;DR: A prop fan testbed aircraft is definitely feasible and necessary for verification of prop fan/prop fan aircraft integrity.
Abstract: The proof of concept, feasibility, and verification of the advanced prop fan and of the integrated advanced prop fan aircraft are established. The use of existing hardware is compatible with having a successfully expedited testbed ready for flight. A prop fan testbed aircraft is definitely feasible and necessary for verification of prop fan/prop fan aircraft integrity. The Allison T701 is most suitable as a propulsor and modification of existing engine and propeller controls are adequate for the testbed. The airframer is considered the logical overall systems integrator of the testbed program.

01 Jul 1982
TL;DR: The establishment of propfan technology readiness was determined and candidate drive systems for propfan application were identified and cost and schedule data for the entire testbed program were generated.
Abstract: The establishment of propfan technology readiness was determined and candidate drive systems for propfan application were identified. Candidate testbed aircraft were investigated for testbed aircraft suitability and four aircraft selected as possible propfan testbed vehicles. An evaluation of the four candidates was performed and the Boeing KC-135A and the Gulfstream American Gulfstream II recommended as the most suitable aircraft for test application. Conceptual designs of the two recommended aircraft were performed and cost and schedule data for the entire testbed program were generated. The program total cost was estimated and a wind tunnel program cost and schedule is generated in support of the testbed program.


Proceedings ArticleDOI
23 Jul 1982
TL;DR: The design requirements and implementation of a testbed for both interactive and automatic computer vision systems is described and includes not only a fully integrated approach to computer vision techniques including statistical pattern recognition and artificial intelligence techniques, but also support to several different user groups with quite different backgrounds.
Abstract: The design requirements and implementation of a testbed for both interactive and automatic computer vision systems is described. The design requirements include not only a fully integrated approach to computer vision techniques including statistical pattern recognition and artificial intelligence techniques, but also support to several different user groups with quite different backgrounds. The implementation has been carried out under UNIX using a variety of languages including C, FORTRAN, and LISP.

ReportDOI
01 Aug 1982
TL;DR: TECCNET (Testbed for Evaluating Command and Control NETworks) is a small, expandable software system created to support C3 system research to highlight the complex interactions between the distributed command and control network elements, the information flow network and the environment within which the systems function.
Abstract: : TECCNET (Testbed for Evaluating Command and Control NETworks) is a small, expandable software system created to support C3 system research. It has been designed: 1) to highlight the complex interactions between the distributed command and control network elements, the information flow network and the environment within which the systems function, and 2) to support the development of an Information Intermediary between the C3 Network and the User. TECCNET is interactive and accommodates three basic user activities: definition of a model to simulated, generation of a scenario, and execution of an experiment. An initial modeling environment has been specified to simulate the management of the network. The algorithm used to demonstrate the system is one proposed by Golestaani as part of his PhD research, which treats flow control and routing together within a unified framework.

Proceedings ArticleDOI
17 Mar 1982
TL;DR: The MITRE Corporation has developed a testbed for the evaluation of graphics human-machine interfaces for communications network control centers, using a MITRE-developed communications network simulator, SCAT/G, to drive the candidate network status displays.
Abstract: As part of a continuing effort in the area of system control of military communications networks, the MITRE Corporation, under the auspices of the Rome Air Development Center, has developed a testbed for the evaluation of graphics human-machine interfaces for communications network control centers. The testbed uses a MITRE-developed communications network simulator, SCAT/G, to drive the candidate network status displays. By duplicating the dynamics of the communications network and its environment, SCAT/G provides a realistic testing ground for the graphics displays.