DOCSLIB.ORG

Colorado 3 RT6226N Hypersparc™ Dual CPU Module/Power Module

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Colorado 3 RT6226N Hypersparc™ Dual CPU Module/Power Module 830-0058-00 Rev A 11/15/96 Colorado 3 RT6226N hyperSPARC DualĆCPU Module/Power Module Features D Based on ROSS’ fourth-generation — Hardware support for symmetric, — Zero-wait-state, 512-Kbyte or hyperSPARC processor shared-memory multiprocessing 1-Mbyte 2nd-level cache D Each module consists of two complete — Level 2 MBus support for cache — Demand-paged virtual memory SPARC CPUs coherency management D Each processor includes D SPARC compliant D Module design — RT620C Central Processing Unit — SPARC Instruction Set Architec- — CPU Module fits in MBus-standard (CPU) ture (ISA) Version 8 compliant form factor: 3.30” (8.34 cm) x 5.78” — RT626 Cache Controller, Memory — Conforms to SPARC Reference (14.67 cm) Management, and Tag Unit MMU Architecture — Power Module attaches to the rear (CMTU) — Conforms to SPARC Level 2 MBus of the CPU module through a stan- — Four (512-Kbyte) or eight Module Specification (Revision 1.2) dard 25-pin D shell connector (1-Mbyte) RT628 Cache Data Units D Dual-clock architecture — Provides CPU upgrade path at (CDUs) module level Ċ CPU scaleable up to 142 MHz Ċ IntraĆModule Bus incorporates low — Advanced packaging technology voltage logic to reduce power and— MBus scaleable up to 66 MHz for a compact design D increase speed Each hyperSPARC processor features D High performance * — Dual-level caches — Superscalar SPARC CPU with inte- — 174 SPECint92 (per CPU) D Full multiprocessing implementation grated floating point unit and 8-Kbyte instruction cache — 212 SPECfp92 (per CPU) * in a 50MHz MBus system CPU Module PLL CPU0 RT620C CPU1 RT620C Clock CPU CPU Generator IMCLK IMCLK +5V IMA[31:0] IMA[31:0] Power Module IMD[63:0] IMD[63:0] RT626 RT626 CMTU RT628 RT628 CMTU RT628 RT628 CDU CDU CDU CDU MBus (Level 2) Figure 1. Logic Block Diagram Selection Guide Part Number: RT6226N* Ć142/1024 CPU Operating Frequency (MHz) 142 Typical Power Consumption (w)** 74 Second-level Cache Size (per CPU) 1M SPECint92 / SPECfp92 174 / 212 SPECrateint92 / SPECratefp92 7684 / 9163 (dual processor) SPECrateint92 / SPECratefp92 (quad processor) *See Appendix C for hyperSPARC ordering information ** Commercial • ROSS Technology, Inc. • 5316 Hwy. 290 West • Austin, Texas 78735 • TEL (512) 436-2000 •FAX (512) 892-3036 1 830-0058-00 Rev A 11/15/96 Colorado 3 RT6226N Functional Description user’s time to market, but provides a mechanism for upgrad- The RT6226N hyperSPARC Module consists of a dual CPU ing in the field. module (RT6226N1) and a power module (RT6226N2). The Component Overview CPU module is a complete dual-SPARC CPU, including on- board primary and secondary cache memories. It is packaged Superscalar SPARC Processor (RT620C) as a compact PCB and interfaces to the remainder of the sys- The RT620C Central Processing Unit is the heart of ROSS’ tem via a SPARC-standard MBus connector. Each of the two fourth-generation of microprocessor. The RT620C CPU ar- CPUs on the RT6226N1 consists of a high-speed superscalar, chitecture employs two advanced concepts for increasing highly pipelined processor with dual integer ALUs and an on- computer system performance: superscalability and superpi- chip floating-point unit (RT620C), a Cache Controller, pelining. Memory Management, and Tag Unit (RT626), and four The RT620C is a high performance full-custom CMOS im- (512-Kbyte) or eight (1-Mbyte) RT628 Cache Data Units. plementation of integrated SPARC integer and floating-point The RT6226N1 fits within the clearance envelope for MBus logic, with an on-chip cache for instructions. modules per the SPARC MBus Specification. The RT6226N2 power module provides the low voltage needed by the CPU Advanced architecture and manufacturing technologies give the RT620C ultra high performance without requiring soft- module from the +5V MBus source. It interfaces to the CPU module through a standard DB–25 connector. It is housed in ware recompilation. Figure 2 is a logic block diagram of the an enclosure which mounts remotely from the CPU module. RT620C. The RT6226N1 interfaces to the rest of the system via the IDP. The Integer Data Path comprises several units. Two SPARC MBus and conforms to the SPARC Reference MMU. independent Arithmetic and Logic Units (ALUs) handle inte- ger arithmetic, logical, and shift instructions. The Load/Store This standardization allows the RT6226N1 to be interchange- able with other SPARC MBus-based CPU modules without Unit (LSU) handles instructions that load and store data be- tween memory and registers which includes the loading and having to modify any portion of the memory system or I/O. This CPU “building block” strategy not only decreases the storing of both integer and floating-point data. The Special IDP Special Registers Integer Registers (IREGS) Floating Point Registers (FREGS) Input Selection Input Selection Input Selection Input Selection ALU ALULDST FPADD FPMUL Align Check Align Check FPDP Floating Program Global Decoder Floating Counter Point Point Dependency Checker Queue Unit Schedule and Control Scheduler Load Store Align Align FPSCHED Exception Logic ISCHED Data Address Instruction Address Instruction Instruction Instruction Cache Intramodule Fetch Bus Controller Interface IFETCH ICACHE IBIU Control Address Out Control Data/ In Instruction Figure 2. RT620C CPU Logic Block Diagram 2 830-0058-00 Rev A 11/15/96 Colorado 3 RT6226N Register Unit (SRU) handles instructions that read and write Cache Control, Memory Management, and Tag Unit the SPARC Special Registers (SREGS). The Integer Register (RT626) File (IREGS) is also contained in the IDP. The CMTU (RT626) is a combined Cache Controller and FPDP. The Floating-Point Data Path also comprises several Memory Management Unit optimized for multiprocessing units. These are the Floating-Point Queue (FPQ), the Float- systems. The CMTU is a high-speed CMOS implementation ing-Point Arithmetic Unit (FAU), The Floating-Point Multi- of the SPARC Reference MMU, combined with cache, a plier Unit (FMU), the Floating-Point Register File (FREGS), memory controller, and on-chip physical cache tag memory. and the Floating-Point Status Register (FSR). These floating- The CMTU supports the SPARC MBus Level 2 protocol for point units handle all SPARC floating-point instructions. multiprocessing systems. Figure 3 depicts the CMTU block diagram. ISCHED. The Integer Scheduler performs key control func- tions. It provides global instruction decodes to identify which The CMTU directly connects to the RT620C Central Proces- execution unit resources are required, and determines wheth- sing Unit and RT628 Cache Data Units without any external er sequential or simultaneous execution is possible. circuitry. The RT626 CMTU uses four or eight RT628 CDUs to realize 512-Kbytes or 1-Mbyte, respectively, of zero-wait- The ISCHED also determines whether data forwarding can state, direct-mapped virtual cache memory. be performed and whether instruction dispatches (also called “launches”) need to be delayed due to data dependencies. MMU. The MMU portion of the CMTU provides translation The ISCHED initiates instruction launch and identifies and from a 32-bit virtual address (4 gigabytes) to 36-bit physical controls interrupt and trap handling. address (64 gigabytes), as provided in the SPARC reference MMU specification. Virtual addresses are further extended FPSCHED. The Floating-Point Instruction Scheduler per- with the use of a context register, which is used to identify up forms key control functions for the floating-point unit. When to 4096 contexts or tasks. The TLB entries contain context the Integer Unit detects floating-point instructions in the numbers to identify tasks or processes. This minimizes un- decode stage, it offloads these instructions to the floating- necessary TLB entry replacement during task switching. point functional units and continues processing. Therefore, functional blocks exist that perform necessary decode, sched- The CMTU performs its address translation task by compar- uling, and control for the floating-point operations. ing a virtual address supplied by the RT620C through the In- tra-Module Bus to the address tags in the TLB entries. If a The FPSCHED performs floating-point instruction decoding, “hit” occurs, the physical address stored in the TLB is used to resolves floating-point data dependency and data-forwarding translate the virtual-to-physical address. If the virtual address conditions, and provides the ISCHED with floating-point does not match any valid TLB entry, a “miss” occurs. This execution status. Delayed instructions are stored temporarily causes a table walk to be performed by the MMU. The table in the Floating-Point Instruction Queue (FPQ). Instructions walk is a search performed by the MMU through the address are launched from the FPQ as data dependencies are translation tables stored in main memory. Upon finding the resolved. PTE, the MMU translates the address and selects a TLB entry IFETCH. The Instruction Fetch Unit consists of two major for replacement. functional blocks referred to as the Program Counter Unit Cache Controller The CMTU’s cache controller supports (PCU) and the Instruction Fetch Controller (IFETCHC). two modes of caching: write-through with no write allocate The PCU calculates the address of the next instruction to be and copy-back with write allocate. The cache is “virtually in- fetched. It handles instructions that cause program control dexed” and “physically tagged.” transfer, such as CALL and BRANCH. This unit handles both In 1-Mbyte secondary cache versions, the cache is organized integer and floating-point branch instructions. as 16384 lines with two sub-blocks, each of which is 32 bytes. The IFETCHC fetches two instructions at a time, and in each Intra-Module Bus address bits IMA[19:6] select the cache clock cycle, the CPU attempts to launch both at once. line, IMA[5] selects the sub-block, and IMA[4:3] select the ICACHE. The on-chip instruction cache is organized as a 64-bit word of the cache line. In 512-Kbyte secondary cache two way set associative buffer. The ICACHE stores 8 Kbytes versions, only one sub-block is populated, and IMA[18:5] of instructions.
Load more

