SEARCH · Search NASA

Results for “non-blocking”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

10 records

All sources NASA NTRS DOE OSTI

NASA NTRS1994

Non-blocking crossbar permutation engine with constant routing latency

The invention is embodied in an N x N crossbar for routing packets from a set of N input ports to a set of N output ports, each packet having a header identifying one of the output ports as its destination, including a plurality of individual links which carry individual packets. Each link has a link input end and a link output end, a plurality of switches. Each of the switches has at least top and bottom switch inputs connected to a corresponding pair of the link output ends and top and bottom switch outputs connected to a corresponding pair of link input ends, whereby each switch is connected to four different links. Each of the switches has an exchange state which routes packets from the top and bottom switch inputs to the bottom and top switch outputs, respectively, and a bypass state which routes packets from the top and bottom switch inputs to the top and bottom switch outputs, respectively. A plurality of individual controller devices governing respective switches for sensing from a header of a packet at each switch input for the identity of the destination output port of the packet and selecting one of the exchange and bypass states in accordance with the identity of the destination output port and with the location of the corresponding switch relative to the destination output port.

Monacos, Steve P.↗

NASA NTRS1992

Tradeoffs in implementing primary-backup protocols

One way to implement a fault-tolerant service is by using multiple servers that fail independently. The state of the service is replicated and distributed among these servers, and updates are coordinated so that even when a subset of the servers fail, the service remains available. A common approach to structuring such replicated services is to designate one server as the primary and all the others as backups. Clients make requests by sending messages only to the primary. If the primary fails, then a failover occurs and one of the backups takes over. This service architecture is commonly called the primary-backup or the primary-copy approach. In most such primary-backup protocols, when the primary receives a client request, it informs the backups about the request, and then responds to the client. Informally, this primary-backup protocol is non-blocking if the primary does not wait for an acknowledgement from the backups before it sends the response; otherwise, it is blocking. Most of the existing protocols are blocking as non-blocking protocols cannot be constructed for some kinds of failures. However, it is shown that non-blocking protocols can be constructed for most of the process and communication failures that are expected to occur in the primary-backup systems of the future. Since non-blocking protocols can theoretically achieve the smallest possible response time, this paper analyzes these protocols under various system parameters. Two kinds of non-blocking protocols are analyzed: one in which the processes use point-to-point communication to exchange messages, and the other in which processes use hardware broadcasts.

Budhiraja, Navin↗

NASA NTRS1992

The Keck keyword layer

Each Keck instrument presents a consistent software view to the user interface programmer. The view consists of a small library of functions, which are identical for all instruments, and a large set of keywords, that vary from instrument to instrument. All knowledge of the underlying task structure is hidden from the application programmer by the keyword layer. Image capture software uses the same function library to collect data for the image header. Because the image capture software and the instrument control software are built on top of the same keyword layer, a given observation can be 'replayed' by extracting keyword-value pairs from the image header and passing them back to the control system. The keyword layer features non-blocking as well as blocking I/O. A non-blocking keyword write operation (such as setting a filter position) specifies a callback to be invoked when the operation is complete. A non-blocking keyword read operation specifies a callback to be invoked whenever the keyword changes state. The keyword-callback style meshes well with the widget-callback style commonly used in X window programs. The first keyword library was built for the two Keck optical instruments. More recently, keyword libraries have been developed for the infrared instruments and for telescope control. Although the underlying mechanisms used for inter-process communication by each of these systems vary widely (Lick MUSIC, Sun RPC, and direct socket I/O, respectively), a basic user interface has been written that can be used with any of these systems. Since the keyword libraries are bound to user interface programs dynamically at run time, only a single set of user interface executables is needed. For example, the same program, 'xshow', can be used to display continuously the telescope's position, the time left in an instrument's exposure, or both values simultaneously. Less generic tools that operate on specific keywords, for example an X display that controls optical instrument exposures, have also been written using the keyword layer.

Conrad, A. R.↗

NASA NTRS1988

An intelligent allocation algorithm for parallel processing

The problem of allocating nodes of a program graph to processors in a parallel processing architecture is considered. The algorithm is based on critical path analysis, some allocation heuristics, and the execution granularity of nodes in a program graph. These factors, and the structure of interprocessor communication network, influence the allocation. To achieve realistic estimations of the executive durations of allocations, the algorithm considers the fact that nodes in a program graph have to communicate through varying numbers of tokens. Coarse and fine granularities have been implemented, with interprocessor token-communication duration, varying from zero up to values comparable to the execution durations of individual nodes. The effect on allocation of communication network structures is demonstrated by performing allocations for crossbar (non-blocking) and star (blocking) networks. The algorithm assumes the availability of as many processors as it needs for the optimal allocation of any program graph. Hence, the focus of allocation has been on varying token-communication durations rather than varying the number of processors. The algorithm always utilizes as many processors as necessary for the optimal allocation of any program graph, depending upon granularity and characteristics of the interprocessor communication network.

