DOCSLIB.ORG

White Paper Northforge Innovations Inc

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
White Paper Northforge Innovations Inc Modern Packet Switch Design White Paper Northforge Innovations Inc. September 2016 1 Introduction This white paper surveys the architectural evolution of Ethernet packet switches, featuring an overview of early packet switch design and the forces that have driven modern design solutions. These forces, which include increased interface speed, increased number of ports, Software-Defined Networking (SDN), Deep Packet Inspection (DPI), and Network Functions Virtualization (NFV) have had a major impact on the architecture and design of modern packet switches. All Packet Switches Are Divided Into Three Parts The networking industy has been building LAN-based packet switches (including under this rubric, LAN Bridges, MPLS Switches, and IP Routers) since the early-mid 1980s. The three functional components of a packet switch have been stable since the beginning. • Data plane – The primary job of a packet switch is to move packets from an input interface to an output interface. Moving the data from input to output is the job of the data plane (sometimes called the forwarding plane). • Control plane – The data plane decides which output port to select for each arriving packet based on a set of tables that are built by the control plane. For an Ethernet Switch, the control plane includes the process that learns MAC addresses, the spanning tree protocol, etc. For an IP router, the control plane includes the various IP routing protocols (e.g., OSPF and IS-IS). • Management plane – All packet switches require some configuration. In addition, they include mechanisms for fault detection and reporting, statistics collection, and troubleshooting. This is all done by the management plane. The management plane includes the CLI, structured management information (e.g., MIBs), and protocols for accessing management information (e.g., SNMP). The Early Years For the first 20 years or so, although LANs got faster, there were only two major changes in packet switch design and architecture. The first change occurred when LANs moved from shared coaxial cable to twisted pair (10BASE-T). When LANs were based on shared media, the packet switches had a relatively small number of interfaces (2 to 8) because each connected LAN could have dozens of systems connected. The packet switch connected networks together. When LANs moved to twisted pair cable and each switch interface connected to a single system (which might be another switch), the packet switch was the network. At that point we started seeing 8, 16, 32, 64 port switches. A related architectural change was the move from software-based implementations (based on standard CPUs, frequently Motorola 68000-series and occasionally Intel x86), often with some hardware assist, to ASIC-based implementations. Fortunately both of these changes happened around the same time (from about 1990 to 1995) since as the number of ports increased, software-based implementations became impractical. 1 Packet performance is usually based on minimum-sized packets (64 bytes). Although some aspects of forwarding performance may be limited by the actual data rate (which is higher with larger packets), per-packet functions such as address lookups tend to be the limiting factor, and minimum-sized packets have the highest packet rate. 2 Early Switch with Software Data Plane Early Switch with Switching SI Management Plane IF IF IF IF Control Plane CPU Data Plane Data Plane CPU Switch Control ASIC Management Optional Hardware Forwarding IF IF Assist The move to ASIC-based switching was critical to the success of packet switching. A 10Mbps Ethernet carries ~15,000 packets per second, so a packet switch with two 10Mbps Ethernet interfaces processes as many as 30,000 pps. This was feasible on a single CPU in 1990. A packet switch with two 100Mbps Ethernet interfaces processes 300,000 pps. This was feasible on a single CPU in the late 1990s. However, by then, it was common to deploy packet switches with 16 ports or more. In 1998 gigabit Ethernet was standardized increasing the packet rate on each interface by another factor of ten. Clearly, packet switching now depends on an ASIC-based forwarding plane. Today, switches with 64 or more 10Gbps ports are common. A 10Gbps Ethernet can source 15,000,000 pps, so these switches process a billion packets per second or more! During this period, very little happened in the control and management planes. The control plane migrated to newer protocols — at layer 2, Spanning Tree moved to Rapid and Multiple Spanning Tree and at layer 3, distance-vector protocols such as RIP and IGRP moved to link state protocols such as OSPF and IS-IS. MPLS was introduced during this period adding a new set of control protocols, a new set of data plane tables, and a new data plane forwarding algorithm. None of these improvements required substantial architectural change. The Later Years Ethernet keeps getting faster and the number of connected stations keeps increasing, so the data plane of packet switches continues to get bigger and faster. In the last 10 years there have been major changes to the functionality and implementation in all of the planes some of which have resulted in changes to the architecture and design of packet switches. The Modern Management Plane In the management plane there has been a migration towards a new way of expressing management information, moving away from ASN.1 and MIBs to a new data modeling language called YANG. YANG information is communicated using a new protocol called NETCONF (rather than SNMP). This is a major software change but does not result in any architectural changes. Another change in the management plane is the inclusion of Fault Management (FM) based on standards IEEE 802.1Q(ag) and ITU-T Y.1731 and Performance Monitoring (PM) based on ITU-T Y.1731. Although found primarily in carrier-based packet switches, they can 3 be used in enterprise networks also. These protocols require substantial software support and the regular exchange of protocol messages. The number of messages that need to be sent and received can be quite large (especially for PM), and therefore call for enhanced CPU capabilities or external hardware assist (e.g., an FPGA). Increasingly these capabilities are built right into the switch ASIC. The Modern Control Plane As noted above, the IP interior gateway protocols have migrated over the years from distance vector protocols to link state protocols. IP routers also frequently run BGP. At layer 2, the Spanning Tree Protocol migrated to Rapid (and Multiple) Spanning Tree Protocol. Newer layer 2 protection protocols such as ITU-T G.8032 Ethernet Ring Protection and G.8031 Ethernet Linear Protection became popular primarily because of their faster switching time. Also, MPLS became a staple on packet switches (especially those that supported IP), which brought along additional control protocols, primarily the Label Distribution Protocol (LDP) and RSVP-TE. None of these changes required substantial architectural changes in the switch. Some new control tables were needed and depending on the protocols supported and the design center with respect to network size, there was an effect on CPU power and the amount of memory needed for the control tables. A divergence has also developed over the past several years between the control protocols used in carrier networks (and enterprise networks) and those used in data centers. Data centers pose a unique challenge in that they have a very large number (hundreds or more) of colocated systems that must be interconnected with high bandwidth. This has resulted in development of new techniques and protocols. Two competing solutions are used in these environments, either the IEEE 802.1Q(aq) protocol Shortest Path Bridging (SPB), or the IETF protocol, Transparent Interconnection of Lots of Links (TRILL, several RFCs based on RFC6325). Over the past several years, however, a major new approach to packet switch control planes has garnered increasing interest – Software Defined Networking or SDN. The Control Plane is a body of software (firmware) that builds tables to drive the activity of the data plane. Control plane protocols are used to exchange information with the other systems in the network in order to derive the information necessary to build the tables. This is a distributed control plane since each node is performing its own computations to populate its forwarding tables. Software Defined Networking is a technique for centralizing the control plane. With SDN, a server communicates with the network elements to collect system and interface state information. The server then computes forwarding table information for each network element (NE) and distributes the new/updated information to each NE. With SDN, the control plane in each NE consists of a protocol processor that can receive the forwarding table updates and apply them to the data plane. The most common protocol for encoding and encapsulating this information is OpenFlow. There are several perceived2 benefits of SDN over the traditional distributed control plane: • Reduced reliance on proprietary protocol implementations – software embedded in network elements is developed, owned, and maintained by the equipment vendor. Improvements, enhancements, bug fixes, overall product direction, and, of course, cost are all based on the product strategy and direction of the vendor. With SDN, control software runs on an external server and therefore the network operator can purchase (or develop) software as needed. This can result in lower cost as well as faster adoption of new capabilities and features. • Lower equipment and network cost – with a distributed control plane each network element has “X” computes (generic unit of computation power) to apply to running the control plane protocols. In a network with 50 network elements there are 50X computes deployed for control plane protocols. If the processing is centralized, each network element requires substantially less horsepower for the control plane so each network element can cost less.
Load more

