Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “SERVER”

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.

At least 217 records · Page 12

Providing Internet Access to High-Resolution Mars Images

The OnMars server is a computer program that provides Internet access to high-resolution Mars images, maps, and elevation data, all suitable for use in geographical information system (GIS) software for generating images, maps, and computational models of Mars. The OnMars server is an implementation of the Open Geospatial Consortium (OGC) Web Map Service (WMS) server. Unlike other Mars Internet map servers that provide Martian data using an Earth coordinate system, the OnMars WMS server supports encoding of data in Mars-specific coordinate systems. The OnMars server offers access to most of the available high-resolution Martian image and elevation data, including an 8-meter-per-pixel uncontrolled mosaic of most of the Mars Global Surveyor (MGS) Mars Observer Camera Narrow Angle (MOCNA) image collection, which is not available elsewhere. This server can generate image and map files in the tagged image file format (TIFF), Joint Photographic Experts Group (JPEG), 8- or 16-bit Portable Network Graphics (PNG), or Keyhole Markup Language (KML) format. Image control is provided by use of the OGC Style Layer Descriptor (SLD) protocol. The OnMars server also implements tiled WMS protocol and super-overlay KML for high-performance client application programs.

Plesea, Lucian↗

CIVET: Continuous Integration, Verification, Enhancement, and Testing

A Git server (GitHub, GitLab, BitBucket) sends event notifications to the Civet server. These are either a " Pull Request" or a "Push" notification. Civet then checks the database to determine what tests need to be run and marks them as ready to run. Civet clients, running on dedicated machines, query the server for available jobs that are ready to run. When a client gets a job it executes the scripts attached to the job and report back to the server the output and exit status. When the client updates the server, the server will also update the Git server with the result of the job, as well as updating the main web page.

Alger, Brian↗

Zebra: A striped network file system

The design of Zebra, a striped network file system, is presented. Zebra applies ideas from log-structured file system (LFS) and RAID research to network file systems, resulting in a network file system that has scalable performance, uses its servers efficiently even when its applications are using small files, and provides high availability. Zebra stripes file data across multiple servers, so that the file transfer rate is not limited by the performance of a single server. High availability is achieved by maintaining parity information for the file system. If a server fails its contents can be reconstructed using the contents of the remaining servers and the parity information. Zebra differs from existing striped file systems in the way it stripes file data: Zebra does not stripe on a per-file basis; instead it stripes the stream of bytes written by each client. Clients write to the servers in units called stripe fragments, which are analogous to segments in an LFS. Stripe fragments contain file blocks that were written recently, without regard to which file they belong. This method of striping has numerous advantages over per-file striping, including increased server efficiency, efficient parity computation, and elimination of parity update.

Hartman, John H.↗

Process evaluation distributed system

The distributed system includes a database server, an administration module, a process evaluation module, and a data display module. The administration module is in communication with the database server for providing observation criteria information to the database server. The process evaluation module is in communication with the database server for obtaining the observation criteria information from the database server and collecting process data based on the observation criteria information. The process evaluation module utilizes a personal digital assistant (PDA). A data display module in communication with the database server, including a website for viewing collected process data in a desired metrics form, the data display module also for providing desired editing and modification of the collected process data. The connectivity established by the database server to the administration module, the process evaluation module, and the data display module, minimizes the requirement for manual input of the collected process data.

Moffatt, Christopher L.↗

End-to-End Performance Management for Large Distributed Storage

Storage systems for large distributed clusters of computer servers are themselves large and distributed. Their complexity and scale make it hard to ensure that applications using them get good, predictable performance. At the same time, shared access to the system from multiple applications, users, and internal system activities leads to a need for predictable performance. This research investigates mechanisms for improving storage system performance in large distributed storage systems through mechanisms that integrate the performance aspects of the path that I/O operations take through the system, from the application interface on the compute server, through the network, to the storage servers. The research focuses on five parts of the I/O path in a distributed storage system: I/O scheduling at the storage server, storage server cache management, client-to-server network flow control, client-to-server connection management, and client cache management.

42 ENGINEERING↗

CIVET: Continuous Integration, Verification, Enhancement, and Testing

A Git server (GitHub, GitLab, BitBucket) sends event notifications to the Civet server. These are either a " Pull Request" or a "Push" notification. Civet then checks the database to determine what tests need to be run and marks them as ready to run. Civet clients, running on dedicated machines, query the server for available jobs that are ready to run. When a client gets a job it executes the scripts attached to the job and report back to the server the output and exit status. When the client updates the server, the server will also update the Git server with the result of the job, as well as updating the main web page.

