SEARCH · Engineering Papers
Results for “Ethernet”
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.
Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.
A Proposed Byzantine Fault-Tolerant Voting Architecture Using Time-Triggered Ethernet
No abstract available
Diolkos: Improving ethernet throughput through dynamic port selection
In large networked systems, a sudden increase in traffic could slowdown the network significantly, impacting network quality for multiple users. We present Diolkos, a system that leverages smart switches to dynamically re-reroute data flows in response to drops in performance. In contrast to other techniques, our tool predicts the future throughput at each port in a switch if a data flow were to be sent through it, and updates which port should be taken to maximize throughput. We use several techniques to predict network switch performance on a software defined network (SDN) mimicking topologies commonly found in datacenters. Experimentally, we demonstrate the effectiveness of choosing a port to send flows through based on predicted performance. We found that using a distributed predictive technique achieves a 24% improvement over using a traditional heuristic technique.
An Evaluation of Ethernet Performance for Scientific Workloads.
Abstract not provided.
TTEthernet for Integrated Spacecraft Networks
Aerospace projects have traditionally employed federated avionics architectures, in which each computer system is designed to perform one specific function (e.g. navigation). There are obvious downsides to this approach, including excessive weight (from so much computing hardware), and inefficient processor utilization (since modern processors are capable of performing multiple tasks). There has therefore been a push for integrated modular avionics (IMA), in which common computing platforms can be leveraged for different purposes. This consolidation of multiple vehicle functions to shared computing platforms can significantly reduce spacecraft cost, weight, and design complexity. However, the application of IMA principles introduces significant challenges, as the data network must accommodate traffic of mixed criticality and performance levels - potentially all related to the same shared computer hardware. Because individual network technologies are rarely so competent, the development of truly integrated network architectures often proves unreasonable. Several different types of networks are utilized - each suited to support a specific vehicle function. Critical functions are typically driven by precise timing loops, requiring networks with strict guarantees regarding message latency (i.e. determinism) and fault-tolerance. Alternatively, non-critical systems generally employ data networks prioritizing flexibility and high performance over reliable operation. Switched Ethernet has seen widespread success filling this role in terrestrial applications. Its high speed, flexibility, and the availability of inexpensive commercial off-the-shelf (COTS) components make it desirable for inclusion in spacecraft platforms. Basic Ethernet configurations have been incorporated into several preexisting aerospace projects, including both the Space Shuttle and International Space Station (ISS). However, classical switched Ethernet cannot provide the high level of network determinism required by real-time spacecraft applications. Even with modern advancements, the uncoordinated (i.e. event-driven) nature of Ethernet communication unavoidably leads to message contention within network switches. The arbitration process used to resolve such conflicts introduces variation in the time it takes for messages to be forwarded. TTEthernet1 introduces decentralized clock synchronization to switched Ethernet, enabling message transmission according to a time-triggered (TT) paradigm. A network planning tool is used to allocate each device a finite amount of time in which it may transmit a frame. Each time slot is repeated sequentially to form a periodic communication schedule that is then loaded onto each TTEthernet device (e.g. switches and end systems). Each network participant references the synchronized time in order to dispatch messages at predetermined instances. This schedule guarantees that no contention exists between time-triggered Ethernet frames in the network switches, therefore eliminating the need for arbitration (and the timing variation it causes). Besides time-triggered messaging, TTEthernet networks may provide two additional traffic classes to support communication of different criticality levels. In the rate-constrained (RC) traffic class, the frame payload size and rate of transmission along each communication channel are limited to predetermined maximums. The network switches can therefore be configured to accommodate the known worst-case traffic pattern, and buffer overflows can be eliminated. The best-effort (BE) traffic class behaves akin to classical Ethernet. No guarantees are provided regarding transmission latency or successful message delivery. TTEthernet coordinates transmission of all three traffic classes over the same physical connections, therefore accommodating the full spectrum of traffic criticality levels required in IMA architectures. Common computing platforms (e.g. LRUs) can share networking resources in such a way that failures in non-critical systems (using BE or RC communication modes) cannot impact flight-critical functions (using TT communication). Furthermore, TTEthernet hardware (e.g. switches, cabling) can be shared by both TTEthernet and classical Ethernet traffic.
Modernization of PLC-Based Control Systems at SNS
When the SNS site was built around 20 years ago, the Conventional Facilities (CF) control systems were de-signed using 2 communication protocols to allow pro-grammable logic controllers (PLCs) to interface with motors, variable frequency drives (VFDs), and remote input and output (I/O) devices. The protocol chosen to control motors and VFDs is DeviceNet, a CANbus-based protocol developed by Allen-Bradley, a subsidiary of Rockwell Automation. The protocol chosen to communi-cate with remote I/O is ControlNet, another protocol developed by Allen-Bradley. Both of these protocols are obsolete and present reliability and maintainability is-sues, particularly DeviceNet. As the Control Systems Section at SNS is working to modernize control systems throughout the machine, a major goal for PLC-based systems is to remove the obsolete communication proto-cols in favor of standard, ubiquitous Ethernet. To this end, any new VFDs installed use Ethernet communica-tion. Many VFDs are currently being replaced in the Central Utilities Building (CUB) and the Central Exhaust Facility (CEF) and are being removed from DeviceNet in favor of Ethernet communication. Planning is underway to retrofit Eaton Intelligent Technology motor control centers (MCCs) in the Target Building to remove particu-larly troublesome DeviceNet adaptors and replace them with Ethernet adaptors for each motor starter. The Con-trolNet network in the CUB has been demolished, with I/O drops integrated into a local Ethernet network, im-proving sustainability and maintainability.
Spacelab system analysis: The modified free access protocol: An access protocol for communication systems with periodic and Poisson traffic
The protocol definition and terminal hardware for the modified free access protocol, a communications protocol similar to Ethernet, are developed. A MFA protocol simulator and a CSMA/CD math model are also developed. The protocol is tailored to communication systems where the total traffic may be divided into scheduled traffic and Poisson traffic. The scheduled traffic should occur on a periodic basis but may occur after a given event such as a request for data from a large number of stations. The Poisson traffic will include alarms and other random traffic. The purpose of the protocol is to guarantee that scheduled packets will be delivered without collision. This is required in many control and data collection systems. The protocol uses standard Ethernet hardware and software requiring minimum modifications to an existing system. The modification to the protocol only affects the Ethernet transmission privileges and does not effect the Ethernet receiver.
Switch configuration for migration to optical fiber network
The purpose is to investigate the migration of an Ethernet LAN segment to fiber optics. At the present time it is proposed to support a Fiber Distributed Data Interface (FDDI) backbone and to upgrade the VAX cluster to fiber optic interface. Possibly some workstations will have an FDDI interface. The remaining stations on the Ethernet LAN will be segmented. The rationale for migrating from the present Ethernet configuration to a fiber optic backbone is due to the increase in the number of workstations and the movement of applications to a windowing environment, extensive document transfers, and compute intensive applications.
Space Network Devices Developed
The NASA Glenn Research Center through a contract with Spectrum Astro, Inc., has been developing space network hardware as an enabling technology using open systems interconnect (OSI) standards for space-based communications applications. The OSI standard is a well-recognized layered reference model that specifies how data should be sent node to node in a communications network. Because of this research and technology development, a space-qualifiable Ethernet-based network interface card (similar to the type found in a networked personal computer) and the associated four-port hub were designed and developed to flight specifications. During this research and development, there also have been many lessons learned for determining approaches for migrating existing spacecraft architectures to an OSI-network-based platform. Industry has recognized the benefits of targeting hardware developed around OSI standards such as Transmission Control Protocol/Internet Protocol (TCP/IP) or similar protocols for use in future generations of space communication systems. Some of these tangible benefits include overall reductions in mission schedule and cost and in system complexity. This development also brings us a step closer to the realization of a principal investigator on a terrestrial Internet site being able to interact with space platform assets in near real time. To develop this hardware, Spectrum Astro first conducted a technology analysis of alternatives study. For this analysis, they looked at the features of three protocol specifications: Ethernet (IEEE 802.3), Firewire (IEEE 1394), and Spacewire (IEEE 1355). A thorough analysis was performed on the basis of criteria such as current protocol performance and suitability for future space applications. Spectrum Astro also projected future influences such as cost, hardware and software availability, throughput performance, and integration procedures for current and transitive space architectures. After a thorough analysis, Ethernet was chosen because it was seen as the best longer term fit because of the prevalent commercial market; the current and projected availability of hardware, software, and development tools; and the ease of architecture integration.
FPGA-Based Networked Phasemeter for a Heterodyne Interferometer
A document discusses a component of a laser metrology system designed to measure displacements along the line of sight with precision on the order of a tenth the diameter of an atom. This component, the phasemeter, measures the relative phase of two electrical signals and transfers that information to a computer. Because the metrology system measures the differences between two optical paths, the phasemeter has two inputs, called measure and reference. The reference signal is nominally a perfect square wave with a 50- percent duty cycle (though only rising edges are used). As the metrology system detects motion, the difference between the reference and measure signal phases is proportional to the displacement of the motion. The phasemeter, therefore, counts the elapsed time between rising edges in the two signals, and converts the time into an estimate of phase delay. The hardware consists of a circuit board that plugs into a COTS (commercial, off-the- shelf) Spartan-III FPGA (field-programmable gate array) evaluation board. It has two BNC inputs, (reference and measure), a CMOS logic chip to buffer the inputs, and an Ethernet jack for transmitting reduced-data to a PC. Two extra BNC connectors can be attached for future expandability, such as external synchronization. Each phasemeter handles one metrology channel. A bank of six phasemeters (and two zero-crossing detector cards) with an Ethernet switch can monitor the rigid body motion of an object. This device is smaller and cheaper than existing zero-crossing phasemeters. Also, because it uses Ethernet for communication with a computer, instead of a VME bridge, it is much easier to use. The phasemeter is a key part of the Precision Deployable Apertures and Structures strategic R&D effort to design large, deployable, segmented space telescopes.
Remotely Accessible Testbed for Software Defined Radio Development
Previous development testbeds have assumed that the developer was physically present in front of the hardware being used. No provision for remote operation of basic functions (power on/off or reset) was made, because the developer/operator was sitting in front of the hardware, and could just push the button manually. In this innovation, a completely remotely accessible testbed has been created, with all diagnostic equipment and tools set up for remote access, and using standardized interfaces so that failed equipment can be quickly replaced. In this testbed, over 95% of the operating hours were used for testing without the developer being physically present. The testbed includes a pair of personal computers, one running Linux and one running Windows. A variety of peripherals is connected via Ethernet and USB (universal serial bus) interfaces. A private internal Ethernet is used to connect to test instruments and other devices, so that the sole connection to the outside world is via the two PCs. An important design consideration was that all of the instruments and interfaces used stable, long-lived industry standards, such as Ethernet, USB, and GPIB (general purpose interface bus). There are no plug-in cards for the two PCs, so there are no problems with finding replacement computers with matching interfaces, device drivers, and installation. The only thing unique to the two PCs is the locally developed software, which is not specific to computer or operating system version. If a device (including one of the computers) were to fail or become unavailable (e.g., a test instrument needed to be recalibrated), replacing it is a straightforward process with a standard, off-the-shelf device.
On TTEthernet for Integrated Fault-Tolerant Spacecraft Networks
There has recently been a push for adopting integrated modular avionics (IMA) principles in designing spacecraft architectures. This consolidation of multiple vehicle functions to shared computing platforms can significantly reduce spacecraft cost, weight, and de- sign complexity. Ethernet technology is attractive for inclusion in more integrated avionic systems due to its high speed, flexibility, and the availability of inexpensive commercial off-the-shelf (COTS) components. Furthermore, Ethernet can be augmented with a variety of quality of service (QoS) enhancements that enable its use for transmitting critical data. TTEthernet introduces a decentralized clock synchronization paradigm enabling the use of time-triggered Ethernet messaging appropriate for hard real-time applications. TTEthernet can also provide two forms of event-driven communication, therefore accommodating the full spectrum of traffic criticality levels required in IMA architectures. This paper explores the application of TTEthernet technology to future IMA spacecraft architectures as part of the Avionics and Software (A&S) project chartered by NASA's Advanced Exploration Systems (AES) program.
Energy–Performance Trade-offs in Privacy-Preserving Federated Learning on SmartNIC-Enabled HPC Systems
Federated learning (FL) is increasingly deployed on accelerator-rich high-performance computing (HPC) systems, yet the system-level energy cost of privacy-aware FL remains poorly understood, particularly across heterogeneous networking and server-placement options. We present a measurement-driven study of energy–performance trade-offs for FL on GH200-class nodes across three deployment configurations: CPU-Ethernet, CPU-InfiniBand (RDMA-capable), and a DPU-hosted FL server over InfiniBand using a BlueField-3 SmartNIC/DPU. Using NVIDIA FLARE (NVFLARE), we align node-level power telemetry with per-round timing extracted from NVFLARE logs to quantify time-to-solution (TTS), energy-to-solution (ETS), energy-delay product (EDP), and synchronization behavior for three transformer models (ALBERT, DistilBERT, BERT), trained with and without differential privacy (DP). We find that interconnect choice is the dominant driver of runtime and energy: host-managed InfiniBand consistently reduces communication overhead versus Ethernet, yielding lower TTS/ETS/EDP. In contrast, in our NVFLARE deployment, placing the FL server on the DPU does not consistently match CPU-InfiniBand performance and can be slower—especially for larger models—highlighting that server placement alone is not sufficient to guarantee end-to-end gains. Finally, under our fixed-round protocol, DP increases per-round cost and runtime variance; ETS increases largely in proportion to TTS because average node power remains relatively stable across configurations.
White Rabbit Time Synchronization for Radiation Detector Readout Electronics
As radiation detector arrays in nuclear physics applications become larger and physically more separated, the time synchronization and trigger distribution between many channels of detector readout electronics become more challenging. Clocks and triggers are traditionally distributed through dedicated cabling, but newer methods such as the IEEE 1588 Precision Time Protocol and White Rabbit allow clock synchronization through the exchange of timing messages over Ethernet. Consequently, we report here the use of White Rabbit in a new detector readout module, the Pixie-Net XL. Herein, the White Rabbit core, data capture from multiple digitizing channels, and subsequent pulse processing for pulse height and constant fraction timing are implemented in a Kintex 7 FPGA. The detector data records include White Rabbit time stamps and are transmitted to storage through the White Rabbit core's gigabit Ethernet data path or a slower diagnostic/control link using an embedded Zynq processor. The performance is characterized by time-of-flight style measurements and by time correlation of high energy background events from cosmic showers in detectors separated by longer distances. Software for the Zynq processor can implement "software triggering", for example to limit recording of data to events where a minimum number of channels from multiple modules detect radiation at the same time.
Opportunistic Hybrid Communications Systems for Distributed PV Coordination
A full-scale, operational implementation of the opportunistic hybrid communications systems for distributed photovoltaic (PV) coordination was successfully developed, simulated, and validated in this 3-year project. The system is considered hybrid because it uses different communications pathways from the scale of residential PV inverters to a transmission network; primary technologies harnessed include Low-Power Wireless Personal Area Network (LoWPAN), Power Line Communication (PLC), WiFi mesh, Worldwide Interoperability for Microwave Access (WiMAX), Ethernet cable, and Optical Ethernet systems. It is opportunistic in that it chooses to route messages through each of these systems based on recent data about latency and availability to ensure reliable message passing.
Spectra Swarm Evaluation
Spectra Swarm product is an ethernet to Serial-attached-SCSI(SAS) bridge that allows a hostserver to communicate with SAS tape drives over ethernet using RDMA over ConvergedEthernet (RoCE).
DAQs Quick Start Guide
DAQs is a Windows® computer app designed to communicate with the Advanced List Mode Module (ALMM), MC-15, and instrumentation based off these platforms. The ALMM communicates with DAQS over the Ethernet using TCP/IP. If you register the IPv4 address of the ALMM on the local network the ALMM can be operated remotely. However, if the ALMM is not connected to the local network then the computer running DAQs will need to be connected directly to the ALMM or an additional Ethernet adapter will need to be installed on the acquisition computer. The IPv4 address can be changed in the rei.ini file located on the µSD card. Please see the appendices for more information on the rei.ini file. This document is intended to be a quick start guide on how to get an ALMM connected to a computer and how to start a data acquisition. DAQs has much more capability than is presented in this document.