Carroll, Chester C.↗

NASA NTRS1997

Scalable Wrap-Around Shuffle Exchange Network with Deflection Routing

The invention in one embodiment is a communication network including plural non-blocking crossbar nodes, first apparatus for connecting the nodes in a first layer of connecting links, and second apparatus for connecting links independent of the first layer, whereby each layer is connected to the other layer at each point of the nodes. Preferably, each one of the layers of connecting links corresponds to one recirculating network topology that closes in on itself.

Monacos, Steve P.↗

NASA NTRS2001

Application of a Scalable, Parallel, Unstructured-Grid-Based Navier-Stokes Solver

A parallel version of an unstructured-grid based Navier-Stokes solver, USM3Dns, previously developed for efficient operation on a variety of parallel computers, has been enhanced to incorporate upgrades made to the serial version. The resultant parallel code has been extensively tested on a variety of problems of aerospace interest and on two sets of parallel computers to understand and document its characteristics. An innovative grid renumbering construct and use of non-blocking communication are shown to produce superlinear computing performance. Preliminary results from parallelization of a recently introduced "porous surface" boundary condition are also presented.

Parikh, Paresh↗

NASA NTRS2004

[PVFS 2000: An operational parallel file system for Beowulf]

The approach has been to develop Parallel Virtual File System version 2 (PVFS2) , retaining the basic philosophy of the original file system but completely rewriting the code. It shows the architecture of the server and client components. BMI - BMI is the network abstraction layer. It is designed with a common driver and modules for each protocol supported. The interface is non-blocking, and provides mechanisms for optimizations including pinning user buffers. Currently TCP/IP and GM(Myrinet) modules have been implemented. Trove -Trove is the storage abstraction layer. It provides for storing both data spaces and name/value pairs. Trove can also be implemented using different underlying storage mechanisms including native files, raw disk partitions, SQL and other databases. The current implementation uses native files for data spaces and Berkeley db for name/value pairs.

Ligon, Walt↗

NASA NTRS1994

A Permutation Engine Switching Node

We describe an asynchronous, strictly non-blocking crossbar node topology and distributed routing algorithm that is particularly suited to optoelectronic implementation.

Permutation engine permutation node topology routi↗

NASA NTRS2014

Launch Lock Assemblies Including Axial Gap Amplification Devices and Spacecraft Isolation Systems Including the Same

Embodiments of a launch lock assembly are provided, as are embodiments of a spacecraft isolation system including one or more launch lock assemblies. In one embodiment, the launch lock assembly includes first and second mount pieces, a releasable clamp device, and an axial gap amplification device. The releasable clamp device normally maintains the first and second mount pieces in clamped engagement; and, when actuated, releases the first and second mount pieces from clamped engagement to allow relative axial motion there between. The axial gap amplification device normally residing in a blocking position wherein the gap amplification device obstructs relative axial motion between the first and second mount pieces. The axial gap amplification device moves into a non-blocking position when the first and second mount pieces are released from clamped engagement to increase the range of axial motion between the first and second mount pieces.

Barber, Tim Daniel↗

NASA NTRS2024

Exploring New Frontiers in Space Communications: Enhancing Delay Tolerant Networking through Cloud and Containerization

The High-rate Delay Tolerant Networking (HDTN) project at NASA Glenn Research Center has developed software that enables more flexible, reliable, and efficient space internetworking by using modern computing techniques such as cloud services, microservices, network function virtualization, software defined networking, and a distributed architecture. HDTN is built upon the Bundle Protocol and related convergence layers which have been developed to mitigate the challenges of the space networking environment including long delays, asymmetric data rates, and intermittent connectivity. The HDTN implementation employs asynchronous message processing tasks which allow for non-blocking operations as well as deployment in both centralized and distributed architectures. This paper investigates deploying HDTN in a containerized approach on the NASA Goddard’s Mission Cloud Platform using Amazon Web Services Elastic Compute Cloud (EC2). Commercial cloud computing will lower operating costs, provide flexible resource allocation, and allow for interconnectivity between multiple NASA centers as well as external partners. Containerization using Docker will enable greater portability and scalability for HDTN to be deployed into a variety of environments. We discuss possible NASA missions and use-cases such as the Laser Communications Relay Demonstration (LCRD) where the services provided by HDTN (reliable transport, high-rate message processing, and store-and-forward capabilities) will be enhanced through cloud computing and containerization. In addition, we describe the HDTN architecture and possible microservice-based networking approaches that can be obtained via HDTN’s configuration capabilities. Finally, we detail the EC2 specifications needed to achieve data rates greater than 1 Gbps to support optical communication missions such as LCRD.

Blake LaFuente↗