Recommended publications
  • Operating RISC: UNIX Standards in the 1990S
    Operating RISC: UNIX Standards in the 1990s This case was written by Will Mitchell and Paul Kritikos at the University of Michigan. The case is based on public sources. Some figures are based on case-writers' estimates. We appreciate comments from David Girouard, Robert E. Thomas and Michael Wolff. The note "Product Standards and Competitive Advantage" (Mitchell 1992) supplements this case. The latest International Computerquest Corporation analysis of the market for UNIX- based computers landed on three desks on the same morning. Noel Sharp, founder, chief executive officer, chief engineer and chief bottle washer for the Superbly Quick Architecture Workstation Company (SQAWC) in Mountain View, California hoped to see strong growth predicted for the market for systems designed to help architects improve their designs. In New York, Bo Thomas, senior strategist for the UNIX systems division of A Big Computer Company (ABCC), hoped that general commercial markets for UNIX-based computer systems would show strong growth, but feared that the company's traditional mainframe and mini-computer sales would suffer as a result. Airborne in the middle of the Atlantic, Jean-Helmut Morini-Stokes, senior engineer for the UNIX division of European Electronic National Industry (EENI), immediately looked to see if European companies would finally have an impact on the American market for UNIX-based systems. After looking for analysis concerning their own companies, all three managers checked the outlook for the alliances competing to establish a UNIX operating system standard. Although their companies were alike only in being fictional, the three managers faced the same product standards issues. How could they hasten the adoption of a UNIX standard? The market simply would not grow until computer buyers and application software developers could count on operating system stability.
    [Show full text]
  • I.T.S.O. Powerpc an Inside View
    SG24-4299-00 PowerPC An Inside View IBM SG24-4299-00 PowerPC An Inside View Take Note! Before using this information and the product it supports, be sure to read the general information under “Special Notices” on page xiii. First Edition (September 1995) This edition applies to the IBM PC PowerPC hardware and software products currently announced at the date of publication. Order publications through your IBM representative or the IBM branch office serving your locality. Publications are not stocked at the address given below. An ITSO Technical Bulletin Evaluation Form for reader′s feedback appears facing Chapter 1. If the form has been removed, comments may be addressed to: IBM Corporation, International Technical Support Organization Dept. JLPC Building 014 Internal Zip 5220 1000 NW 51st Street Boca Raton, Florida 33431-1328 When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you. Copyright International Business Machines Corporation 1995. All rights reserved. Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp. Abstract This document provides technical details on the PowerPC technology. It focuses on the features and advantages of the PowerPC Architecture and includes an historical overview of the development of the reduced instruction set computer (RISC) technology. It also describes in detail the IBM Power Series product family based on PowerPC technology, including IBM Personal Computer Power Series 830 and 850 and IBM ThinkPad Power Series 820 and 850.
    [Show full text]
  • A Brief History of Debian I
    A Brief History of Debian i A Brief History of Debian A Brief History of Debian ii 1999-2020Debian Documentation Team [email protected] Debian Documentation Team This document may be freely redistributed or modified in any form provided your changes are clearly documented. This document may be redistributed for fee or free, and may be modified (including translation from one type of media or file format to another or from one spoken language to another) provided that all changes from the original are clearly marked as such. Significant contributions were made to this document by • Javier Fernández-Sanguino [email protected] • Bdale Garbee [email protected] • Hartmut Koptein [email protected] • Nils Lohner [email protected] • Will Lowe [email protected] • Bill Mitchell [email protected] • Ian Murdock • Martin Schulze [email protected] • Craig Small [email protected] This document is primarily maintained by Bdale Garbee [email protected]. A Brief History of Debian iii COLLABORATORS TITLE : A Brief History of Debian ACTION NAME DATE SIGNATURE WRITTEN BY September 14, 2020 REVISION HISTORY NUMBER DATE DESCRIPTION NAME A Brief History of Debian iv Contents 1 Introduction -- What is the Debian Project? 1 1.1 In the Beginning ................................................... 1 1.2 Pronouncing Debian ................................................. 1 2 Leadership 2 3 Debian Releases 3 4 A Detailed History 6 4.1 The 0.x Releases ................................................... 6 4.1.1 The Early Debian Packaging System ..................................... 7 4.2 The 1.x Releases ................................................... 7 4.3 The 2.x Releases ................................................... 8 4.4 The 3.x Releases ................................................... 8 4.5 The 4.x Releases ..................................................
    [Show full text]
  • Microprocessors: from Basic Chips to Complete Systems
    - 237 - MICROPROCESSORS: FROM BASIC CHIPS TO COMPLETE SYSTEMS R. W. Dobinson,*) University of Illinois, Urbana, Illinois, USA. "Good-morning, good morning!", the General said When we met him last week on our way to the line. Now the soldiers he smiled at are most of them dead, And we're cursing his staff for Incompetent swine. "He's a cheery old card," grunted Harry to Jack As they slogged up to Arras with rifle and pack. * * * * But he did for them both by his plan of attack. Siegfried Sassoon April 1917 1. AIMS OF THESE LECTURES Microprocessor technology has, since its conception and birth in the early 1970's, entered very many areas of our lives. No end to its growth is in sight, and new uses appear almost daily. The semiconductor industry continues to produce ever more powerful integrated circuits (known far and wide as chips); more functionality and speed at lower cost is every salesman's cry. These lectures aim to present and explain in general terms some of the characteristics of microprocessor chips and associated components. They will show how systems are synthesized from the basic integrated circuit building blocks which are currently available; processor, memory, input-output (I/O) devices, etc. It is not my intention to discuss in detail the many different microprocessors now available on the market, nor will a complete catalogue of support chips be presented. Time will not permit this. Instead, emphasis will be placed on explaining the basic principles of different types of chip. As far as possible X will avoid talking too much about any specific devices; thus I will spend some time discussing a generic microprocessor accessing generic memory and talking to the outside world via generic I/O devices.
    [Show full text]
  • Experimental Verification of Mission Planning by Autonomous Mission Execution and Data Visualization Using the NPS AUV II
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Calhoun, Institutional Archive of the Naval Postgraduate School Calhoun: The NPS Institutional Archive Faculty and Researcher Publications Faculty and Researcher Publications 1992 Experimental verification of mission planning by autonomous mission execution and data visualization using the NPS AUV II Healey, A.J. http://hdl.handle.net/10945/44824 EXPERIMENT AL VERIFICATION OF MISSION PLANNING BY AUTONOMOUS MISSION EXECUTION AND DATA YISUALIZATION USING THE NPS AUV II A. J. Healey, D. B. Marco Naval Postgraduate School Monterey, Calif. 93943 (408)-646-2586 (Phone) (408)-646-2238 (Fax) ABSTRACT University of Tokyo has recently developed an underwater vehicle for bottom contour following using neural network techniques This paper describes recent results in mission execution, and (Ura, 1990). At the Nava! Postgra?uate School, we have developed post mission data analysis from the NPS AUV II testbed underwater an ~nderwater testbed :<eh1cle that 1s specifically designed to test and vehicle. Ongoing research is focused on control technology to meet very.fy ~evelopments m control technology. It is run in the NPS the needs of future Naval Autonomous Underwater Vehicles. These sw1mmmg. pool . as an environment for experimental mission vehicle~ are unmanned, untethered, free swimming, robotic demonstrauon usmg a GESPAC computer with a Motorola 68030 submannes to be used for Naval missions including search, C~U. a 2MByt~ R~M card with control code written in "C". The mapping, surveillance, and intervention activity. The approach m1ss1oi: pl~nmng 1_nterface with the vehicle control computer is taken at NPS combines integrated computer simulation, real time e~b?d1ed m_a <;JR1DCASE laptop M~-DOS machine containing rob~st control theory, computer architecture and code development, rmss_10n details m the form of way pomts and run times that are vehicle and component design and experimentation, sonar data obtamed from an external pre-mission planning analysis.
    [Show full text]
  • The Definitive Guide to GCC
    The Definitive Guide to GCC KURT WALL AND WILLIAM VON HAGEN APress Media, LLC The Definitive Guide to GCC Copyright ©2004 by Kurt Wall and William von Hagen Originally published by Apress in 2004 All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and the publisher. ISBN 978-1-59059-109-3 ISBN 978-1-4302-0704-7 (eBook) DOI 10.1007/978-1-4302-0704-7 Trademarked names may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, we use the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. Technical Reviewer: Gene Sally Editorial Board: Steve Anglin, Dan Appleman, Gary Cornell, James Cox, Tony Davis, John Franklin, Chris Mills, Steven Rycroft, Dominic Shakeshaft, Julian Skinner, Martin Streicher, Jim Sumser, Karen Watterson, Gavin Wray, John Zukowski Assistant Publisher: Grace Wong Project Manager: Sofia Marchant Copy Editor: Ami Knox Production Manager: Kari Brooks Production Editor: Janet Vaii Proofreader: Elizabeth Berry Compositor and Artist: Kinetic Publishing Services, llC Indexer: Valerie Perry Cover Designer: Kurt Krames Manufacturing Manager: Tom Debolski The information in this book is distributed on an "as is" hasis, without warranty. Although every precaution bas been taken in the preparation of this work, neither the author(s) nor Apress shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the information contained in this work.
    [Show full text]
  • Gnu Assembler
    Using as The gnu Assembler (Sourcery G++ Lite 2010q1-188) Version 2.19.51 The Free Software Foundation Inc. thanks The Nice Computer Company of Australia for loaning Dean Elsner to write the first (Vax) version of as for Project gnu. The proprietors, management and staff of TNCCA thank FSF for distracting the boss while they gotsome work done. Dean Elsner, Jay Fenlason & friends Using as Edited by Cygnus Support Copyright c 1991, 92, 93, 94, 95, 96, 97, 98, 99, 2000, 2001, 2002, 2006, 2007, 2008, 2009 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled \GNU Free Documentation License". i Table of Contents 1 Overview :::::::::::::::::::::::::::::::::::::::: 1 1.1 Structure of this Manual :::::::::::::::::::::::::::::::::::::: 14 1.2 The GNU Assembler :::::::::::::::::::::::::::::::::::::::::: 15 1.3 Object File Formats::::::::::::::::::::::::::::::::::::::::::: 15 1.4 Command Line ::::::::::::::::::::::::::::::::::::::::::::::: 15 1.5 Input Files :::::::::::::::::::::::::::::::::::::::::::::::::::: 16 1.6 Output (Object) File:::::::::::::::::::::::::::::::::::::::::: 16 1.7 Error and Warning Messages :::::::::::::::::::::::::::::::::: 16 2 Command-Line Options::::::::::::::::::::::: 19 2.1 Enable Listings: `-a[cdghlns]'
    [Show full text]
  • Advanced Embedded Systems
    Advanced Embedded Systems | Punit Narang | Manoj Gulati | Sourabh Sankule | P a g e | i Contents Chapter 1 - Introduction to Embedded Electronics ........................................................................... 1 1.1 Embedded System .................................................................................................................. 1 1.1.1 Example of Embedded System ........................................................................................ 2 1.1.2 Characteristics ................................................................................................................. 3 1.1.3 User interface .................................................................................................................. 3 1.1.4 Processors in embedded systems ................................................................................... 4 1.1.5 Peripherals ...................................................................................................................... 4 1.2 Microcontrollers...................................................................................................................... 4 1.2.1 What is a Microcontroller? ............................................................................................. 4 1.2.2 Microcontrollers vs. Microprocessors ............................................................................ 5 1.2.3 Development/Classification of microcontrollers (Invisible) ........................................... 5 1.2.4 Development of microprocessors
    [Show full text]
  • The Definitive Guide to GCC Second Edition
    The Definitive Guide to GCC Second Edition ■■■ William von Hagen The Definitive Guide to GCC, Second Edition Copyright © 2006 by William von Hagen All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and the publisher. ISBN-13 (pbk): 978-1-59059-585-5 ISBN-10 (pbk): 1-59059-585-8 Printed and bound in the United States of America 9 8 7 6 5 4 3 2 1 Trademarked names may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, we use the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. Lead Editors: Jason Gilmore, Keir Thomas Technical Reviewer: Gene Sally Editorial Board: Steve Anglin, Ewan Buckingham, Gary Cornell, Jason Gilmore, Jonathan Gennick, Jonathan Hassell, James Huddleston, Chris Mills, Matthew Moodie, Dominic Shakeshaft, Jim Sumser, Keir Thomas, Matt Wade Project Manager: Richard Dal Porto Copy Edit Manager: Nicole LeClerc Copy Editor: Jennifer Whipple Assistant Production Director: Kari Brooks-Copony Production Editor: Katie Stence Compositor: Susan Glinert Proofreader: Elizabeth Berry Indexer: Toma Mulligan Artist: April Milne Cover Designer: Kurt Krames Manufacturing Director: Tom Debolski Distributed to the book trade worldwide by Springer-Verlag New York, Inc., 233 Spring Street, 6th Floor, New York, NY 10013. Phone 1-800-SPRINGER, fax 201-348-4505, e-mail [email protected], or visit http://www.springeronline.com.
    [Show full text]
  • Gnu Assembler
    Using as The gnu Assembler January 1994 The Free Software Foundation Inc. thanks The Nice Computer Company of Australia for loaning Dean Elsner to write the first (Vax) version of as for Project gnu. The proprietors, management and staff of TNCCA thank FSF for distracting the boss while they got some work done. Dean Elsner, Jay Fenlason & friends Using as Edited by Cygnus Support Copyright c 1991, 92, 93, 94, 95, 96, 97, 1998 Free Software Foundation, Inc. Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the con- ditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another lan- guage, under the above conditions for modified versions. Chapter 1: Overview 1 1 Overview This manual is a user guide to the gnu assembler as. Here is a brief summary of how to invoke as. For details, see Chapter 2 [Comand-Line Options], page 9. as [ -a[cdhlns][=file] ] [ -D ] [ --defsym sym=val ] [ -f ] [ --gstabs ] [ --help ] [ -I dir ] [ -J ] [ -K ] [ -L ] [ --keep-locals ] [ -o objfile ] [ -R ] [ --statistics ] [ -v ] [ -version ] [ --version ] [ -W ] [ -w ] [ -x ] [ -Z ] [ -mbig-endian | -mlittle-endian ] [ -m[arm]1 | -m[arm]2 | -m[arm]250 | -m[arm]3 | -m[arm]6 | -m[arm]7[t][[d]m[i]] ] [ -m[arm]v2 | -m[arm]v2a | -m[arm]v3 | -m[arm]v3m | -m[arm]v4 | -m[arm]v4t ] [ -mthumb | -mall ] [ -mfpa10 | -mfpa11 | -mfpe-old | -mno-fpu ] [ -EB | -EL ] [ -mapcs-32 | -mapcs-26 ] [ -O ] [ -Av6 | -Av7 | -Av8 | -Asparclet | -Asparclite -Av8plus | -Av8plusa | -Av9 | -Av9a ] [ -xarch=v8plus | -xarch=v8plusa ] [ -bump ] [ -32 | -64 ] [ -ACA | -ACA_A | -ACB | -ACC | -AKA | -AKB | -AKC | -AMC ] [ -b ] [ -no-relax ] [ -l ] [ -m68000 | -m68010 | -m68020 | ..
    [Show full text]
  • LCSH Section Numerals
    0 (Group of artists) 1c Magenta (Stamp) 2e children USE Zero (Group of artists) USE British Guiana One-Cent Magenta (Stamp) USE Twice-exceptional children 0⁰ latitude 1I (Interstellar object) 2nd Avenue (Manhattan, New York, N.Y.) USE Equator USE ʻOumuamua (Interstellar object) USE Second Avenue (Manhattan, New York, N.Y.) 0⁰ meridian 1I/2017 U1 (Interstellar object) 2nd Avenue (Seattle, Wash.) USE Prime Meridian USE ʻOumuamua (Interstellar object) USE Second Avenue (Seattle, Wash.) 0-1 Bird Dog (Reconnaissance aircraft) 1I/ʻOumuamua (Interstellar object) 2nd Avenue West (Seattle, Wash.) USE Bird Dog (Reconnaissance aircraft) USE ʻOumuamua (Interstellar object) USE Second Avenue West (Seattle, Wash.) 0th law of thermodynamics 1P/ Halley (Comet) 2nd law of thermodynamics USE Zeroth law of thermodynamics USE Halley's comet USE Second law of thermodynamics 1,000 Year Monument (Novgorod, Russia) 1st Avenue (Seattle, Wash.) 2P/Encke (Comet) USE Tysi︠a︡cheletie Rossii (Novgorod, Russia) USE First Avenue (Seattle, Wash.) USE Encke comet 1,4-beta-D-glucan cellobiohydrolase 1st Avenue West (Seattle, Wash.) 2U 2030+40 (Astronomy) USE Cellulose 1,4-beta-cellobiosidase USE First Avenue West (Seattle, Wash.) USE Cygnus X-3 1 1/2 Strutter (Military aircraft) 1st century, A.D. 3-(1-piperazino)benzotrifluoride USE Sopwith 1 1/2 Strutter (Military aircraft) USE First century, A.D. USE Trifluoromethylphenylpiperazine 1-2 Montague Place (London, England) 1st Hill Park (Seattle, Wash.) 3.1 Tongnip Sŏnŏn Kinyŏmtʻap (Seoul, Korea) BT Office buildings—England
    [Show full text]
  • Xenix and the Motorola 68000 Family
    Xenix and the Motorola 68000 family Bill Bateson looks at Xenix and Xenix 68000 The main features of the Xenix time-sharing system are Bill Bateson is a systems discussed, paying particular attention to those aspects programmer in the software of the operating system which relate most closely to products group of UK firm the hardware on which the system is running. In Logica. He started his career particular the architecture of the CPU, the memory in the computing industry management hardware, and the disc system are in 1979 with SPL Inter- discussed. national working on reactor microsystems Unix memory management simulation programs for the UK Atomic Energy Authority. Bateson is a graduate of Bristol University, WHAT IS XENIX? UK, with a degree in math- ematics and computing science. He is currently Xenix family tree engaged in adapting Xenix to run on various 68000- based microsystems. Xenix is an enhanced version of the Unix time-sharing system, and its relationship to Unix can best be illus- trated by means of a family tree (Figure 1). structure. They contain the information necessary to Unix itself was first written and implemented by Ken map the names of the files immediately below them Thompson (of Bell Labs) on DEC PDP 7 in 1969. His onto the files themselves. This information is in the motivation to write the system was a general dissatis- form of a simple pointer which says where to find faction with the available computer facilities. With the disc block(s) belonging to the file. Because it is Unix, he aimed to produce a system that provided a simply a pointer, an identical copy of the pointer can powerful development environment for programmers appear in another directory, which gives rise to the geared towards interactive use.
    [Show full text]