DOCSLIB.ORG

LDM7 Deployment Guidance

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
LDM7 Deployment Guidance LDM­7 Deployment Guidance Steve Emmerson, University Corporation for Atmospheric Research ([email protected]) ​ ​ Malathi Veeraraghavan, University of Virginia ([email protected]) ​ ​ Multicast network test To install LDM­7, you will need a Linux/Unix machine and a copy of the LDM­7 software package. Also, you need to make sure the network that LDM­7 is going to run on supports and has enabled multicast. To test whether multicast is supported, please follow the link https://github.com/shawnsschen/CC­NIE­Toolbox/tree/master/generic/mcast_test and obtain the two C files. One is for multicast sender and the other for receiver. If there are more than one network interfaces in the sender’s system, you have to manually update the routing table with one new entry: route add 224.0.0.1 dev eth1. Then use route ­n to check the updated routing ​ ​ ​ table. You will be able to see something like: Note that the entry we added is only matching a particular multicast address 224.0.0.1, not a subnet. If the multicast address changes, you need to manually change the configuration or use a subnet address. Now you have a multicast network (though not sure if it works), next step is to upload the mcast_send.c onto the sender system and mcast_recv.c onto all the receiver systems (more than one in a multicast network). Use the following command to compile them, respectively: gcc ­o send mcast_send.c gcc ­o recv mcast_recv.c send is a multicast sender­side test program, it sends out a “hello multicast world” message every second to multicast group 224.0.0.1:5173. recv is a multicast receiver­side program, ​ ​ ​ which receives the “hello multicast world” message from the multicast group 224.0.0.1:5173. ​ ​ Both send and recv take one input argument, the interface IP address, to inform the OS which interface they would like to use for multicast. For example, we usually use eth1 in GENI because it is the data­plane interface. Only on the same plane will this test program work. send listening on eth0 and recv listening on eth1 will not work since the management plane and data plane are physically disconnected. You can do a ping to test the reachability between interfaces. Once everything has settled, execute ./send <data­plane interface IP> on the sender system, ​ and execute ./recv <data­plane interface IP> on the receiver system. If working well, you will ​ be able to see “hello multicast world” on all systems. LDM­7 Installation As the multicast network itself is working well, we can proceed and start installing LDM­7 on all the nodes in this network. According to UCAR, here are the platform requirements before installing: https://www.unidata.ucar.edu/software/ldm/ldm­6.12.14/basics/platform.html. ​ ​ In addition, pax, sudo, libyaml­dev(el), sysstat, ntp, gcc 4.8, g++ 4.8 (gcc­c++ for CentOS), make, autoconf, m4, and automake are needed for compiling. Ubuntu: sudo apt­get install libxml2­dev libpng­dev zlib1g­dev sudo apt­get install pax libyaml­dev sysstat ntp autoconf m4 automake (Check gnuplot separately, vmstat, netstat, top, etc. should already be installed) Centos: yum install libxml2­devel yum install libpng­devel yum install zlib­devel Note that the development packages will be found in your package managers as ­dev in Ubuntu/Debian and ­devel in CentOS. Special Notes: zlib package can be found as zlib­dev(el) in package manager. For CentOS 6, the default gcc/g++ version provided by the system is too outdated. You have to manually upgrade it to 4.8. To do this: $ wget http://people.centos.org/tru/devtools­2/devtools­2.repo ­O /etc/yum.repos.d/devtools­2.repo $ yum install devtoolset­2­gcc devtoolset­2­binutils devtoolset­2­gcc­c++ $ mv /usr/bin/gcc /usr/bin/gcc_old $ mv /usr/bin/g++ /usr/bin/g++_old $ ln ­s /opt/rh/devtoolset­2/root/usr/bin/gcc /usr/bin/gcc $ ln ­s /opt/rh/devtoolset­2/root/usr/bin/g++ /usr/bin/g++ $ gcc ­v You will see gcc is upgraded to 4.8. For CentOS: To give sudo access to users in the wheel group, execute visudo and search for the ​ following line: # %wheel ALL=(ALL) ALL For Ubuntu: Look for the following line (it may not be commented) # %sudo ALL=(ALL) ALL Uncomment it by removing the hash mark if commented. If not commented do nothing. And save and quit. Now, upload LDM­7 package onto the nodes. Next, create an ldm user if it does not exist. To ​ create the user, execute: Centos: adduser ldm ​ Ubuntu: adduser ldm Then use passwd ldm to set a password. We also add ldm into the sudo list by executing the ​ ​ following command. Centos: usermod ­aG wheel ldm ​ Ubuntu: usermod ­aG sudo ldm (Can check if the following command was successful with: $ groups ldm) ​ ​ After the account is created, all the following operations will be done as user ldm. We switch to ​ ​ ldm home and proceed: su ­ ldm. ​ ​ Move your uploaded LDM­7 package to ldm home directory, you should expect something like ldm­6.12.15.42.tar.gz. We unpack it with: gunzip ­c ldm­6.12.15.42.tar.gz | pax ­r '­s:/:/src/:' ​ ​ Then we will compile it. Go into the source folder: cd /home/ldm/ldm­6.12.15.42/src. Use the ​ ​ following commands to compile (Note that if make distclean returns “No rule to make target…”, ​ it is fine, just proceed to next step): Centos: $ sudo /etc/init.d/rsyslog start (CentOS 6) $ sudo systemctl start rsyslog.service (CentOS 7) Ubuntu: $ sudo start rsyslog (restart if already running) $ make distclean $ find ­exec touch \{\} \; $ ./configure ­­with­debug ­­with­multicast ­­disable­root­actions CFLAGS=­g CXXFLAGS=­g $ make install $ sudo make root­actions If no error is reported, you will have a fresh installed LDM­7. We are going to configure it. For the sender side (upstream LDM­7), find the configuration file: vi $HOME/etc/ldmd.conf. Delete ​ ​ everything inside and add the following lines: MULTICAST ANY 224.0.0.1:38800 1 10.10.1.1 ALLOW ANY ^.*$ EXEC "insert.sh" EXEC "cpu_mon.sh" EXEC "tc_mon.sh" 10.10.1.1 is the data­plane IP address for the sender, you can replace it with the actual IP. 224.0.0.1 is the multicast address we are going to use, you should make sure it is the same as what you set in the routing table. For the receivers, open the same configuration file and delete everything. Add the following line: RECEIVE ANY 10.10.1.1 10.10.1.x 10.10.1.1 is the IP of the sender, 10.10.1.x is the IP of the receiver’s data­plane interface. ​ ​ ​ We need to configure the LDM­7 product queue settings as well. For LDM­7 sender, execute regutil ­s 5G /queue/size in ldm home. For receivers, execute regutil ­s 2G /queue/size ​ instead. Then execute regutil ­s 35000 /queue/slots. Finally, execute regutil ­s 10.10.1.x ​ ​ ​ /hostname, where 10.10.1.x is the corresponding IP on that node. ​ ​ ​ Some scripts for measurement are also needed. Go to https://github.com/shawnsschen/CC­NIE­Toolbox/tree/master/generic/misc and get util folder. ​ Put util onto the sender’s ldm home. Run chmod +x util/* to make sure all scripts are ​ ​ executable. Run chown ­R ldm.ldm util to change the permission. Then open ​ /home/ldm/.bash_profile and add a new line at the bottom: export ​ PATH=$PATH:$HOME/util. Then touch /home/ldm/.bash_profile. Put the github repo ​ ​ ​ containing the test input in ldm home: git clone ​ https://github.com/shawnsschen/LDM6­LDM7­comparison.git. ​ For bandwidth measurement, we need to use sysstat. Configure it to log every minute: sed ­i ­e \'s/*\/10/*\/1/g\' /etc/cron.d/sysstat rm /var/log/sa/* And make sure it is running: service crond start service sysstat start The last thing we need to do is to configure tc htb on the sender. Run the following commands ​ with root permission (assuming eth1 is the data­plane interface): tc qdisc del dev eth1 root tc qdisc add dev eth1 root handle 1: htb default 2 tc class add dev eth1 parent 1: classid 1:1 htb rate 20mbit ceil 20mbit tc qdisc add dev eth1 parent 1:1 handle 10: bfifo limit 600mb tc class add dev eth1 parent 1: classid 1:2 htb rate 20mbit ceil 20mbit tc qdisc add dev eth1 parent 1:2 handle 11: bfifo limit 600mb tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 224.0.0.1/32 flowid 1:1 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 0/0 flowid 1:2 20 Mbps (per­class sending rate) and 600 Mb (per­class BFIFO size) are the key parameters for LDM­7, as the experimental settings change, you can replace them with new values. So far, we have finished all the settings and are good to go! But wait a second, open util/insert.sh on the sender. See the sleep xxx line? Change it with the value: m*40, where m ​ ​ ​ ​ is your number of receivers. This is to make sure the sender would not start sending before all receivers are connected. You can have 40 seconds to start a receiving LDM. You can also set it to a larger value to buy yourself more time.
Load more

