DOCSLIB.ORG

Low-Power High Performance Computing

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Low-Power High Performance Computing Panagiotis Kritikakos August 16, 2011 MSc in High Performance Computing The University of Edinburgh Year of Presentation: 2011 Abstract The emerging development of computer systems to be used for HPC require a change in the architecture for processors. New design approaches and technologies need to be embraced by the HPC community for making a case for new approaches in system design for making it possible to be used for Exascale Supercomputers within the next two decades, as well as to reduce the CO2 emissions of supercomputers and scientific clusters, leading to greener computing. Power is listed as one of the most important issues and constraint for future Exascale systems. In this project we build a hybrid cluster, investigating, measuring and evaluating the performance of low-power CPUs, such as Intel Atom and ARM (Marvell 88F6281) against commodity Intel Xeon CPU that can be found within standard HPC and data-center clusters. Three main factors are considered: computational performance and efficiency, power efficiency and porting effort. Contents 1 Introduction 1 1.1 Report organisation . 2 2 Background 3 2.1 RISC versus CISC . 3 2.2 HPC Architectures . 4 2.2.1 System architectures . 4 2.2.2 Memory architectures . 5 2.3 Power issues in modern HPC systems . 9 2.4 Energy and application efficiency . 10 3 Literature review 12 3.1 Green500 . 12 3.2 Supercomputing in Small Spaces (SSS) . 12 3.3 The AppleTV Cluster . 13 3.4 Sony Playstation 3 Cluster . 13 3.5 Microsoft XBox Cluster . 14 3.6 IBM BlueGene/Q . 14 3.7 Less Watts . 14 3.8 Energy-efficient cooling . 14 3.8.1 Green Revolution Cooling . 15 3.8.2 Google Data Centres . 15 3.8.3 Nordic Research . 16 3.9 Exascale . 17 4 Technology review 19 4.1 Low-power Architectures . 19 4.1.1 ARM . 19 4.1.2 Atom . 21 4.1.3 PowerPC and Power . 22 4.1.4 MIPS . 23 5 Benchmarking, power measurement and experimentation 25 5.1 Benchmark suites . 25 5.1.1 HPCC Benchmark Suite . 25 i 5.1.2 NPB Benchmark Suite . 25 5.1.3 SPEC Benchmarks . 26 5.1.4 EEMBC Benchmarks . 26 5.2 Benchmarks . 27 5.2.1 HPL . 27 5.2.2 STREAM . 27 5.2.3 CoreMark . 27 5.3 Power measurement . 28 5.3.1 Metrics . 29 5.3.2 Measuring unit power . 29 5.3.3 The measurement procedure . 29 5.4 Experiments design and execution . 30 5.5 Validation and reproducibility . 31 6 Cluster design and deployment 33 6.1 Architecture support . 33 6.1.1 Hardware considerations . 33 6.1.2 Software considerations . 34 6.1.3 Soft Float vs Hard Float . 34 6.2 Fortran . 35 6.3 C/C++ . 35 6.4 Java . 35 6.5 Hardware decisions . 36 6.6 Software decisions . 36 6.7 Networking . 39 6.8 Porting . 40 6.8.1 Fortran to C . 40 6.8.2 Binary incompatibility . 40 6.8.3 Scripts developed . 41 7 Results and analysis 42 7.1 Thermal Design Power . 42 7.2 Idle readings . 43 7.3 Benchmark results . 44 7.3.1 Serial performance: CoreMark . 44 7.3.2 Parallel performance: HPL . 50 7.3.3 Memory performance: STREAM . 58 7.3.4 HDD and SSD power consumption . 61 8 Future work 63 9 Conclusions 64 A CoreMark results 66 ii B HPL results 67 C STREAM results 69 D Shell Scripts 70 D.1 add_node.sh . 70 D.2 status.sh . 71 D.3 armrun.sh . 71 D.4 watt_log.sh . 71 D.5 fortran2c.sh . 72 E Benchmark outputs samples 73 E.1 CoreMark output sample . 73 E.2 HPL output sample . 73 E.3 STREAM output sample . 75 F Project evaluation 76 F.1 Goals . 76 F.2 Work paln . 76 F.3 Risks . 77 F.4 Changes . 77 G Final Project Proposal 78 G.1 Content . 78 G.2 The work to be undertaken . 78 G.2.1 Deliverables . 78 G.3 Tasks . 79 G.4 Additional information / Knowledge required . 79 iii List of Tables 6.1 Cluster nodes hardware specifications . 36 6.2 Cluster nodes software specifications . 37 6.3 Network configuration . 39 7.1 Maximum TDP per processor. 42 7.2 Average system power consumption on idle. 43 7.3 CoreMark results with 1 million iterations. 44 7.4 HPL problem sizes. 51 7.5 HPL problem sizes. 51 7.6 STREAM results for 500MB array size. 58 A.1 CoreMark results for various iterations. 66 B.1 HPL problem sizes. 67 B.2 HPL problem sizes. 68 B.3 HPL results for N=500. 68 C.1 STREAM results for size array of 500MB. 69 iv List of Figures 2.1 Single Instruction Single Data (Reproduced from Blaise Barney, LLNL). .................................. 5 2.2 Single Instruction Multiple Data (Reproduced from Blaise Barney, LLNL). .................................. 6 2.3 Multiple Instruction Single Data (Reproduced from Blaise Barney, LLNL). .................................. 6 2.4 Multiple Instruction Multiple Data (Reproduced from Blaise Bar- ney, LLNL). ............................... 6 2.5 Distributed memory architecture (Reproduced from Blaise Barney, LLNL). .................................. 7 2.6 Shared Memory UMA architecture (Reproduced from Blaise Bar- ney, LLNL). ............................... 8 2.7 Shared Memory NUMA architecture (Reproduced from Blaise Bar- ney, LLNL). ............................... 8 2.8 Hybrid Distributed-Shared Memory architecture (Reproduced from Blaise Barney, LLNL). .......................... 8 2.9 Moore’s law for power consumption (Reproduced from W-chun Feng, LANL). ............................... 10 3.1 GRCooling four-rack CarnotJetTM system at Midas Networks (source GRCooling) . ............................... 15 3.2 Google data-centre at Finland, next to the Finnish gulf (source Google). 16 3.3 NATO ammunition depot at Rennesøy, Norway (source Green Moun- tain Data Centre AS). .......................... 17 3.4 Projected power demand of a supercomputer (M. Kogge) . 18 4.1 OpenRD board SoC with ARM (Marvell 88F6281) (Cantanko). 20 4.2 Intel D525 Board with Intel Atom dual-core. 21 4.3 IBM’s BlueGene/Q 16-core compute node (Timothy Prickett Mor- gan, The Register). ............................ 22 4.4 Pipelined MIPS, showing the five stages (instruction fetch, instruc- tion decode, execute, memory access and write back (Wikimedia Commons). ................................ 23 4.5 Motherboard with Loongson 2G processor (Wikimedia Commons). 24 v 5.1 Power measurement setup. ....................... 29 6.1 The seven-node cluster that was built as part of this project. 38 6.2 Cluster connectivity ........................... 39 7.1 Power readings over time. ........................ 43 7.2 CoreMark results for 1 million iterations. 45 7.3 CoreMark results for 1 thousand iterations. 46 7.4 CoreMark results for 2 million iterations. 46 7.5 CoreMark results for 1 million iterations utilising 1 thread per core. 47 7.6 CoreMark performance for 1, 2, 4, 6 and 8 cores per system. 48 7.7 CoreMark performance speedup per system. 49 7.8 CoreMark performance on Intel Xeon. 49 7.9 Power consumption over time while executing CoreMark. 50 7.10 HPL results for large problem size, calculated with ACT’s script. 52 7.11 HPL results for problem size 80% of the system memory. 52 7.12 HPL results for N=500. ......................... 53 7.13 HPL total power consumption for N equal to 80% of memory. 54 7.14 HPL total power consumption for N calculated with ACT’s script. 55 7.15 HPL total power consumption for N=7296. 56 7.16 HPL total power consumption for N=500. 56 7.17 Power consumption over time while executing HPL. ..
Recommended publications
  • Wind River Vxworks Platforms 3.8

    Wind River Vxworks Platforms 3.8

    Wind River VxWorks Platforms 3.8 The market for secure, intelligent, Table of Contents Build System ................................ 24 connected devices is constantly expand- Command-Line Project Platforms Available in ing. Embedded devices are becoming and Build System .......................... 24 VxWorks Edition .................................2 more complex to meet market demands. Workbench Debugger .................. 24 New in VxWorks Platforms 3.8 ............2 Internet connectivity allows new levels of VxWorks Simulator ....................... 24 remote management but also calls for VxWorks Platforms Features ...............3 Workbench VxWorks Source increased levels of security. VxWorks Real-Time Operating Build Configuration ...................... 25 System ...........................................3 More powerful processors are being VxWorks 6.x Kernel Compatibility .............................3 considered to drive intelligence and Configurator ................................. 25 higher functionality into devices. Because State-of-the-Art Memory Host Shell ..................................... 25 Protection ..................................3 real-time and performance requirements Kernel Shell .................................. 25 are nonnegotiable, manufacturers are VxBus Framework ......................4 Run-Time Analysis Tools ............... 26 cautious about incorporating new Core Dump File Generation technologies into proven systems. To and Analysis ...............................4 System Viewer ........................
  • Accelerating HPL Using the Intel Xeon Phi 7120P Coprocessors

    Accelerating HPL Using the Intel Xeon Phi 7120P Coprocessors

    Accelerating HPL using the Intel Xeon Phi 7120P Coprocessors Authors: Saeed Iqbal and Deepthi Cherlopalle The Intel Xeon Phi Series can be used to accelerate HPC applications in the C4130. The highly parallel architecture on Phi Coprocessors can boost the parallel applications. These coprocessors work seamlessly with the standard Xeon E5 processors series to provide additional parallel hardware to boost parallel applications. A key benefit of the Xeon Phi series is that these don’t require redesigning the application, only compiler directives are required to be able to use the Xeon Phi coprocessor. Fundamentally, the Intel Xeon series are many-core parallel processors, with each core having a dedicated L2 cache. The cores are connected through a bi-directional ring interconnects. Intel offers a complete set of development, performance monitoring and tuning tools through its Parallel Studio and VTune. The goal is to enable HPC users to get advantage from the parallel hardware with minimal changes to the code. The Xeon Phi has two modes of operation, the offload mode and native mode. In the offload mode designed parts of the application are “offloaded” to the Xeon Phi, if available in the server. Required code and data is copied from a host to the coprocessor, processing is done parallel in the Phi coprocessor and results move back to the host. There are two kinds of offload modes, non-shared and virtual-shared memory modes. Each offload mode offers different levels of user control on data movement to and from the coprocessor and incurs different types of overheads. In the native mode, the application runs on both host and Xeon Phi simultaneously, communication required data among themselves as need.
  • Vxworks Architecture Supplement, 6.2

    Vxworks Architecture Supplement, 6.2

    VxWorks Architecture Supplement VxWorks® ARCHITECTURE SUPPLEMENT 6.2 Copyright © 2005 Wind River Systems, Inc. All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means without the prior written permission of Wind River Systems, Inc. Wind River, the Wind River logo, Tornado, and VxWorks are registered trademarks of Wind River Systems, Inc. Any third-party trademarks referenced are the property of their respective owners. For further information regarding Wind River trademarks, please see: http://www.windriver.com/company/terms/trademark.html This product may include software licensed to Wind River by third parties. Relevant notices (if any) are provided in your product installation at the following location: installDir/product_name/3rd_party_licensor_notice.pdf. Wind River may refer to third-party documentation by listing publications or providing links to third-party Web sites for informational purposes. Wind River accepts no responsibility for the information provided in such third-party documentation. Corporate Headquarters Wind River Systems, Inc. 500 Wind River Way Alameda, CA 94501-1153 U.S.A. toll free (U.S.): (800) 545-WIND telephone: (510) 748-4100 facsimile: (510) 749-2010 For additional contact information, please visit the Wind River URL: http://www.windriver.com For information on how to contact Customer Support, please visit the following URL: http://www.windriver.com/support VxWorks Architecture Supplement, 6.2 11 Oct 05 Part #: DOC-15660-ND-00 Contents 1 Introduction
  • EEMBC and the Purposes of Embedded Processor Benchmarking Markus Levy, President

    EEMBC and the Purposes of Embedded Processor Benchmarking Markus Levy, President

    EEMBC and the Purposes of Embedded Processor Benchmarking Markus Levy, President ISPASS 2005 Certified Performance Analysis for Embedded Systems Designers EEMBC: A Historical Perspective • Began as an EDN Magazine project in April 1997 • Replace Dhrystone • Have meaningful measure for explaining processor behavior • Developed business model • Invited worldwide processor vendors • A consortium was born 1 EEMBC Membership • Board Member • Membership Dues: $30,000 (1st year); $16,000 (subsequent years) • Access and Participation on ALL Subcommittees • Full Voting Rights • Subcommittee Member • Membership Dues Are Subcommittee Specific • Access to Specific Benchmarks • Technical Involvement Within Subcommittee • Help Determine Next Generation Benchmarks • Special Academic Membership EEMBC Philosophy: Standardized Benchmarks and Certified Scores • Member derived benchmarks • Determine the standard, the process, and the benchmarks • Open to industry feedback • Ensures all processor/compiler vendors are running the same tests • Certification process ensures credibility • All benchmark scores officially validated before publication • The entire benchmark environment must be disclosed 2 Embedded Industry: Represented by Very Diverse Applications • Networking • Storage, low- and high-end routers, switches • Consumer • Games, set top boxes, car navigation, smartcards • Wireless • Cellular, routers • Office Automation • Printers, copiers, imaging • Automotive • Engine control, Telematics Traditional Division of Embedded Applications Low High Power
  • Intel Cirrascale and Petrobras Case Study

    Intel Cirrascale and Petrobras Case Study

    Case Study Intel® Xeon Phi™ Coprocessor Intel® Xeon® Processor E5 Family Big Data Analytics High-Performance Computing Energy Accelerating Energy Exploration with Intel® Xeon Phi™ Coprocessors Cirrascale delivers scalable performance by combining its innovative PCIe switch riser with Intel® processors and coprocessors To find new oil and gas reservoirs, organizations are focusing exploration in the deep sea and in complex geological formations. As energy companies such as Petrobras work to locate and map those reservoirs, they need powerful IT resources that can process multiple iterations of seismic models and quickly deliver precise results. IT solution provider Cirrascale began building systems with Intel® Xeon Phi™ coprocessors to provide the scalable performance Petrobras and other customers need while holding down costs. Challenges • Enable deep-sea exploration. Improve reservoir mapping accuracy with detailed seismic processing. • Accelerate performance of seismic applications. Speed time to results while controlling costs. • Improve scalability. Enable server performance and density to scale as data volumes grow and workloads become more demanding. Solution • Custom Cirrascale servers with Intel Xeon Phi coprocessors. Employ new compute blades with the Intel® Xeon® processor E5 family and Intel Xeon Phi coprocessors. Cirrascale uses custom PCIe switch risers for fast, peer-to-peer communication among coprocessors. Technology Results • Linear scaling. Performance increases linearly as Intel Xeon Phi coprocessors “Working together, the are added to the system. Intel® Xeon® processors • Simplified development model. Developers no longer need to spend time optimizing data placement. and Intel® Xeon Phi™ coprocessors help Business Value • Faster, better analysis. More detailed and accurate modeling in less time HPC applications shed improves oil and gas exploration.
  • Cloud Workbench a Web-Based Framework for Benchmarking Cloud Services

    Cloud Workbench a Web-Based Framework for Benchmarking Cloud Services

    Bachelor August 12, 2014 Cloud WorkBench A Web-Based Framework for Benchmarking Cloud Services Joel Scheuner of Muensterlingen, Switzerland (10-741-494) supervised by Prof. Dr. Harald C. Gall Philipp Leitner, Jürgen Cito software evolution & architecture lab Bachelor Cloud WorkBench A Web-Based Framework for Benchmarking Cloud Services Joel Scheuner software evolution & architecture lab Bachelor Author: Joel Scheuner, [email protected] Project period: 04.03.2014 - 14.08.2014 Software Evolution & Architecture Lab Department of Informatics, University of Zurich Acknowledgements This bachelor thesis constitutes the last milestone on the way to my first academic graduation. I would like to thank all the people who accompanied and supported me in the last four years of study and work in industry paving the way to this thesis. My personal thanks go to my parents supporting me in many ways. The decision to choose a complex topic in an area where I had no personal experience in advance, neither theoretically nor technologically, made the past four and a half months challenging, demanding, work-intensive, but also very educational which is what remains in good memory afterwards. Regarding this thesis, I would like to offer special thanks to Philipp Leitner who assisted me during the whole process and gave valuable advices. Moreover, I want to thank Jürgen Cito for his mainly technologically-related recommendations, Rita Erne for her time spent with me on language review sessions, and Prof. Harald Gall for giving me the opportunity to write this thesis at the Software Evolution & Architecture Lab at the University of Zurich and providing fundings and infrastructure to realize this thesis.
  • MIPS IV Instruction Set

    MIPS IV Instruction Set

    MIPS IV Instruction Set Revision 3.2 September, 1995 Charles Price MIPS Technologies, Inc. All Right Reserved RESTRICTED RIGHTS LEGEND Use, duplication, or disclosure of the technical data contained in this document by the Government is subject to restrictions as set forth in subdivision (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DFARS 52.227-7013 and / or in similar or successor clauses in the FAR, or in the DOD or NASA FAR Supplement. Unpublished rights reserved under the Copyright Laws of the United States. Contractor / manufacturer is MIPS Technologies, Inc., 2011 N. Shoreline Blvd., Mountain View, CA 94039-7311. R2000, R3000, R6000, R4000, R4400, R4200, R8000, R4300 and R10000 are trademarks of MIPS Technologies, Inc. MIPS and R3000 are registered trademarks of MIPS Technologies, Inc. The information in this document is preliminary and subject to change without notice. MIPS Technologies, Inc. (MTI) reserves the right to change any portion of the product described herein to improve function or design. MTI does not assume liability arising out of the application or use of any product or circuit described herein. Information on MIPS products is available electronically: (a) Through the World Wide Web. Point your WWW client to: http://www.mips.com (b) Through ftp from the internet site “sgigate.sgi.com”. Login as “ftp” or “anonymous” and then cd to the directory “pub/doc”. (c) Through an automated FAX service: Inside the USA toll free: (800) 446-6477 (800-IGO-MIPS) Outside the USA: (415) 688-4321 (call from a FAX machine) MIPS Technologies, Inc.
  • Automatic Benchmark Profiling Through Advanced Trace Analysis Alexis Martin, Vania Marangozova-Martin

    Automatic Benchmark Profiling Through Advanced Trace Analysis Alexis Martin, Vania Marangozova-Martin

    Automatic Benchmark Profiling through Advanced Trace Analysis Alexis Martin, Vania Marangozova-Martin To cite this version: Alexis Martin, Vania Marangozova-Martin. Automatic Benchmark Profiling through Advanced Trace Analysis. [Research Report] RR-8889, Inria - Research Centre Grenoble – Rhône-Alpes; Université Grenoble Alpes; CNRS. 2016. hal-01292618 HAL Id: hal-01292618 https://hal.inria.fr/hal-01292618 Submitted on 24 Mar 2016 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Automatic Benchmark Profiling through Advanced Trace Analysis Alexis Martin , Vania Marangozova-Martin RESEARCH REPORT N° 8889 March 23, 2016 Project-Team Polaris ISSN 0249-6399 ISRN INRIA/RR--8889--FR+ENG Automatic Benchmark Profiling through Advanced Trace Analysis Alexis Martin ∗ † ‡, Vania Marangozova-Martin ∗ † ‡ Project-Team Polaris Research Report n° 8889 — March 23, 2016 — 15 pages Abstract: Benchmarking has proven to be crucial for the investigation of the behavior and performances of a system. However, the choice of relevant benchmarks still remains a challenge. To help the process of comparing and choosing among benchmarks, we propose a solution for automatic benchmark profiling. It computes unified benchmark profiles reflecting benchmarks’ duration, function repartition, stability, CPU efficiency, parallelization and memory usage.
  • Power Measurement Tutorial for the Green500 List

    Power Measurement Tutorial for the Green500 List

    Power Measurement Tutorial for the Green500 List R. Ge, X. Feng, H. Pyla, K. Cameron, W. Feng June 27, 2007 Contents 1 The Metric for Energy-Efficiency Evaluation 1 2 How to Obtain P¯(Rmax)? 2 2.1 The Definition of P¯(Rmax)...................................... 2 2.2 Deriving P¯(Rmax) from Unit Power . 2 2.3 Measuring Unit Power . 3 3 The Measurement Procedure 3 3.1 Equipment Check List . 4 3.2 Software Installation . 4 3.3 Hardware Connection . 4 3.4 Power Measurement Procedure . 5 4 Appendix 6 4.1 Frequently Asked Questions . 6 4.2 Resources . 6 1 The Metric for Energy-Efficiency Evaluation This tutorial serves as a practical guide for measuring the computer system power that is required as part of a Green500 submission. It describes the basic procedures to be followed in order to measure the power consumption of a supercomputer. A supercomputer that appears on The TOP500 List can easily consume megawatts of electric power. This power consumption may lead to operating costs that exceed acquisition costs as well as intolerable system failure rates. In recent years, we have witnessed an increasingly stronger movement towards energy-efficient computing systems in academia, government, and industry. Thus, the purpose of the Green500 List is to provide a ranking of the most energy-efficient supercomputers in the world and serve as a complementary view to the TOP500 List. However, as pointed out in [1, 2], identifying a single objective metric for energy efficiency in supercom- puters is a difficult task. Based on [1, 2] and given the already existing use of the “performance per watt” metric, the Green500 List uses “performance per watt” (PPW) as its metric to rank the energy efficiency of supercomputers.
  • Towards Better Performance Per Watt in Virtual Environments on Asymmetric Single-ISA Multi-Core Systems

    Towards Better Performance Per Watt in Virtual Environments on Asymmetric Single-ISA Multi-Core Systems

    Towards Better Performance Per Watt in Virtual Environments on Asymmetric Single-ISA Multi-core Systems Viren Kumar Alexandra Fedorova Simon Fraser University Simon Fraser University 8888 University Dr 8888 University Dr Vancouver, Canada Vancouver, Canada [email protected] [email protected] ABSTRACT performance per watt than homogeneous multicore proces- Single-ISA heterogeneous multicore architectures promise to sors. As power consumption in data centers becomes a grow- deliver plenty of cores with varying complexity, speed and ing concern [3], deploying ASISA multicore systems is an performance in the near future. Virtualization enables mul- increasingly attractive opportunity. These systems perform tiple operating systems to run concurrently as distinct, in- at their best if application workloads are assigned to het- dependent guest domains, thereby reducing core idle time erogeneous cores in consideration of their runtime proper- and maximizing throughput. This paper seeks to identify a ties [4][13][12][18][24][21]. Therefore, understanding how to heuristic that can aid in intelligently scheduling these vir- schedule data-center workloads on ASISA systems is an im- tualized workloads to maximize performance while reducing portant problem. This paper takes the first step towards power consumption. understanding the properties of data center workloads that determine how they should be scheduled on ASISA multi- We propose that the controlling domain in a Virtual Ma- core processors. Since virtual machine technology is a de chine Monitor or hypervisor is relatively insensitive to changes facto standard for data centers, we study virtual machine in core frequency, and thus scheduling it on a slower core (VM) workloads. saves power while only slightly affecting guest domain per- formance.
  • Genesi Pegasos II Debian Linux by Maurie Ommerman CPD Applications Freescale Semiconductor, Inc

    Genesi Pegasos II Debian Linux by Maurie Ommerman CPD Applications Freescale Semiconductor, Inc

    Freescale Semiconductor AN2739 Application Note Rev. 1, 03/2005 Genesi Pegasos II Debian Linux by Maurie Ommerman CPD Applications Freescale Semiconductor, Inc. Austin, TX This application note is the fourth in a series describing the Genesi Contents Pegasos II system, which contains a PowerPC™ microprocessor, 1. Introduction . 1 and the various applications of the system. 2. Terminology . 2 3. Starting Debian Linux . 2 4. Logging in as a Normal User . 6 5. Window Managers . 14 1 Introduction 6. Other User Applications . 19 7. Root User . 20 This application note describes the Debian Linux Operating 8. References . 43 System and many of the commands. Linux has a variety of ways 9. Document Revision History . 43 to accomplish most tasks. This document will show only one way to perform the actions described here. There are other ways. Also, there is usually a GUI way to accomplish most tasks, however, this paper presents command line methods for most tasks. GUI are nice, but they hide what is really happening. When the network is set up with a GUI, how the files are actually affected is not seen, but using the line commands allows feedback on exactly what is happening. This is not a complete guide to Debian Linux, but is a collection of useful things to help both the experienced and novice become quickly adept at using Debian Linux. © Freescale Semiconductor, Inc., 2005. All rights reserved. Terminology 2 Terminology The following terms are used in this document. CUPS Common Unix Printing System Architecture Debian One of the versions of Linux IDE A type of hard drive, which allows up to 2 drives on each channel Linux OS Linux operating system SCSI A type of hard drive, which allows up to 8 drives on each channel Shell A software construct to allow separate users and jobs within the same user to have a separate environment to avoid interfering with each other USB Universal serial bus Yellow Dog One of the versions of Linux 3 Starting Debian Linux Use the boot option 2 for the 2.4 kernel and option 3 for the 2.6 kernel, option 4 for the 2.6.8 kernel.
  • I.MX 8Quadxplus Power and Performance

    I.MX 8Quadxplus Power and Performance

    NXP Semiconductors Document Number: AN12338 Application Note Rev. 4 , 04/2020 i.MX 8QuadXPlus Power and Performance 1. Introduction Contents This application note helps you to design power 1. Introduction ........................................................................ 1 management systems. It illustrates the current drain 2. Overview of i.MX 8QuadXPlus voltage supplies .............. 1 3. Power measurement of the i.MX 8QuadXPlus processor ... 2 measurements of the i.MX 8QuadXPlus Applications 3.1. VCC_SCU_1V8 power ........................................... 4 Processors taken on NXP Multisensory Evaluation Kit 3.2. VCC_DDRIO power ............................................... 4 (MEK) Platform through several use cases. 3.3. VCC_CPU/VCC_GPU/VCC_MAIN power ........... 5 3.4. Temperature measurements .................................... 5 This document provides details on the performance and 3.5. Hardware and software used ................................... 6 3.6. Measuring points on the MEK platform .................. 6 power consumption of the i.MX 8QuadXPlus 4. Use cases and measurement results .................................... 6 processors under a variety of low- and high-power 4.1. Low-power mode power consumption (Key States modes. or ‘KS’)…… ......................................................................... 7 4.2. Complex use case power consumption (Arm Core, The data presented in this application note is based on GPU active) ......................................................................... 11 5. SOC