DOCSLIB.ORG

Ethernet for the ATLAS Second Level Trigger

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Ethernet for the ATLAS Second Level Trigger Ethernet for the ATLAS Second Level Trigger by Franklin Saka Royal Holloway College, Physics Department University of London 2001 Thesis submitted in accordance with the requirements of the University of London for the degree of Doctor of Philosophy Abstract In preparation for building the ATLAS second level trigger, various networks and protocols are being investigated. Advancement in Ethernet LAN technology has seen the speed increase from 10 Mbit/s to 100 Mbit/s and 1 Gigabit/s. There are organisations looking at taking Ethernet speeds even higher to 10 Gigabit/s. The price of 100 Mbit/s Ethernet has fallen rapidly since its introduction. Gigabit Ethernet prices are also following the same pattern as products are taken up by customers wishing to stay with the Ethernet technology but requiring higher speeds to run the latest applications. The price/performance/longevity and universality features of Ethernet has made it an interesting technology for the ATLAS second level trigger network. The aim of this work is to assess the technology in the context of the ATLAS trigger and data acquisition system. We investigate the technology and its implications. We assess the performance of contemporary, commodity, off-the-shelf Ethernet switches/networks and interconnects. The results of the performance analysis are used to build switch models such that large ATLAS-like networks can be simulated and studied. Finally, we then look at the feasibility and prospect for Ethernet in the ATLAS second level trigger based on current products and estimates of the state of the technology in 2005, when ATLAS is scheduled to come on line. 2 Acknowledgements I would like to thank my supervisors, John Strong and Bob Dobinson for the opportunity to carry out the work presented in this thesis, for their guidance and advice. I would also like to thank the members of the ATLAS community, Marcel Boosten, Krzysztof Korcyl, Stefan Haas, David Thornley, Roger Heely, Marc Dobson, Brian Martin and other past and present members of Bob Dobinson’s group at CERN with whom I was lucky enough to work. I am also grateful to: PPARC for funding this PhD; my industrial sponsors SGS-Thompson, in particular those I worked with (Gajinder Panesar and Neil Richards) for their help and friendship; CERN and the ESPRIT projects ARCHES (project no. 20693) and SWIFT. I would like express my appreciation to: Antonia Dura “bueno paella” Martinez who was there through the sleepless nights (Gracias por haber tenido paciencia); to Celestino “Celestial Casanova” Canosa, we did it Tino! Thanks also to Stefano “Teti” Caruso, Gabriela Susana “Chia- pas chica” Garcia, Teresa “belle potosina” Segovia, Micheal “you guys” Pragassen, Uma “Bala... umski” Shanker, and Roy “jock strap” Gomez and all my other dear friends for making the journey more interesting. Finally, to Ophelia, Sheila, Kelvin, Adil and the rest of my family, thank you for your contin- ued encouragements and support. To David, Maxwell, Rachel and Natalie, I hope you will achieve an equivalent and more in the years to come. This one is dedicated to my mother Evelyn who saw it all from the start. Cheers mum. 3 4 Contents 1 Introduction 11 1.1 Physics background . 12 1.2 The ATLAS Trigger/DAQ system . 12 1.3 The level-2 trigger . 15 1.4 Thesis Aim . 16 1.5 Thesis Outline . 16 1.6 Context . 17 1.7 Contribution . 17 2 Requirements for the ATLAS second level trigger 19 2.1 General Requirements . 20 3 A Review of the Ethernet technology 25 3.1 Introduction . 26 3.2 History of Ethernet . 26 3.3 The Ethernet technology . 27 3.3.1 Relation to OSI reference model . 28 3.3.2 Frame format . 29 3.3.3 Broadcast and multicast . 31 3.3.4 The CSMA/CD protocol . 31 3.3.5 Full and Half duplex . 32 3.3.6 Flow control . 32 3.3.7 Current transmission rates . 33 3.4 Connecting multiple Ethernet segments . 34 3.4.1 Routers . 34 5 3.4.2 Repeaters and hubs . 35 3.4.3 Switches and bridges . 35 3.5 The Ethernet switch Standards . 36 3.5.1 The Bridge Standard . 36 3.5.2 Virtual LANs (VLANs) . 37 3.5.3 Quality of service (QoS) . 38 3.5.4 Trunking . 39 3.5.5 Higher layer switching . 39 3.5.6 Switch management . 39 3.6 Reasons for Ethernet . 40 3.7 Conclusion . 41 4 Network interfacing Performance issues 43 4.1 Introduction . 44 4.2 The measurement setup . 45 4.3 The comms 1 measurement procedures . 46 4.4 TCP/IP protocol . 47 4.4.1 A brief introduction to TCP/IP . 47 4.4.2 Results with the default setup using Fast Ethernet . 50 4.4.3 Delayed acknowledgement disabled . 55 4.4.4 Nagle algorithm and delayed acknowledgement disabled . 55 4.4.5 A parameterised model of TCP/IP comms 1 communication . 56 4.4.6 Effects of the socket size on the end-to-end latency . 61 4.4.7 Results of CPU usage of comms 1 with TCP . 62 4.4.8 Raw Ethernet . 66 4.4.9 A parameterised model of the CPU load . 67 4.4.10 Conclusions for ATLAS . 67 4.4.11 Gigabit Ethernet compared with Fast Ethernet . 68 4.4.12 Effects of the processor speed . 71 4.5 TCP/IP and ATLAS . 72 4.5.1 Decision Latency . 72 4.5.2 Request-response rate and CPU load . 73 4.5.3 Conclusion for ATLAS . 75 6 4.6 MESH . 76 4.6.1 MESH comms 1 performance . 76 4.6.2 Scalability in MESH . 79 4.7 Conclusion . 81 4.8 Further work . 81 5 Ethernet Network topologies and possible enhancements for ATLAS 83 5.1 Introduction . 84 5.2 Scalable networks with standard Ethernet . 84 5.3 Constructing arbitrary network architectures with Ethernet . 87 5.3.1 The Spanning Tree Algorithm . 87 5.3.2 Learning and the Forwarding table . 88 5.3.3 Broadcast and Multicast for arbitrary networks . 89 5.3.4 Path Redundancy . 92 5.4 Outlook . 93 5.5 Conclusions . 94 6 The Ethernet testbed measurement software and clock synchronisation 97 6.1 Introduction . 98 6.2 Goals . 98 6.2.1 An example measurement . 99 6.3 Design decisions . 100 6.3.1 Testbed setup . 100 6.3.2 The Traffic Generator program . 101 6.3.3 The usage of MESH in the ETB software . 101 6.4 synchronising PC clocks . 104 6.4.1 Method . 104 6.4.2 Factors affecting synchronisation accuracy . 105 6.4.3 Clock drift and skew . 106 6.4.4 Temperature dependency on the synchronisation . 109 6.4.5 Integrating clock synchronisation and measurements . 110 6.4.6 Conditions for best synchronisation . 110 6.4.7 Summary of clock accuracy . 112 7 6.5 Measurements procedure . 114 6.5.1 Configuration files . 114 6.5.2 The transmitter and receiver . 117 6.6 Considerations in using ETB . 122 6.7 Possible improvements . 123 6.8 Strengths and limitations of ETB . 123 6.9 Commercial testers . 124 6.10 Price Comparison . 125 6.11 Conclusions . 126 7 Analysis of testbed measurements 127 7.1 Introduction . 128 7.2 Contemporary Ethernet switch architectures . 128 7.2.1 Operating modes . 129 7.2.2 Switching Fabrics . ..
Load more