Alger, Brian↗

The water use of data center workloads: A review and assessment of key determinants

The global importance of data center water use is increasing with the rapid growth of digitalization and artificial intelligence. This study analyzes the factors influencing workload-level water use, measured in liters consumed per workload, to guide water-saving strategies in data centers. Our findings reveal workload-level water use variations exceeding 10,000-fold, driven by over 1000-fold differences in water consumption per kilowatt hour of server electricity consumed and approximately 10-fold differences in server workload efficiency. Key determinants are ranked as server efficiency, electrical grid water consumption factors, server utilization, cooling system type, infrastructure efficiency, climate zone, inactive server percentage, and server refresh cycle. Notably, there is no single recipe for minimizing water use; instead, optimal outcomes depend on tailored combinations of these factors. This analysis addresses critical knowledge gaps by identifying the determinants of data center water use and exploring their achievable minima under diverse site-specific constraints.

Data centers↗

Threshold-based queuing system for performance analysis of cloud computing system with dynamic scaling

Cloud computing is promising technology to manage and improve utilization of computing center resources to deliver various computing and IT services. For the purpose of energy saving there is no need to unnecessarily operate many servers under light loads, and they are switched off. On the other hand, some servers should be switched on in heavy load cases to prevent very long delays. Thus, waiting times and system operating cost can be maintained on acceptable level by dynamically adding or removing servers. One more fact that should be taken into account is significant server setup costs and activation times. For better energy efficiency, cloud computing system should not react on instantaneous increase or instantaneous decrease of load. That is the main motivation for using queuing systems with hysteresis for cloud computing system modelling. In the paper, we provide a model of cloud computing system in terms of multiple server threshold-based infinite capacity queuing system with hysteresis and noninstantanuous server activation. For proposed model, we develop a method for computing steady-state probabilities that allow to estimate a number of performance measures.

71 CLASSICAL AND QUANTUM MECHANICS, GENERAL PHYSIC↗

The PhEDEx next-gen website

PhEDEx is the data-transfer management solution written by CMS. It consists of agents running at each site, a website for presentation of information, and a web-based data-service for scripted access to information. The website allows users to monitor the progress of data-transfers, the status of site agents and links between sites, and the overall status and behaviour of everything about PhEDEx. It also allows users to make and approve requests for data-transfers and for deletion of data. It is the main point-of-entry for all users wishing to interact with PhEDEx. For several years, the website has consisted of a single perl program with about 10K SLOC. This program has limited capabilities for exploring the data, with only coarse filtering capabilities and no context-sensitive awareness. Graphical information is presented as static images, generated on the server, with no interactivity. It is also not well connected to the rest of the PhEDEx codebase, since much of it was written before the data-service was developed. All this makes it hard to maintain and extend. We are re-implementing the website to address these issues. The UI is being rewritten in Javascript, replacing most of the server-side code. We are using the YUI toolkit to provide advanced features and context-sensitive interaction, and will adopt a Javascript charting library for generating graphical representations client-side. This relieves the server of much of its load, and automatically improves server-side security. The Javascript components can be re-used in many ways, allowing custom pages to be developed for specific uses. In particular, standalone test-cases using small numbers of components make it easier to debug the Javascript than it is to debug a large server program. Information about PhEDEx is accessed through the PhEDEx data-service, since direct SQL is not available from the clients browser. This provides consistent semantics with other, externally written monitoring tools, which already use the data-service. It also reduces redundancy in the code, yielding a simpler, consolidated codebase. In this talk we describe our experience of re-factoring this monolithic server-side program into a lighter client-side framework. We describe some of the techniques that worked well for us, and some of the mistakes we made along the way. We present the current state of the project, and its future direction.

Egeland, R.↗

ModBase, a database of annotated comparative protein structure models and associated resources