Recommended publications
  • System Administration
    System Administration Varian NMR Spectrometer Systems With VNMR 6.1C Software Pub. No. 01-999166-00, Rev. C0503 System Administration Varian NMR Spectrometer Systems With VNMR 6.1C Software Pub. No. 01-999166-00, Rev. C0503 Revision history: A0800 – Initial release for VNMR 6.1C A1001 – Corrected errors on pg 120, general edit B0202 – Updated AutoTest B0602 – Added additional Autotest sections including VNMRJ update B1002 – Updated Solaris patch information and revised section 21.7, Autotest C0503 – Add additional Autotest sections including cryogenic probes Applicability: Varian NMR spectrometer systems with Sun workstations running Solaris 2.x and VNMR 6.1C software By Rolf Kyburz ([email protected]) Varian International AG, Zug, Switzerland, and Gerald Simon ([email protected]) Varian GmbH, Darmstadt, Germany Additional contributions by Frits Vosman, Dan Iverson, Evan Williams, George Gray, Steve Cheatham Technical writer: Mike Miller Technical editor: Dan Steele Copyright 2001, 2002, 2003 by Varian, Inc., NMR Systems 3120 Hansen Way, Palo Alto, California 94304 1-800-356-4437 http://www.varianinc.com All rights reserved. Printed in the United States. The information in this document has been carefully checked and is believed to be entirely reliable. However, no responsibility is assumed for inaccuracies. Statements in this document are not intended to create any warranty, expressed or implied. Specifications and performance characteristics of the software described in this manual may be changed at any time without notice. Varian reserves the right to make changes in any products herein to improve reliability, function, or design. Varian does not assume any liability arising out of the application or use of any product or circuit described herein; neither does it convey any license under its patent rights nor the rights of others.
    [Show full text]
  • Ross Technology RT6224K User Manual 1 (Pdf)
    Full-service, independent repair center -~ ARTISAN® with experienced engineers and technicians on staff. TECHNOLOGY GROUP ~I We buy your excess, underutilized, and idle equipment along with credit for buybacks and trade-ins. Custom engineering Your definitive source so your equipment works exactly as you specify. for quality pre-owned • Critical and expedited services • Leasing / Rentals/ Demos equipment. • In stock/ Ready-to-ship • !TAR-certified secure asset solutions Expert team I Trust guarantee I 100% satisfaction Artisan Technology Group (217) 352-9330 | [email protected] | artisantg.com All trademarks, brand names, and brands appearing herein are the property o f their respective owners. Find the Ross Technology RT6224K-200/512S at our website: Click HERE 830-0016-03 Rev A 11/15/96 PRELIMINARY Colorado 4 RT6224K hyperSPARC CPU Module Features D Based on ROSS’ fifth-generation D SPARC compliant — Zero-wait-state, 512-Kbyte or hyperSPARC processor — SPARC Instruction Set Architec- 1-Mbyte 2nd-level cache — RT620D Central Processing Unit ture (ISA) Version 8 compliant — Demand-paged virtual memory (CPU) — Conforms to SPARC Reference management — RT626 Cache Controller, Memory MMU Architecture D Module design Management, and Tag Unit — Conforms to SPARC Level 2 MBus — MBus-standard form factor: 3.30” (CMTU) Module Specification (Revision 1.2) (8.34 cm) x 5.78” (14.67 cm) — Four (512-Kbyte) or eight D Dual-clock architecture — Provides CPU upgrade path at (1-Mbyte) RT628 Cache Data Units module level (CDUs) Ċ CPU scaleable up to
    [Show full text]
  • 12 MULTICHIP MODULES (Mcms)
    12 MULTICHIP MODULES (MCMs) HISTORICAL PERSPECTIVE Virtually every large computer manufacturer, telecommunications products manufacturer, high volume consumer electronics manufacturer and aerospace products manufacturer is working on or considering designs that include multichip modules. There has been a dramatic increase in activity over the last five years, with entire conferences being dedicated to multichip modules. MCMs have gone through three phases in their growth. Phase one was the widespread use in mainframe and super computer products. Some examples of MCMs used for these high-end applications are shown in Figure 12-1. The primary driving force was performance. These systems were predominately ECL based, with relatively low inte- gration levels. The MCM implementation allowed the Òre-integrationÓ of the LSI chips into VLSI modules, while keeping the wiring delays small. Source: DEC Source: IBM Source: Motorola/Siemens Source: ICE, “Roadmaps of Packaging Technology” 22555 Figure 12-1. Early MCMs in ECL Mainframe Computers in the Mid 1980Õs INTEGRATED CIRCUIT ENGINEERING CORPORATION 12-1 Multichip Modules (MCMs) Using a conventional single chip package and circuit board interconnect strategy, the package and interconnects took up over 50% of the timing budget. Decreases in the chip delays could not have much impact on system performance without a significant decrease in the interconnect delays as well. The use of MCMs reduced the interconnect delays significantly. This is shown in Figure 12-2 com- paring the delays in the IBM 3033 with a CPU using single chip packages and four circuit boards, and the IBM 3081, the first mainframe that used the Thermal Conduction Module (TCM).
    [Show full text]
  • Hypersparc Module Installation Guide E ROSS Technology, Inc
    TM hyperSPARC Module Installation Guide E ROSS Technology, Inc. 5316 Highway 290 West Austin, Texas 78735 U.S.A. All rights reserved. This product and related documentation is protected by copyright and distributed under licenses re- stricting its use, copying, distribution, and decompilation. No part of this product or related documentation may be repro- duced in any form by any means without prior written authorization of ROSS Technology and its licensors, if any. Portions of this product may be derived from the UNIXR and Berkeley 4.3 BSD systems, licensed from UNIX Systems Laboratories, Inc. and the University of California, respectively. Third party font software in this product is protected by copyright and licensed from Sun’s Font Suppliers. RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR 52.227-19. The product described in this manual may be protected by one or more U.S. patents, foreign patents, or pending applica- tions. TRADEMARKS: ROSS, ROSS Technology, and the ROSS Technology, Inc. logo are registered trademarks of ROSS Technology, Inc. hyperSPARC is a trademark of SPARC International, Inc. and is licensed exclusively to ROSS Technology, Inc. Sun, Sun Microsystems, and the Sun logo are trademarks or registered trademarks of Sun Microsystems, Inc. UNIX, and OPEN LOOK are registered trademarks of UNIX System Laboratories, Inc. All other product names mentioned herein are the trademarks of their respective owners. All SPARC trademarks, including the SCD Compliant Logo, are trademarks or registered trademarks of SPARC Interna- tional, Inc.
    [Show full text]
  • Computer Architectures an Overview
    Computer Architectures An Overview PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Sat, 25 Feb 2012 22:35:32 UTC Contents Articles Microarchitecture 1 x86 7 PowerPC 23 IBM POWER 33 MIPS architecture 39 SPARC 57 ARM architecture 65 DEC Alpha 80 AlphaStation 92 AlphaServer 95 Very long instruction word 103 Instruction-level parallelism 107 Explicitly parallel instruction computing 108 References Article Sources and Contributors 111 Image Sources, Licenses and Contributors 113 Article Licenses License 114 Microarchitecture 1 Microarchitecture In computer engineering, microarchitecture (sometimes abbreviated to µarch or uarch), also called computer organization, is the way a given instruction set architecture (ISA) is implemented on a processor. A given ISA may be implemented with different microarchitectures.[1] Implementations might vary due to different goals of a given design or due to shifts in technology.[2] Computer architecture is the combination of microarchitecture and instruction set design. Relation to instruction set architecture The ISA is roughly the same as the programming model of a processor as seen by an assembly language programmer or compiler writer. The ISA includes the execution model, processor registers, address and data formats among other things. The Intel Core microarchitecture microarchitecture includes the constituent parts of the processor and how these interconnect and interoperate to implement the ISA. The microarchitecture of a machine is usually represented as (more or less detailed) diagrams that describe the interconnections of the various microarchitectural elements of the machine, which may be everything from single gates and registers, to complete arithmetic logic units (ALU)s and even larger elements.
    [Show full text]
  • Cacheminer: a Runtime Approach to Exploit Cache Locality on SMP
    IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, VOL. 11, NO. 4, APRIL 2000 357 Cacheminer: A Runtime Approach to Exploit Cache Locality on SMP Yong Yan, Member, IEEE Computer Society, Xiaodong Zhang, Senior Member, IEEE, and Zhao Zhang, Member, IEEE AbstractÐExploiting cache locality of parallel programs at runtime is a complementary approach to a compiler optimization. This is particularly important for those applications with dynamic memory access patterns. We propose a memory-layout oriented technique to exploit cache locality of parallel loops at runtime on Symmetric Multiprocessor (SMP) systems. Guided by application-dependent and targeted architecture-dependent hints, our system, called Cacheminer, reorganizes and partitions a parallel loop using the memory- access space of its execution. Through effective runtime transformations, our system maximizes the data reuse in each partitioned data region assigned in a cache, and minimizes the data sharing among the partitioned data regions assigned to all caches. The executions of tasks in the partitions are scheduled in an adaptive and locality-preserved way to minimize the execution time of programs by trading off load balance and locality. We have implemented the Cacheminer runtime library on two commercial SMP servers and an SimOS simulated SMP. Our simulation and measurement results show that our runtime approach can achieve comparable performance with the compiler optimizations for programs with regular computation and memory-access patterns, whose load balance and cache locality can be well optimized by the tiling and other program transformations. However, our experimental results show that our approach is able to significantly improve the memory performance for the applications with irregular computation and dynamic memory access patterns.
    [Show full text]
  • Strategic Interactions in Dram and Risc Technology: a Network Approach
    Strategic interactions in dram and risc technology: A network approach Geert Duysters & Wim Vanhaverbeke 93.023 September 1993 MERIT, P.O. Box 616, 6200 MD Maastricht (Netherlands) - telephone (31)43-883875- fax: (31)43-216518 1 STRATEGIC INTERACTIONS IN DRA AND RISC TECHNOLOGY: A NETWORK APPROACH Geert Duysters and WiI Vanhaverbeke1 INTRODUCTION Cooperative agreements have been ignored in business literature for a veiy long time. Only recently, the use of cooperative agreements as part of corporate strategies gained substantial interest. This increase in attention is above all due to the fact that in the last decade the number of cooperative agreements by firms has rocketed. In fact cooperative agreements have outnumbered the fully owned foreign subsidiaries (Contractor and Lorange, 1988). In this paper we will use the term cooperation to denote cooperative agreements between partners which are not connected through (majority) ownership. A cooperative agreement can be seen as an agreement which is positioned between two extremes, arm's length transactions on the one hand and the merger of the two firs on the other hand. Cooperation among companies is usually analyzed in strategic management literature on the dyadic level or on the level of the partcipating firs. Only recently, interest by economists has grown to study cooperative efforts of firs within an inter-organisational network framework (see e.g. Hagedoom and Schakenraad. 1990, 1992, 1993). In high- tech industries where almost all incumbents are linked to each other by means of a network of cooperative agreements, an analysis on the level of the individual players or allances is not appropriate to understand the strategic value of cooperative strategies.
    [Show full text]
  • Company Backgrounder R
    Company Backgrounder R The SPARCTM Solutions Company ROSS Technology, Inc., in its commitment to provide leading-edge SPARCTM solu- tions, offers a full range of hardware products that provide the performance, soft- ware compatibility, and upgradeability demanded by our worldwide market. Our design expertise ranges from SPARC microprocessors and motherboards to com- plete workstations and servers. Founded in 1988, ROSS has supplied high-performance microprocessors to SPARC systems OEMs such as Sun Microsystems, Fujitsu, Tatung, Axil, and ICL, to name a few. To increase our marketshare, ROSS established a program to provide hyperSPARCTM multiprocessing CPU upgrades to end users of Sun SPARCstationTM 10, 20 and SPARCserverTM 600MP systems. Our success in this new market led to the development of motherboard upgrade kits for SPARCstation 5 systems that enable full multiprocessing performance (up to four CPUs) at a cost far below that of a comparable new system. The commitment, experience and design exper- tise developed in the areas of multiprocessing, upgradeability and the SPARC architecture have established ROSS as a leader in the SPARC community and have contributed to the outstanding overall success of SPARC systems in the worksta- tion market today. In keeping with our commitment to provide solutions to the increasing demands of our customers, ROSS recently introduced SPARCplugTM and hyperSTATIONTM workstations. Available in several configurations ranging from a plug-in worksta- tion module for a tower PC to full servers, SPARCplug workstations provide SPARCstationTM 20-level performance in a reduced form factor and at a lower cost. For customers with even greater performance needs, ROSS hyperSTATION work- stations and hyperSERVERTM systems extend the state-of-the-art of 32-bit multipro- cessing to new levels and offer an extensive upgrade path to satisfy future require- ments.
    [Show full text]
  • Solaris 8 (SPARC Platform Edition) Online Release Notes Update
    Solaris 8 (SPARC Platform Edition) Online Release Notes Update Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303–4900 U.S.A. Part Number 806-3771–10 February 2000 Copyright 2000 Sun Microsystems, Inc. 901 San Antonio Road, Palo Alto, California 94303-4900 U.S.A. All rights reserved. This product or document is protected by copyright and distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this product or document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Third-party software, including font technology, is copyrighted and licensed from Sun suppliers. Parts of the product may be derived from Berkeley BSD systems, licensed from the University of California. UNIX is a registered trademark in the U.S. and other countries, exclusively licensed through X/Open Company, Ltd. Sun, Sun Microsystems, the Sun logo, docs.sun.com, AnswerBook, AnswerBook2, SunStore, Java, JDK, Solaris Web Start, JumpStart, NFS, HotJava, DiskSuite, Solstice AdminSuite, SunLink, Solstice AutoClient, and Solaris are trademarks, registered trademarks, or service marks of Sun Microsystems, Inc. in the U.S. and other countries. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the U.S. and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. The OPEN LOOK and SunTM Graphical User Interface was developed by Sun Microsystems, Inc. for its users and licensees. Sun acknowledges the pioneering efforts of Xerox in researching and developing the concept of visual or graphical user interfaces for the computer industry.
    [Show full text]
  • Sparcstation 20 Service Manual
    SPARCstation 20 Service Manual Sun Microsystems Computer Company A Sun Microsystems, Inc. Business 901 San Antonio Road Palo Alto, CA 94303-4900 USA 650 960-1300 fax 650 969-9131 Part No.: 801-6189-12 Revision A, July 1996 Send comments about this document to: [email protected] 1997 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, California 94303-4900 U.S.A. All rights reserved. This product or document is protected by copyright and distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this product or document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Portions of this product may be derived from the UNIX® system, licensed from Novell, Inc., and from the Berkeley 4.3 BSD system, licensed from the University of California. UNIX is a registered trademark in the United States and in other countries and is exclusively licensed by X/Open Company Ltd. Third-party software, including font technology in this product, is protected by copyright and licensed from Sun’s suppliers. RESTRICTED RIGHTS: Use, duplication, or disclosure by the U.S. Government is subject to restrictions of FAR 52.227-14(g)(2)(6/87) and FAR 52.227-19(6/87), or DFAR 252.227-7015(b)(6/95) and DFAR 227.7202-3(a). Sun, Sun Microsystems, the Sun logo, and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and in other countries. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc.
    [Show full text]
  • FIVE Documentation Sorenson Workstation
    The Sorenson Workstation FIVE Data by Olav Sorenson Jeffrey S. Skoll Chair in Technical Innovation and Entrepreneurship Professor of Strategic Management Joseph L. Rotman School of Management University of Toronto ©2008 Sorenson Workstation FIVE Data 2 Contents 1. Conditions of Use................................................................................................3 2. Data Set Author ...................................................................................................4 3. Data Set Summary...............................................................................................4 4. Author’s Research Using This Data Set..............................................................4 5. Additional References .........................................................................................5 6. Data Set Sources..................................................................................................5 7. Data Description..................................................................................................5 7.1. Product/Industry Definition...........................................................................6 7.2. Excluded Fields .............................................................................................7 8. Tables ..................................................................................................................8 8.1. Descriptive Statistics, File 1: SorensonworkprodFIVEdata.........................8 8.2. Descriptive Statistics, File 2: SorensonworkfirmFIVEdata
    [Show full text]
  • Benchmarks Are They Really Useful?
    Session 1520 Benchmarks - Are they Really Useful? A Boyanich, S P Maj Department of Computer Science Edith Cowan University Western Australia [email protected] Abstract Benchmarking is an important commercial tool, which can be used for quantifying the performance of computer and network equipment. Furthermore, benchmarks are potentially valuable as part of curriculum studies in computer and network technology. Benchmarks may be of value to support the understanding of different architectural features and their effect on equipment performance. In effect the benchmarking results may provide a tangible metric that can be related directly not only to various architectural features but also the interactions between different levels in the memory hierarchy, hence providing a method of quantifying different performances of differing computer architectures and configurations. In this context a wide range of benchmarks were tested using the criteria of: repeatability, comparability, consistency, use of meaningful units etc. The criteria selected are based on the fundamental principles of measurement science. Our results clearly indicated that different benchmarking suites gave significantly different results for the same equipment. Also each benchmark failed to give consistent results, when compared to other benchmarks, even on identical equipment. Furthermore many of the benchmarks provided performance data in arbitrary units that were difficult to relate to expected changes in performance. In effect every benchmark tested failed to meet the evaluation criteria. The authors offer an alternative benchmarking method that is designed to meet such criteria and experimental work to date indicates some success using this new metric. This paper presents results of this work and gives recommendations regarding the use of benchmarks in computer education courses.
    [Show full text]