Recommended publications
  • NOAA Technical Report NOS NGS 60
    NOAA Technical Report NOS NGS 60 NAD83 (NSR2007) National Readjustment Final Report Dale G. Pursell Mike Potterfield Rockville, MD August 2008 NOAA Technical Report NOS NGS 60 NAD 83(NSRS2007) National Readjustment Final Report Dale G. Pursell Mike Potterfield Silver Spring, MD August 2008 U.S. DEPARTMENT OF COMMERCE National Oceanic and Atmospheric Administration National Ocean Service Contents Overview ........................................................................................................................ 1 Part I. Background .................................................................................................... 5 1. North American Datum of 1983 (1986) .......................................................................... 5 2. High Accuracy Reference Networks (HARNs) .............................................................. 5 3. Continuously Operating Reference Stations (CORS) .................................................... 7 4. Federal Base Networks (FBNs) ...................................................................................... 8 5. National Readjustment .................................................................................................... 9 Part II. Data Inventory, Assessment and Input ....................................... 11 6. Preliminary GPS Project Analysis ................................................................................11 7. Master File .....................................................................................................................11
    [Show full text]
  • A Longitudinal and Cross-Dataset Study of Internet Latency and Path Stability
    A Longitudinal and Cross-Dataset Study of Internet Latency and Path Stability Mosharaf Chowdhury Rachit Agarwal Vyas Sekar Ion Stoica Electrical Engineering and Computer Sciences University of California at Berkeley Technical Report No. UCB/EECS-2014-172 http://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-172.html October 11, 2014 Copyright © 2014, by the author(s). All rights reserved. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission. A Longitudinal and Cross-Dataset Study of Internet Latency and Path Stability Mosharaf Chowdhury Rachit Agarwal Vyas Sekar Ion Stoica UC Berkeley UC Berkeley Carnegie Mellon University UC Berkeley ABSTRACT Even though our work does not provide new active mea- We present a retrospective and longitudinal study of Internet surement techniques or new datasets, we believe that there is value in this retrospective analysis on several fronts. First, it latency and path stability using three large-scale traceroute provides a historical and longitudinal perspective of Internet datasets collected over several years: Ark and iPlane from path properties that are surprisingly lacking in the measure- 2008 to 2013 and a proprietary CDN’s traceroute dataset spanning 2012 and 2013. Using these different “lenses”, we ment community today. Second, it can help us revisit and revisit classical properties of Internet paths such as end-to- reappraise classical assumptions about path latency and sta- end latency, stability, and of routing graph structure.
    [Show full text]
  • Misleading Stars: What Cannot Be Measured in the Internet?
    Noname manuscript No. (will be inserted by the editor) Misleading Stars: What Cannot Be Measured in the Internet? Yvonne-Anne Pignolet · Stefan Schmid · Gilles Tredan Abstract Traceroute measurements are one of the main in- set can help to determine global properties such as the con- struments to shed light onto the structure and properties of nectivity. today’s complex networks such as the Internet. This arti- cle studies the feasibility and infeasibility of inferring the network topology given traceroute data from a worst-case 1 Introduction perspective, i.e., without any probabilistic assumptions on, e.g., the nodes’ degree distribution. We attend to a scenario Surprisingly little is known about the structure of many im- where some of the routers are anonymous, and propose two portant complex networks such as the Internet. One reason fundamental axioms that model two basic assumptions on is the inherent difficulty of performing accurate, large-scale the traceroute data: (1) each trace corresponds to a real path and preferably synchronous measurements from a large in the network, and (2) the routing paths are at most a factor number of different vantage points. Another reason are pri- 1/α off the shortest paths, for some parameter α 2 (0; 1]. vacy and information hiding issues: for example, network In contrast to existing literature that focuses on the cardi- providers may seek to hide the details of their infrastructure nality of the set of (often only minimal) inferrable topolo- to avoid tailored attacks. gies, we argue that a large number of possible topologies Knowledge of the network characteristics is crucial for alone is often unproblematic, as long as the networks have many applications as well as for an efficient operation of the a similar structure.
    [Show full text]
  • PAX A920 Mobile Smart Terminal Quick Setup Guide
    PAX A920 QUICK SETUP GUIDE PAX A920 Mobile Smart Terminal Quick Setup Guide 2018000702 v1.8 1 PAX Technology® Customer Support [email protected] (877) 859-0099 www.pax.us PAX A920 QUICK SETUP GUIDE PAX A920 Mobile Terminal Intelligence of an ECR in a handheld point of sale. The PAX A920 is an elegantly designed compact secure portable payment terminal powered by an Android operating system. The A920 comes with a large high definition color display. A thermal printer and includes NFC contactless and electronic signature capture. Great battery life for portable use. 2018000702 v1.8 2 PAX Technology® Customer Support [email protected] (877) 859-0099 www.pax.us PAX A920 QUICK SETUP GUIDE 1 What’s in The Box The PAX A920 includes the following items in the box. 2018000702 v1.8 3 PAX Technology® Customer Support [email protected] (877) 859-0099 www.pax.us PAX A920 QUICK SETUP GUIDE 2 A920 Charging Instructions Before starting the A920 battery should be fully charged by plugging the USB to micro USB cord to a PC or an AC power supply and then plug the other end with the micro USB connector into the micro USB port on the left side of the terminal. Charge the battery until full. Note: There is a protective cover on the new battery terminals that must be removed before charging the battery. See Remove and Replace Battery section. 2018000702 v1.8 4 PAX Technology® Customer Support [email protected] (877) 859-0099 www.pax.us PAX A920 QUICK SETUP GUIDE 3 A920 Buttons and Functions Front Description 6 1 2 7 3 8 9 4 5 2018000702 v1.8 5 PAX Technology® Customer Support [email protected] (877) 859-0099 www.pax.us PAX A920 QUICK SETUP GUIDE 3.1 A920 Buttons and Functions Front Description 1.
    [Show full text]
  • PAX-It! TM Applications the Paxcam Digital USB 2.0 Camera System
    Digital Imaging Workflow for Industrial From the Makers of PAX-it! TM Applications The PAXcam Digital USB 2.0 Camera System l Affordable camera for microscopy, with an easy-to-use interface l Beautiful, high-resolution images; true color rendition l Fully integrated package with camera and software l USB 2.0 interface for the fastest live digital color preview on the market l Easy-to-use interface for color balance, exposure & contrast control, including focus indicator tool l Adjustable capture resolution settings (true optical resolution -- no interpolation) l Auto exposure, auto white balance and manual color adjustment are supported l Create and apply templates and transparencies over the live image l Acquire images directly into the PAX-it archive for easy workflow l Easy one-cable connection to computer; can also be used on a laptop l Adjustable region of interest means smaller file sizes when capturing images l PAXcam interface can control multiple cameras from the same computer l Stored presets may be used to save all camera settings for repeat conditions Capture Images Directly to PAX-it Image Database Software Includes PAXcam Video Agent for motion video capture l Time lapse image capture l Combine still images to create movie files l Extract individual frames of video clips as bitmap images Live preview up to 40 fps PAX-it! l File & retrieve images in easy-to-use cabinet/folder structure l Store images, video clips, documents, and other standard digital file types l Images and other files are in a searchable database that you
    [Show full text]
  • Freebsd and Netbsd on Small X86 Based Systems
    FreeBSD and NetBSD on Small x86 Based Systems Dr. Adrian Steinmann <[email protected]> Asia BSD Conference in Tokyo, Japan March 17th, 2011 1 Introduction Who am I? • Ph.D. in Mathematical Physics (long time ago) • Webgroup Consulting AG (now) • IT Consulting Open Source, Security, Perl • FreeBSD since version 1.0 (1993) • NetBSD since version 3.0 (2005) • Traveling, Sculpting, Go AsiaBSDCon Tutorial March 17, 2011 in Tokyo, Japan “Installing and Running FreeBSD and NetBSD on Small x86 Based Systems” Dr. Adrian Steinmann <[email protected]> 2 Focus on Installing and Running FreeBSD and NetBSD on Compact Flash Systems (1) Overview of suitable SW for small x86 based systems with compact flash (CF) (2) Live CD / USB dists to try out and bootstrap onto a CF (3) Overview of HW for small x86 systems (4) Installation strategies: what needs special attention when doing installations to CF (5) Building your own custom Install/Maintenance RAMdisk AsiaBSDCon Tutorial March 17, 2011 in Tokyo, Japan “Installing and Running FreeBSD and NetBSD on Small x86 Based Systems” Dr. Adrian Steinmann <[email protected]> 3 FreeBSD for Small HW Many choices! – Too many? • PicoBSD / TinyBSD • miniBSD & m0n0wall • pfSense • FreeBSD livefs, memstick • NanoBSD • STYX. Others: druidbsd, Beastiebox, Cauldron Project, ... AsiaBSDCon Tutorial March 17, 2011 in Tokyo, Japan “Installing and Running FreeBSD and NetBSD on Small x86 Based Systems” Dr. Adrian Steinmann <[email protected]> 4 PicoBSD & miniBSD • PicoBSD (1998): Initial import into src/release/picobsd/ by Andrzej Bialecki <[email protected]
    [Show full text]
  • Parallel MPI I/O in Cube: Design & Implementation
    Parallel MPI I/O in Cube: Design & Implementation Bine Brank A master thesis presented for the degree of M.Sc. Computer Simulation in Science Supervisors: Prof. Dr. Norbert Eicker Dr. Pavel Saviankou Bergische Universit¨atWuppertal in cooperation with Forschungszentrum J¨ulich September, 2018 Erkl¨arung Ich versichere, dass ich die Arbeit selbstst¨andigverfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitate kenntlich gemacht habe. Mit Abgabe der Abschlussarbeit erkenne ich an, dass die Arbeit durch Dritte eingesehen und unter Wahrung urheberrechtlicher Grunds¨atzezi- tiert werden darf. Ferner stimme ich zu, dass die Arbeit durch das Fachgebiet an Dritte zur Einsichtnahme herausgegeben werden darf. Wuppertal, 27.8.2017 Bine Brank 1 Acknowledgements Foremost, I would like to express my deepest and sincere gratitude to Dr. Pavel Saviankou. Not only did he introduce me to this interesting topic, but his way of guiding and supporting me was beyond anything I could ever hoped for. Always happy to discuss ideas and answer any of my questions, he has truly set an example of excellence as a researcher, mentor and a friend. In addition, I would like to thank Prof. Dr. Norbert Eicker for agreeing to supervise my thesis. I am very thankful for all remarks, corrections and help that he provided. I would also like to thank Ilya Zhukov for helping me with the correct in- stallation/configuration of the CP2K software. 2 Contents 1 Introduction 7 2 HPC ecosystem 8 2.1 Origins of HPC . 8 2.2 Parallel programming . 9 2.3 Automatic performance analysis . 10 2.4 Tools .
    [Show full text]
  • Release 0.11.0
    mpiFileUtils Documentation Release 0.11.0 HPC Sep 29, 2021 Contents 1 Overview 1 2 User Guide 3 2.1 Project Design Principles........................................3 2.1.1 Scale..............................................3 2.1.2 Performance...........................................3 2.1.3 Portability............................................3 2.1.4 Composability..........................................4 2.2 Utilities..................................................4 2.3 Experimental Utilities..........................................4 2.4 libmfu..................................................4 2.4.1 libmfu: the mpiFileUtils common library...........................5 2.4.2 mfu_flist.............................................5 2.4.3 mfu_path............................................5 2.4.4 mfu_param_path........................................5 2.4.5 mfu_io..............................................5 2.4.6 mfu_util.............................................6 2.5 Build...................................................6 2.5.1 Build everything with Spack..................................6 2.5.2 Build everything directly....................................6 2.5.3 Build everything directly with DAOS support.........................8 2.5.4 Build mpiFileUtils directly, build its dependencies with Spack................8 3 Man Pages 9 3.1 dbcast...................................................9 3.1.1 SYNOPSIS...........................................9 3.1.2 DESCRIPTION.........................................9 3.1.3 OPTIONS............................................9
    [Show full text]
  • Z/VM Version 7 Release 2
    z/VM Version 7 Release 2 OpenExtensions User's Guide IBM SC24-6299-01 Note: Before you use this information and the product it supports, read the information in “Notices” on page 201. This edition applies to Version 7.2 of IBM z/VM (product number 5741-A09) and to all subsequent releases and modifications until otherwise indicated in new editions. Last updated: 2020-09-08 © Copyright International Business Machines Corporation 1993, 2020. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Figures................................................................................................................. xi Tables................................................................................................................ xiii About this Document........................................................................................... xv Intended Audience..................................................................................................................................... xv Conventions Used in This Document......................................................................................................... xv Escape Character Notation................................................................................................................... xv Case-Sensitivity.....................................................................................................................................xv Typography............................................................................................................................................xv
    [Show full text]
  • The Emaginepos Guide to Pax / Emv / Broadpos
    THE EMAGINEPOS GUIDE TO PAX / EMV / BROADPOS Author Davis Ford <[email protected]> Last Updated 9/22/2016 THE EMAGINEPOS GUIDE TO PAX / EMV / BROADPOS What Is BroadPOS? Some things you can do with BroadPOS What Processors Are Currently Supported? How To Login To BroadPOS Support Checklist Step -1: Things Specific To Processors Tokenization (attach credit card): Batch Out Step 0: Get One Or More VAR Sheets for the Merchant Step 1: Create a New Merchant (if necessary) Step 2: Add the Serial Numbers of the New Terminal(s) Step 3: Create A New Template TSYS Parameters TSYS Tab => Merchant Parameters TSYS Tab => Host Feature First Data Omaha Parameters First Data Omaha Tab => Host Features, Host URLs First Data Rapid Connect Parameters FirstData RapidConnect Tab => Host Features FirstData RapidConnect Tab => Host URLs Heartland Portico Parameters Hsptc Tab => Host Features Hsptc Tab => Merchant Parameters Hsptc Tab => Host URLs Hsptc Tab => Dial Parameters Misc Tab => Communication Tab => General Communication Tab => LAN Communication Tab => Communication between ECR/POS and PAX terminal Communication => POS System Feature (Ethernet Only) Step 4: Deploy The Template Step 5: Install the Browser Extension for Emagine Payments Step 6: Setup Payment Terminals in the Backoffice Step 7: Create New Payment Type for EMV (if necessary) Step 8: Test The Terminal Frequently Asked Questions / Troubleshooting PAX Frequently Asked Questions List CONNECT ERROR when I try to execute a transaction SWIPE ONLY error when I try to Void or Adjust NOTES on First
    [Show full text]
  • An Airborne Network Telemetry Link for the Inet Technical Demonstration System
    An Airborne Network Telemetry Link for the iNET Technical Demonstration System Item Type text; Proceedings Authors Temple, Kip; Laird, Daniel Publisher International Foundation for Telemetering Journal International Telemetering Conference Proceedings Rights Copyright © held by the author; distribution rights International Foundation for Telemetering Download date 25/09/2021 05:15:29 Link to Item http://hdl.handle.net/10150/606170 AN AIRBORNE NETWORK TELEMETRY LINK FOR THE INET TECHNICAL DEMONSTRATION SYSTEM Kip Temple Air Force Flight Test Center, Edwards AFB CA Daniel Laird Air Force Flight Test Center, Edwards AFB CA ABSTRACT A previous paper was presented [1] detailing the design and testing of the first networked demonstration system (ITC 2006) for iNET. This paper extends that work by testing a commercial off the shelf (COTS) solution for the wireless network connection of the Telemetry Network System (TmNS). This paper will briefly discuss specific pieces of the airborne and ground station system but will concentrate on the new wireless network link, how it was tested, and how well it performed. Flight testing results will be presented accessing the performance of the wireless network link. KEY WORDS integrated Networked Enhanced Telemetry (iNET), wireless network link, Telemetry Network System (TmNS), serial streaming telemetry INTRODUCTION The iNET Team has assembled a Demonstration System to not only assess COTS wireless network link performance within the aeronautical test environment but also to demonstrate the potential uses of a network linked system. The TmNS is shown pictorially in Figure 1. The four components are the vehicular network, or the Test Article Segment (TAS), the interface to the ground station, or Ground Station Segment (GSS), the wireless network link that ties the two networks together, and the legacy serial streaming telemetry (SST) link.
    [Show full text]
  • Objections to Killer Robots
    DEADLY Decisions objections to 8 killer robots Address: Postal Address: Godebaldkwartier 74 PO Box 19318 3511 DZ Utrecht 3501 DH Utrecht The Netherlands The Netherlands www.paxforpeace.nl [email protected] © PAX 2014 Authors: Merel Ekelhof Miriam Struyk Lay-out: Jasper van der Kist This is a publication of PAX. PAX is a founder of the Campaign to Stop Killer Robots. For more information, visit our website: www.paxforpeace.nl or www.stopkillerrobots.org About PAX, formerly known as IKV Pax Christi PAX stands for peace. Together with people in conflict areas and critical citizens in the Netherlands, we work on a dignified, democratic and peaceful society, everywhere in the world. Peace requires courage. The courage to believe that peace is possible, to row against the tide, to speak out and to carry on no matter what. Everyone in the world can contribute to peace, but that takes courage. The courage to praise peace, to shout it from the rooftops and to write it on the walls. The courage to call politicians to accountability and to look beyond your own boundaries. The courage to address people and to invite them to take part, regardless of their background. PAX brings people together who have the courage to stand for peace. We work together with people in conflict areas, visit politicians and combine efforts with committed citizens. www.PAXforpeace.nl The authors would like to thank Roos Boer, Bonnie Docherty, Alexandra Hiniker, Daan Kayser, Noel Sharkey and Wim Zwijnenburg for their comments and advice. First, you had human beings without machines. Then you had human beings with machines.
    [Show full text]