ModBase (http://salilab.org/modbase) is a database of annotated comparative protein structure models. The models are calculated by ModPipe, an automated modeling pipeline that relies primarily on Modeller for fold assignment, sequence-structure alignment, model building and model assessment (http://salilab.org/modeller/). ModBase currently contains almost 30 million reliable models for domains in 4.7 million unique protein sequences. ModBase allows users to compute or update comparative models on demand, through an interface to the ModWeb modeling server (http://salilab.org/ modweb). ModBase models are also available through the Protein Model Portal (http://www.prote inmodelportal.org/). Recently developed associated resources include the AllosMod server for modeling ligand-induced protein dynamics (http://salilab.org/ allosmod), the AllosMod-FoXS server for predicting a structural ensemble that fits an SAXS profile (http://salilab.org/allosmod-foxs), the FoXSDock server for protein–protein docking filtered by an SAXS profile (http://salilab.org/foxsdock), the SAXS Merge server for automatic merging of SAXS profiles (http://salilab.org/saxsmerge) and the Pose & Rank server for scoring protein–ligand complexes (http://salilab.org/poseandrank). In this update, we also highlight two applications of ModBase: a PSI:Biology initiative to maximize the structural coverage of the human alpha-helical transmembrane proteome and a determination of structural determinants of human immunodeficiency virus-1 protease specificity.

59 BASIC BIOLOGICAL SCIENCES↗

Situational Awareness of Network System Roles (SANSR)

In a large enterprise it is difficult for cyber security analysts to know what services and roles every machine on the network is performing (e.g. file server, domain name server, email server). Understanding the roles of the systems in the network provides analysts with a situational awareness that will allow them to detect consequential changes in the network, initiate an incident response plan, and optimize their security posture. Using the network flow data, already collected by most enterprises, we developed a tool that enables analysts to automatically detect/classify services and roles of every machine that’s operating on a network (e.g. file server, domain name server, email server) for better situational awareness of potential threats to the network. his tool queries Elasticsearch for network flow data, creates a temporal behavior model of each system, uses unsupervised machine learning to cluster the models with a set of labeled temporal behavior models, and the resulting information can be printed to the console or programmatically accessed. The results include the likelihood that a machine has a labeled role and lists other machines that are most similar in behavior.

Huffer, KellyM.↗

Choreographer Pre-Testing Code Analysis and Operational Testing.

Choreographer is a "moving target defense system", designed to protect against attacks aimed at IP addresses without corresponding domain name system (DNS) lookups. It coordinates actions between a DNS server and a Network Address Translation (NAT) device to regularly change which publicly available IP addresses' traffic will be routed to the protected device versus routed to a honeypot. More details about how Choreographer operates can be found in Section 2: Introducing Choreographer. Operational considerations for the successful deployment of Choreographer can be found in Section 3. The Testing & Evaluation (T&E) for Choreographer involved 3 phases: Pre-testing, Code Analysis, and Operational Testing. Pre-testing, described in Section 4, involved installing and configuring an instance of Choreographer and verifying it would operate as expected for a simple use case. Our findings were that it was simple and straightforward to prepare a system for a Choreographer installation as well as configure Choreographer to work in a representative environment. Code Analysis, described in Section 5, consisted of running a static code analyzer (HP Fortify) and conducting dynamic analysis tests using the Valgrind instrumentation framework. Choreographer performed well, such that only a few errors that might possibly be problematic in a given operating situation were identified. Operational Testing, described in Section 6, involved operating Choreographer in a representative environment created through Emulytics TM . Depending upon the amount of server resources dedicated to Choreographer vis-á-vis the amount of client traffic handled, Choreographer had varying degrees of operational success. In an environment with a poorly resourced Choreographer server and as few as 50-100 clients, Choreographer failed to properly route traffic over half the time. Yet, with a well-resourced server, Choreographer handled over 1000 clients without missrouting. Choreographer demonstrated sensitivity to low-latency connections as well as high volumes of traffic. In addition, depending upon the frequency of new connection requests and the size of the address range that Choreographer has to work with, it is possible for all benefits of Choreographer to be ameliorated by its need to allow DNS servers rather than the end client to make DNS requests. Conclusions and Recommendations, listed in Section 7, address the need to understand the specific use case where Choreographer would be deployed to assess whether there would be problems resulting from the operational considerations described in Section 3 or performance concerns from the results of Operational Testing in Section 6. Deployed in an appropriate architecture with sufficiently light traffic volumes and a well-provisioned server, it is quite likely that Choreographer would perform satisfactorily. Thus, we recommend further detailed testing, to potentially include Red Team testing, at such time a specific use case is identified

97 MATHEMATICS AND COMPUTING↗

Reproduction of the Yucca Mountain Project TSPA-LA Model Runs using TSPA Computing Systems

Sandia National Laboratories (SNL) conducted an evaluation of total system performance assessment (TSPA) related computing systems for the previously considered Yucca Mountain Project (YMP). This was done to maintain the operational readiness of the computing infrastructure (computer hardware and software) and knowledge capability for total system performance assessment (TSPA) type analysis, as directed by the National Nuclear Security Administration (NNSA), DOE 2010. This work is a continuation of the ongoing readiness evaluation reported in Lee and Hadgu (2014). The current work examined main components of the computing system identified in the previous work (Lee and Hadgu, 2014) to ensure the operational readiness of the TSPA-LA model capability on the server cluster. The TSPA computing hardware and storage system were replaced in late 2014 to maintain core capability and improve computation efficiency. One floating license of GoldSim Version 9.60.300 was installed on the upgraded cluster head node, and its distributed processing capability was mapped on the cluster processors. Other supporting software was tested and installed to support the TSPA-type analysis on the server cluster. All the TSPA-LA modeling cases were tested and verified for the model reproducibility on the upgraded 2014 server cluster (CL2014). All test runs were executed on multiple processors on the server cluster utilizing the GoldSim distributed processing capability, and all runs completed successfully. The model reproducibility verification was evaluated by two approaches: numerical value comparison and graphical comparison. The analysis demonstrated an excellent reproducibility of the TSPA-LA model runs on the upgraded server cluster. The 2014 server cluster and supporting software systems are fully operational to support TSPA- LA type analysis.

97 MATHEMATICS AND COMPUTING↗

Reproduction of the Yucca Mountain Project TSPA-LA Model Runs using TSPA Computing Systems

Sandia National Laboratories (SNL) conducted an evaluation of total system performance assessment (TSPA) related computing systems for the previously considered Yucca Mountain Project (YMP). This was done to maintain the operational readiness of the computing infrastructure (computer hardware and software) and knowledge capability for total system performance assessment (TSPA) type analysis, as directed by the National Nuclear Security Administration (NNSA), DOE 2010. This work is a continuation of the ongoing readiness evaluation reported in Lee and Hadgu (2014). The current work examined main components of the computing system identified in the previous work (Lee and Hadgu, 2014) to ensure the operational readiness of the TSPA-LA model capability on the server cluster. The TSPA computing hardware and storage system were replaced in late 2014 to maintain core capability and improve computation efficiency. One floating license of GoldSim Version 9.60.300 was installed on the upgraded cluster head node, and its distributed processing capability was mapped on the cluster processors. Other supporting software was tested and installed to support the TSPA-type analysis on the server cluster. All the TSPA-LA modeling cases were tested and verified for the model reproducibility on the upgraded 2014 server cluster (CL2014). All test runs were executed on multiple processors on the server cluster utilizing the GoldSim distributed processing capability, and all runs completed successfully. The model reproducibility verification was evaluated by two approaches: numerical value comparison and graphical comparison. The analysis demonstrated an excellent reproducibility of the TSPA-LA model runs on the upgraded server cluster. The 2014 server cluster and supporting software systems are fully operational to support TSPA- LA type analysis.

97 MATHEMATICS AND COMPUTING↗

Evaluation of the Computing Systems for Yucca Mountain Repository TSPA-LA Model Operational Readiness

Sandia National Laboratories (SNL) was tasked to conduct an evaluation of the legacy computing systems of the now-closed Yucca Mountain Project (YMP) to maintain the operational readiness of the computing infrastructure (computer hardware and software) and knowledge capability for total system performance assessment (TSPA) type analysis, in the event that the License Application (LA) review by the U.S. Nuclear Regulatory Commission (NRC) is re-started and involves additional requests for information (RAIs). Six problem areas or components of the computing system were identified and subsequently resolved or improved to ensure the operational readiness of the TSPA-LA model capability on the server cluster. As part of this readiness review, the legacy TSPA computational cluster that was relocated from the SNL YMP Lead Lab Project Office in Las Vegas, Nevada to the SNL offices in Albuquerque, New Mexico was replaced with new hardware. Three floating licenses of Goldsim Version 9.60.300 were installed on the new cluster head node, and its distributed processing capability was mapped on the cluster processors. Other supporting software was tested and installed to support the TSPA- type analysis on the server cluster. TSPA-LA modeling cases were tested and verified for the model reproducibility on the current server cluster. All test runs were executed on multiple processors on the server cluster utilizing the Goldsim distributed processing capability, and all runs were completed successfully. The model reproducibility verification was evaluated by two approaches: numerical value comparison and graphical comparison, and the analysis demonstrated an excellent reproducibility of the TSPA-LA model runs on the server cluster. The current server cluster and supporting software systems are fully operational to support TSPA-LA type analysis.

97 MATHEMATICS AND COMPUTING↗

Universal Utility Data Exchange (UUDEX) – Security and Administration: Cybersecurity of Energy Delivery Systems (CEDS) Research and Development

A critical component of the Universal Utility Data Exchange (UUDEX) approach is the integrated security contained within its processing. This document describes how that security is designed and expected to be implemented by UUDEX Implementations (U-Implementations), including the UUDEX Server (U-Server) and UUDEX Clients (U-Clients). The UUDEX security hierarchy consists of three levels: 1. The UUDEX Instance (U-Instance) itself, which sits at the top of the hierarchy and contains the U-Server, the UUDEX Identity Authority (U-Identity Authority), and the UUDEX Administrator (U-Administrator) functions; 2. A group of one or more UUDEX Participants (U-Participants) that present “organizations” that participate in the U-Instance and contains the UUDEX Administrator Participant (U-U-Administrator Participant) function; 3. A group of one or more UUDEX Endpoints (U-Endpoints) that represent the individual UUDEX Publish Clients (U-Publish Client) responsible for supplying data to the U-Instance that is consumed by UUDEX Subscriber Clients (U-Subscriber Clients). U-Endpoints can be either autonomous devices that publish and subscribe data such as data exchange servers found in supervisory control and data acquisition and energy management systems, or they can be tied to users of applications that, for example, submit DOE OE-417 disturbance reports. U-Participants and U-Endpoints can be organized into UUDEX Groups (U-Groups). Any number of U-Participants or U-Endpoints can be members of a U-Group. A given U-Participant or U-Endpoint can be a member of multiple U-Groups, but a U-Group cannot contain other U-Groups. For example, a U-Group could be created to contain all U-Participant Transmission Operators within the purview of a Reliability Coordinator, and another U-Group could be created to contain all U-Participant Generator Operators within the purview of a Reliability Coordinator. U-Participants that are both Transmission Operators and Generator Operators would be members of both U-Groups. U-Participants, U-Endpoints, and U-Groups are used in the access control structures to provide access to individual UUDEX Subjects (U-Subjects). U-Groups are created by the U-Administrator and are managed by the U-Administrator or the designated U-Group Managers. U-Endpoints can be assigned UUDEX Roles (U-Roles) that can be used to further restrict access. U-Roles are assigned to individual U-Endpoints. For example, a U-Role of “Security Analyst” could be used to restrict which U-Endpoints can publish or subscribe security incident reports and vulnerability notifications, while a U-Role of “Transmission Planner” can be used to restrict which U-Endpoints can publish power system model updates. U-Role definitions are created by the U-Administrator, but the U-Roles are assigned to U-Endpoints by their respective UUDEX Participant Administrators (U-Participant Administrator). Because all information required to make security decisions is either included within the U-Endpoint’s X.509 digital certificate or stored in a datastore on the U-Server, all security decisions are performed and enforced within the U-Server. This reduces the complexity of the U-Client code and minimizes the chance for compromise of the integrity of the UUDEX security features.

97 MATHEMATICS AND COMPUTING↗

Network issues for large mass storage requirements

File Servers and Supercomputing environments need high performance networks to balance the I/O requirements seen in today's demanding computing scenarios. UltraNet is one solution which permits both high aggregate transfer rates and high task-to-task transfer rates as demonstrated in actual tests. UltraNet provides this capability as both a Server-to-Server and Server-to-Client access network giving the supercomputing center the following advantages highest performance Transport Level connections (to 40 MBytes/sec effective rates); matches the throughput of the emerging high performance disk technologies, such as RAID, parallel head transfer devices and software striping; supports standard network and file system applications using SOCKET's based application program interface such as FTP, rcp, rdump, etc.; supports access to the Network File System (NFS) and LARGE aggregate bandwidth for large NFS usage; provides access to a distributed, hierarchical data server capability using DISCOS UniTree product; supports file server solutions available from multiple vendors, including Cray, Convex, Alliant, FPS, IBM, and others.

Perdue, James↗

Requirements for a network storage service

Sandia National Laboratories provides a high performance classified computer network as a core capability in support of its mission of nuclear weapons design and engineering, physical sciences research, and energy research and development. The network, locally known as the Internal Secure Network (ISN), comprises multiple distributed local area networks (LAN's) residing in New Mexico and California. The TCP/IP protocol suite is used for inter-node communications. Scientific workstations and mid-range computers, running UNIX-based operating systems, compose most LAN's. One LAN, operated by the Sandia Corporate Computing Computing Directorate, is a general purpose resource providing a supercomputer and a file server to the entire ISN. The current file server on the supercomputer LAN is an implementation of the Common File Server (CFS). Subsequent to the design of the ISN, Sandia reviewed its mass storage requirements and chose to enter into a competitive procurement to replace the existing file server with one more adaptable to a UNIX/TCP/IP environment. The requirements study for the network was the starting point for the requirements study for the new file server. The file server is called the Network Storage Service (NSS) and its requirements are described. An application or functional description of the NSS is given. The final section adds performance, capacity, and access constraints to the requirements.

Kelly, Suzanne M.↗