Recommended publications
  • Redes De Computadores (RCOMP)
    Redes de Computadores (RCOMP) Lecture 03 2019/2020 • Ethernet local area network technologies. • Virtual local area networks (VLAN). • Wireless local area networks. Instituto Superior de Engenharia do Porto – Departamento de Engenharia Informática – Redes de Computadores (RCOMP) – André Moreira 1 ETHERNET Networks – CSMA/CD Ethernet networks (IEEE 802.3 / ISO 8802-3) were originally developed by Xerox in the 70s. Nowadays, ethernet is undoubtedly the most widely used technology in wired LANs. Originally, access control to the medium (MAC - Medium Access Control) was a key issue. The CSMA/CD technique used in ethernet is not ideal, it doesn’t avoid collisions and, as such, results in low efficiency under heavy traffic. The early Ethernet networks were based on a coaxial cable to which all nodes were connected (bus topology), the most important variants were: Thick Ethernet - 10base5 - 10 Mbps / Digital Signal(1) / maximum 500 m bus length Thin Ethernet - 10base2 - 10 Mbps / Digital Signal(1) / maximum 180 m bus length Node Node Node Node Node Node Node Node Node Node (1) base stands for a baseband transmission medium, therefore digital signals must be used. Instituto Superior de Engenharia do Porto – Departamento de Engenharia Informática – Redes de Computadores (RCOMP) – André Moreira 2 ETHERNET networks – Collision Domain CSMA/CD (Carrier Sense Multiple Access with Collision Detection) requires packet collisions to be detected by all nodes before the emission of the packet ends. This introduces limitations on the relationship between the packet’s transmission time and the signal propagation delay. To ensure collision detection by all nodes, there’s minimum packet size of 64 bytes (this sets a minimum transmission time), also there is a maximum segment size (sets the maximum propagation delay).
    [Show full text]
  • MTU and MSS Tutorial
    MTU and MSS Tutorial Dr. E. Garcia, [email protected] Published: November 16, 2009. Last Update: November 16, 2009. © 2009 E. Garcia Abstract – This tutorial covers maximum transmission unit ( MTU ), maximum segment size ( MSS ), PING, NETSTAT, and fragmentation. Expressions relevant to these concepts are systematically derived and explained. Keywords: maximum transmission unit, MTU , maximum segment size, MSS , PING, NETSTAT 1 MTU and MSS As discussed in the IP Packet Fragmentation Tutorial (http://www.miislita.com/internet-engineering/ip-packet-fragmentation-tutorial.pdf ) and elsewhere (1 - 3), the data payload ( DP ) of an IP packet is defined as the packet length ( PL ) minus the length of its IP header ( IPHL ), (Eq 1) whereܦܲ theൌ maximum ܲܮ െ ܫܲܪܮ PL is defined as the Maximum Transmission Unit (MTU) . This is the largest IP packet that can be transmitted without further fragmentation. Thus, when PL = MTU (Eq 2) However,ܦܲ ൌ an ܯܷܶ IP packet െ ܫܲܪܮ encapsulates a TCP packet such that DP = TCPHL + MSS (Eq 3) where TCPHL is the length of the TCP header and MSS is the data payload of the TCP packet, also known as the Maximum Segment Size (MSS) . Combining Equations 2 and 3 leads to MSS = MTU – IPHL – TCPHL (Eq 4) Figure 1 illustrates the connection between MTU and MSS –for an IP packet decomposed into three fragments. Figure 1. Fragmentation example where MTU = PL = pl 1 = pl 2 > pl 3 and DP = dp 1 + dp 2 + dp 3 = PL – IPHL . © 2009 E. Garcia 1 Typically, IP and TCP headers are 20 bytes long. Thus, MSS = MTU – 40 (Eq 5) If IP or TCP options are specified, the MSS is further reduced by the number of bytes taken up by the options (OP), each of which may be one byte or several bytes in size.
    [Show full text]
  • ABSTRACT 1 INTRODUCTION 1.1 Background 1.2 Data Link Requirements Overview
    HIGH-SPEED, LOW-POWER, EXCELLENT EMC: LVDS FOR ON-BOARD DATA HANDLING Dr SM Parkes Applied Computing, University of Dundee, Dundee, DD1 4HN, Scotland, UK Tel: 44 1382 345194, Fax: 44 1382 345509, Email: [email protected] ABSTRACT Since the endorsement of the IEEE 1355 by ESA and major companies involved in the space industry, the technology has The capabilities of remote-sensing instrumentation are been migrated successfully into radiation-tolerant, space- developing rapidly. As a consequence the data rates being qualifiable components. Daimler-Benz Aerospace and TEMIC handled on-board spacecraft are increasing. have developed a component (SMCS) which provides three LVDS (Low Voltage Differential Signaling) provides a means IEEE 1355 compatible links and a processor interface (Ref. 4). of sending data along a twisted pair cable at high speed, with Demonstration systems have been and are being developed for low power and with excellent EMC performance. These both multi-DSP processing systems (Ref. 5) and for large features make LVDS ideal for satellite on-board data-handling capacity, solid-state data storage systems (Ref. 6). High level applications. protocols have been developed to support interprocessor communication (Ref. 7). Software support for the SMCS link This paper assesses the suitability of LVDS for space devices has been provided within the Eonic Virtuoso real-time applications as part of a data-handling system based on IEEE operating system for both the TSC21020 DSP processor and 1355 comparing it against other types of line driver/receiver. the ERC32 SPARC 32-bit processor (Ref. 8). It explains how LVDS can be used together with IEEE 1355 to form the basis for a powerful on-board data handling system, The Digital Interface Circuit Evaluation (DICE) study was which is capable of handling data from current and future, initiated by ESTEC to take stock of these developments, to high data-rate instruments.
    [Show full text]
  • Iethernet W5500 Datasheet Kr
    W5500 Datasheet Version 1.0.6 http://www.wiznet.co.kr © Copyright 2013 WIZnet Co., Ltd. All rights reserved. W5500 The W5500 chip is a Hardwired TCP/IP embedded Ethernet controller that provides easier Internet connection to embedded systems. W5500 enables users to have the Internet connectivity in their applications just by using the single chip in which TCP/IP stack, 10/100 Ethernet MAC and PHY embedded. WIZnet‘s Hardwired TCP/IP is the market-proven technology that supports TCP, UDP, IPv4, ICMP, ARP, IGMP, and PPPoE protocols. W5500 embeds the 32Kbyte internal memory buffer for the Ethernet packet processing. If you use W5500, you can implement the Ethernet application just by adding the simple socket program. It’s faster and easier way rather than using any other Embedded Ethernet solution. Users can use 8 independent hardware sockets simultaneously. SPI (Serial Peripheral Interface) is provided for easy integration with the external MCU. The W5500’s SPI supports 80 MHz speed and new efficient SPI protocol for the high speed network communication. In order to reduce power consumption of the system, W5500 provides WOL (Wake on LAN) and power down mode. Features - Supports Hardwired TCP/IP Protocols : TCP, UDP, ICMP, IPv4, ARP, IGMP, PPPoE - Supports 8 independent sockets simultaneously - Supports Power down mode - Supports Wake on LAN over UDP - Supports High Speed Serial Peripheral Interface(SPI MODE 0, 3) - Internal 32Kbytes Memory for TX/RX Buffers - 10BaseT/100BaseTX Ethernet PHY embedded - Supports Auto Negotiation (Full and half duplex, 10 and 100-based ) - Not supports IP Fragmentation - 3.3V operation with 5V I/O signal tolerance - LED outputs (Full/Half duplex, Link, Speed, Active) - 48 Pin LQFP Lead-Free Package (7x7mm, 0.5mm pitch) 2 / 68 W5500 Datasheet Version1.0.6 (DEC 2014) Target Applications W5500 is suitable for the following embedded applications: - Home Network Devices: Set-Top Boxes, PVRs, Digital Media Adapters - Serial-to-Ethernet: Access Controls, LED displays, Wireless AP relays, etc.
    [Show full text]
  • Modelado Y Validación De Un Sistema Digital De Comunicaciones De Gran Ancho De Banda De Aplicación En Vehículos De Transporte
    UNIVERSIDAD PONTIFICIA COMILLAS DE MADRID ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) (Instituto de Investigación Tecnológica) Modelado y validación de un sistema digital de comunicaciones de gran ancho de banda de aplicación en vehículos de transporte Tesis para la obtención del grado de Doctor Director: Prof. Dr. D. Sadot Alexandres Fernández Autor: Ing. D. Carlos Rodríguez-Morcillo García Madrid 2007 CONSTANCIA REGISTRAL DEL TRIBUNAL DEL ACTO DE LA DEFENSA DE TESIS DOCTORAL TÍTULO: Modelado y validación de un sistema digital de comunicaciones de gran ancho de banda de aplicación en vehículos de transporte AUTOR: D. Carlos Rodríguez-Morcillo García DIRECTOR: Dr. D. Sadot Alexandres Fernández TUTOR-PONENTE: -- DEPARTAMENTO: Instituto de Investigación Tecnológica FACULTAD O ESCUELA: Escuela Técnica Superior de Ingeniería (ICAI) Miembros del Tribunal Calificador: PRESIDENTE: Dr. D. Manuel Mazo Quintas Firma: ................................ VOCAL: Dr. D. José Luís Martín González Firma: ................................ VOCAL: Dr. D. César Sanz Álvaro Firma: ................................ VOCAL: Dr. D. Rafael Palacios Hielscher Firma: ................................ SECRETARIO: Dr. D. José Daniel Muñoz Frías Firma: ................................ Fecha de lectura: 19 de septiembre de 2007 Calificación: ……………………………………………………. A María, a mis padres y a mi hermano. A la memoria de Quique. Resumen En esta Tesis se propone un sistema digital de comunicaciones que per- mite transmitir una gran cantidad de información entre los equipos embar- cados en un vehículo de transporte, aumentando así la capacidad de trans- misión de los sistemas instalados actualmente. Además, el sistema propues- to es capaz de funcionar compartiendo el mismo medio físico que los siste- mas actuales, para minimizar el coste económico y de recursos que supone la instalación de un nuevo sistema en un vehículo ya fabricado.
    [Show full text]
  • Automotive Ethernet: the Definitive Guide
    Automotive Ethernet: The Definitive Guide Charles M. Kozierok Colt Correa Robert B. Boatright Jeffrey Quesnelle Illustrated by Charles M. Kozierok, Betsy Timmer, Matt Holden, Colt Correa & Kyle Irving Cover by Betsy Timmer Designed by Matt Holden Automotive Ethernet: The Definitive Guide. Copyright © 2014 Intrepid Control Systems. 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 publisher. Printed in the USA. ISBN-10: 0-9905388-0-X ISBN-13: 978-0-9905388-0-6 For information on distribution or bulk sales, contact Intrepid Control Systems at (586) 731-7950. You can purchase the paperback or electronic version of this book at www.intrepidcs.com or on Amazon. We’d love to hear your feedback about this book—email us at [email protected]. Product and company names mentioned in this book may be the trademarks of their respective owners. Rather than use a trademark symbol with every occurence of a trademarked name, we are using the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. The information in this book is distributed on an “As Is” basis, without warranty. While every precaution has been taken in the preparation of this book, neither the authors nor Intrepid Control Systems 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 book.
    [Show full text]
  • Practical TCP/IP and Ethernet Networking Titles in the Series
    Practical TCP/IP and Ethernet Networking Titles in the series Practical Cleanrooms: Technologies and Facilities (David Conway) Practical Data Acquisition for Instrumentation and Control Systems (John Park, Steve Mackay) Practical Data Communications for Instrumentation and Control (Steve Mackay, Edwin Wright, John Park) Practical Digital Signal Processing for Engineers and Technicians (Edmund Lai) Practical Electrical Network Automation and Communication Systems (Cobus Strauss) Practical Embedded Controllers (John Park) Practical Fiber Optics (David Bailey, Edwin Wright) Practical Industrial Data Networks: Design, Installation and Troubleshooting (Steve Mackay, Edwin Wright, John Park, Deon Reynders) Practical Industrial Safety, Risk Assessment and Shutdown Systems for Instrumentation and Control (Dave Macdonald) Practical Modern SCADA Protocols: DNP3, 60870.5 and Related Systems (Gordon Clarke, Deon Reynders) Practical Radio Engineering and Telemetry for Industry (David Bailey) Practical SCADA for Industry (David Bailey, Edwin Wright) Practical TCP/IP and Ethernet Networking (Deon Reynders, Edwin Wright) Practical Variable Speed Drives and Power Electronics (Malcolm Barnes) Practical TCP/IP and Ethernet Networking Deon Reynders Pr Eng, BSc BEng, BSc Eng (Elec)(Hons), MBA Edwin Wright MIPENZ, BSc(Hons), BSc(Elec Eng), IDC Technologies, Perth, Australia . Newnes An imprint of Elsevier Linacre House, Jordan Hill, Oxford OX2 8DP 200 Wheeler Road, Burlington, MA 01803 First published 2003 Copyright 2003, IDC Technologies. All rights reserved No part of this publication may be reproduced in any material form (including photocopying or storing in any medium by electronic means and whether or not transiently or incidentally to some other use of this publication) without the written permission of the copyright holder except in accordance with the provisions of the Copyright, Designs and Patents Act 1988 or under the terms of a licence issued by the Copyright Licensing Agency Ltd, 90 Tottenham Court Road, London, England W1T 4LP.
    [Show full text]
  • Spacewire Handbook
    SpaceWire Handbook DRAFT - SVN version 45 - September 24, 2012 4Links Limited Suite E U 2 BletchleyPark Milton Keynes, MK3 6EB United Kingdom Copyright © 2012 4Links Limited. SpaceWire Handbook DRAFT - SVN version 45 - September 24, 2012 Foreword This Draft Handbook is 4Links Limited’sinitial contribution to the forthcoming ECSS SpaceWire Handbook. Change Log Date Version 2012/06/29 First draft issue 2012/09/24 Second draft issue Copyright © 2012 4Links Limited. 2 SpaceWire Handbook DRAFT - SVN version 45 - September 24, 2012 Table of Contents Title Page ......................... 1 Foreword . ........................ 2 Change Log ........................ 2 1. Introduction ....................... 6 1.1. Purpose ....................... 6 1.2. Scope ........................ 6 1.3. Acknowledgements . ................... 6 1.4. Document structure . ................... 7 2. Terms, definitions and abbreviations ............... 8 2.1. Terms and definitions from other documents ............ 8 2.2. Terms specific to the present handbook ............. 8 2.2.1. SpaceWire End-Point .................. 8 2.2.2. SpaceWire Node ................... 8 2.2.3. SpaceWire Unit ................... 8 2.3. Abbreviated terms .................... 8 3. References ........................ 9 4. Introduction to SpaceWire .................. 10 4.1. Background and History .................. 10 4.1.1. 1960 -AModular Computer ............... 10 4.1.2. 1980 -System on Chip, Serial Interfaces . ........... 11 4.1.3. Transputer serial links in space ............... 11 4.1.4. Modularity ..................... 12 4.1.5. 1990+ Transputer links to IEEE-1355 ............ 12 4.1.6. IEEE-1355 and early SpaceWire in Space ........... 13 4.2. The current SpaceWire Standard ................ 13 4.2.1. Data-Strobe encoding . ................. 14 4.2.2. Low-levelflow-control . ................ 15 4.2.3. Packets . ..................... 15 4.2.4. Packet Routing .................... 15 4.2.5.
    [Show full text]
  • Computer Networking Exercises
    Computer Networking Exercises Antonio Carzaniga Faculty of Informatics USI (Università della Svizzera italiana) Edition 2.4 April 2020 1 ◮Exercise 1. Consider a DNS query of type A within a DNS system containing IN class information. Using boxes to represent servers and lines with labels to represent packets, diagram an iterative request for “www.ban.mcyds.net”. The answer must be authoritative. Label any DNS servers you need to contact using a descriptive label. Label every packet with the essential information. For example, a box may be labeled “authority for .com,” while a packet might be labeled “answer, www.ban.mcyds.net, 192.168.23.45” (10’) Consider the same DNS request specified above. Now create a new diagram showing a recursive request. Once again, the answer must be authoritative. (10’) ◮Exercise 2. Given the utility functions listed below, write the pseudo-code to perform an iterative DNS lookup. dns_query_pkt make_dns_packet(type, class, flags) Creates a new DNS query packet. Flags can be combined via the ‘|’ operator. So for a query that is both authoritative and recursive, one would write: (DNS_AUTH | DNS_RECURSE). Only the DNS_AUTH and DNS_RECURSE flags are valid. Type can be A, MX, NS, or any other valid DNS type. value get_dns_answer(dns_answer_packet, n) Return the value in the nth answer of a dns_answer_pkt packet. For example, in re- ply to a MX lookup for inf.unisi.ch, get_dns_answer(pkt,1) would return the SMTP mail server for the inf.unisi.ch domain. In reply to a NS query it would return the authoritative name server. dns_answer_packet send_and_wait(dns_query_packet, server) Send the given dns_query_packet and wait for a replay from the given DNS server.
    [Show full text]
  • The IEEE 1355 Standard: Developments, Performance and Application in High Energy Physics
    The IEEE 1355 Standard: Developments, Performance and Application in High Energy Physics Thesis submitted in accordance with the requirements of the University of Liverpool for the degree of Doctor of Philosophy by Stefan Haas December 1998 The IEEE 1355 Standard: Developments, Performance and Applications in High Energy Physics Stefan Haas The data acquisition systems of the next generation High Energy Physics experiments at the Large Hadron Collider (LHC) at CERN will rely on high-speed point-to-point links and switching networks for their higher level trigger and event building systems. This thesis pro- vides a detailed evaluation of the DS-Link and switch technology, which is based on the IEEE 1355 standard for Heterogeneous InterConnect (HIC). The DS-Link is a bidirectional point-to-point serial interconnect, operating at speeds up to 200 MBaud. The objective of this thesis was to study the performance of the IEEE 1355 link and switch technology and to dem- onstrate that switching networks using this technology would scale to meet the requirements of the High Energy Physics applications. The performance and reliability of the basic point-to-point interconnect technology over elec- trical and fibre optic media were examined. These studies were carried out while the IEEE 1355 standard was still being finalised and have therefore provided valuable input to the standards working group. In order to validate the fibre optic physical layer proposed for the IEEE 1355 standard, an implementation demonstrator of a DS-Link interface for fibre optics, employing a new line encoding scheme, has been designed and characterised. This interface allows the link length for DS-links to be extended, which is important in the HEP context, where the cable length from the detector to the electronics can be up to 200 meters.
    [Show full text]
  • Dynamic Jumbo Frame Generation for Network Performance Scalability
    1 JumboGen: Dynamic Jumbo Frame Generation For Network Performance Scalability David Salyers, Yingxin Jiang, Aaron Striegel, Christian Poellabauer Department of Computer Science and Engineering University of Notre Dame Notre Dame, IN. 46530 USA Email: {dsalyers, yjiang3, striegel, cpoellab}@nd.edu Abstract— Network transmission speeds are increasing at a there is a fixed amount of overhead processing per packet, significant rate. Unfortunately, the actual performance of the it is a challenge for CPUs to scale with increasing network network does not scale with the increases in line speed. This speeds [2]. In order to overcome this issue, many works on is due to the fact that the majority of packets are less than or equal to 64 bytes and the fact that packet size has not scaled with high performance networks, as in [3] and [4], have advocated the increases in network line speeds. This causes a greater and the use of a larger MTU length or jumbo frames. These works greater load to be placed on routers in the network as routing show that the performance of TCP and the network in general decisions have to be made for an ever increasing number of can significantly improve with the use of jumbo-sized packets. packets, which can cause increased packet delay and loss. In Unfortunately, the benefits of jumbo frames are limited for order to help alleviate this problem and make the transfer of bulk data more efficient, networks can support an extra large several reasons. First, the majority of packets transferred are MTU size. Unfortunately, when a packet traverses a number of 64 bytes or less.
    [Show full text]
  • Exploring Usable Path MTU in the Internet
    Exploring usable Path MTU in the Internet Ana Custura Gorry Fairhurst Iain Learmonth University of Aberdeen University of Aberdeen University of Aberdeen Abstract—To optimise their transmission, Internet endpoints methodologies and tools [7] [8], providing an up-to-date need to know the largest size of packet they can send across PMTUD behaviour report for both IPv4 and IPv6. a specific Internet path, the Path Maximum Transmission Unit We include an in-depth exploration of server and client (PMTU). This paper explores the PMTU size experienced across the Internet core, wired and mobile edge networks. advertised Maximum Segment Size (MSS), taking advantage Our results show that MSS Clamping has been widely deployed of existing measurement platforms, MONROE [9] and RIPE in edge networks, and some webservers artificially reduce their Atlas [10], and using or extending existing tools Netalyzr [11] advertised MSS, both of which we expect help avoid PMTUD and PATHspider [12]. failure for TCP. The maximum packet size used by a TCP We also look at ICMP quotation health and analyze a connection is also constrained by the acMSS. MSS Clamping was observed in over 20% of edge networks tested. We find a large number of ICMP quotations from a previous large- significant proportion of webservers that advertise a low MSS scale measurement campaign. These results provide important can still be reached with a 1500 byte packet. We also find more insight to inform the design of new methods that can robustly than half of IPv6 webservers do not attempt PMTUD and clamp discover the PMTU for UDP traffic where there are currently the MSS to 1280 bytes.
    [Show full text]