[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference kernel::csguk_systems

Title:CSGUK_SYSTEMS
Notice:No restrictions on keyword creation
Moderator:KERNEL::ADAMS
Created:Wed Mar 01 1989
Last Modified:Thu Nov 28 1996
Last Successful Update:Fri Jun 06 1997
Number of topics:242
Total number of notes:1855

84.0. "5800 topic" by COMICS::EDMUNDS () Tue Jan 09 1990 02:27

From:	WAGON::DONALD "Terry Donald, DTN 264-2801 GSF/A15 Hudson, NH  08-Jan-1990 1315"  8-JAN-1990 18:24:35.01
To:	@COMBINED_PILOT
CC:	
Subj:	DECsystem 5800 Performance

               <<< SASE::WRKD:[NOTES$LIBRARY]DECSYSTEMS.NOTE;6 >>>
          -< DECSYSTEMS -- Discussing the MIPS-based, non-WS Systems >-
================================================================================
Note 90.0                  DECsystem 5800 Performance                 No replies
LANDO::ALLISON                                      134 lines   8-JAN-1990 01:17
--------------------------------------------------------------------------------
	There seems to be a great deal of confusion about the DECsystem
5800 performance and positioning throughout Digital's marketing and sales
communities.  In this note I'll try to set the record straight about it's
performance characteristics and how it compares to other DECsystems.

	The initial intent of the DECsystem 5800 was to provide a highly
expandable system to top Digital's new line-up of RISC systems.  The
primary goal was to achieve the best possible time to market to complete
the entire RISC product set by the start of FY90.  To achieve the time to
market goal, it was necessary to "borrow" the VAX 6000 system platform, and
even the bus interface used on the VAX 6200/6300 CPU.

	As CPU chips become faster in relationship to system memory, their
performance has become much more dependent upon memory access time.  It was
realized from the start of the design that DECsystem 5800 performance would
suffer somewhat from it's use of the VAX 6000 memory sub-system.  MIPSco
claimed that their 25MHz R3000 chip performed at 20 MIPs in their M/2000
system.  It was felt that the DECsystem would yield 15-18 MIPs re-using the
VAX 6000 components.

	At announcement the DECsystem 5800 was positioned at 18.7 "Integer
MIPs" and 14 overall "VUPs".  The 18.7 MIPs number was measured across a
group of 5 integer benchmarks.  The 14 VUPs number was measured across a
group of ~30 mixed floating point and integer benchmarks.  Unfortunately,
these industry standard benchmarks are typically small in size and do not
result in a significant number of cache misses.

	As the DECsystem 5800 was benchmarked by customers running complex
applications it was found that performance was less than expected.  Further
investigation showed that these applications had cache miss rates much
higher than the standard benchmarks.  Some also had write patterns which
excited a bottleneck in the 5800 memory interface.

	The primary limitation of the DECsystem 5800 performance lies in
the interface between the 5800 and the XMI, rather than in the XMI itself. 
To minimize development time, the XMI interface of the VAX 6200/6300 was
used for the 5800.  This interface has a limitation of about 8 MB/second
total for XMI transactions.

	Another limitation in the initial 5800 design was the cache fill
size of the primary cache.  The 5800 has a 2 level cache.  The primary
cache is a 64KB D / 64KB I cache with an access time of 20ns and a fill
size of 4 bytes.  The secondary cache is 256KB mixed I and D with an access
time of ~400ns and a fill size of 32 bytes.  Because of the long access
time to the second level cache, the fill size of the primary cache is
inadequate.

	A change to the 5800 design has been made to increase the fill size
of the primary cache to 32 bytes.  Due to the scope of the change, it was
not possible to implement it in the systems shipped during the months of
December and January.  This design change speeds up most real applications
(but not simple benchmarks), by 15-20%.  The design change will be made in
all systems shipped starting in February and updated modules will be
distributed to all customers who received the December/January systems in
the April/May timeframe.

	With the cache fill size ECO, the DECsystem 5800 has performance
approximately equal to the 3100 and 5400.  Applications which hit well in
the cache will perform better than the 3100/5400 while those with very high
miss rates (or high scattered write rates), will perform somewhat worse
than the 3100/5400.

	The set of programs selected for inclusion in the SPEC benchmark
suite are fairly complex programs typical of most technical applications.
The following table compares the DECsystems and some competitors.  Other
than the first two columns which are execution times in seconds, all
numbers are performance as compared to a VAX 11/780.  It should be noted
that the 5800 is fastest on 3 programs, the 5400 on 4 programs and the 3100
on 3 programs.

           780 sec 5800 sec   5800   5400   3100 M/2000 SS/3xx  DN10010 9000/834
gcc        1481.50   156.30   9.50  10.50  10.20  19.20  13.80    12.00    10.20
espresso   2266.00   141.80  15.90  13.60  11.70  18.10  11.60    12.90     8.90
spice     23951.40  2890.50   8.20   9.00   9.60  12.00  11.10     7.70     8.70
doduc      1863.00   155.60  11.90   9.80   9.00  17.60   8.30    23.00     8.70
nasa7     20093.10  2188.80   9.10  11.90  12.20  16.80  11.20    20.40     9.10
li         6206.20   502.80  12.30  13.30  12.90  23.60  11.20     6.70    11.70
eqntott    1100.80    76.30  14.40  12.80  11.10  17.80  12.60     7.80    10.10
matrix300  4525.10   687.50   6.50   7.00   6.00   8.40  14.40    21.80    10.50
fpppp      3038.40   274.30  11.00  11.90  10.40  20.10  13.00    32.00     9.00
tomcatv    2648.60   283.30   9.30  10.00  10.20  16.80   7.50    19.90     8.50
                            ------ ------ ------ ------ ------ -------- --------
SPECMARK                     10.50  10.80  10.10  16.50  11.30    14.50     9.50


	The variability of performance is highest for the 5800 due to it's
cache behavior.  For programs which hit well in the cache, the raw compute
speed advantage of the 5800 wins big.  For programs with poor cache hit
rates, the 3100 typically wins due to it's fast memory sub-system.

	It should be noted, that for this set of "real" programs, none of
these systems live up to their billed MIPs ratings.  This effect is caused
almost entirely by "real" cache miss rates.  The difference between
theoretical MIPs and real performance will widen in the future as CPUs
become much faster while memory sub-systems make only modest gains in
speed. 

	Unfortunately it is very difficult to predict how a program will
run on the 5800 without running it.  Contrary to popular belief, program
size has little to do with cache hit rate.  An identical problem, solved by
two different methods could have dramatically different performance
results.

	It is best to assume that 3100, 5400 and 5810 have very similar raw
compute rates and sell the systems based on their other attributes.  It is
important to note that the 5820 has nearly twice the throughput for
applications with a number of compute bound tasks.  A single task will have
an execution time similar to the 3100 and 5400, but the overall system
throughput will be higher.

	The 5800 series is ideal for customers who need the expandability
of additional processors, memory and I/O channels.  For applications
requiring large amounts of physical memory, ELAPSED run time on a 5800 can
be several times faster than a memory starved 3100 or 5400.  Raw CPU
seconds will continue to be similar, but there will be far less idle time
on a system where memory paging is minimized.

	The situation we currently have with the line-up of DECsystem
products is very similar to our VAX line-up at various times over the past
few years.  The advent of low priced micro-processors have made it possible
to put the same raw compute power on the desktop as we place in the
computer room.  The difference in performance is minimal for single copies
of modest sized programs.  The real difference comes in the "system"
performance of the various machines when subjected to a real workload. 
Through multiple processors, large amounts of memory and large amounts of
I/O, the DECsystem 5800 does have a significant place in Digital's RISC
family.  It is important to understand the strengths as well as the
weaknesses of our systems in order to properly position them against each
other and especially against our competition.

Brian Allison


    
T.RTitleUserPersonal
Name
DateLines
84.158xx INFOKERNEL::BLANDtoward 2000 ...Tue Feb 06 1990 05:46216
+---------------------------+TM
|   |   |   |   |   |   |   |
| d | i | g | i | t | a | l |              TIME DEPENDENT CASE	
|   |   |   |   |   |   |   |
+---------------------------+


 
      TITLE:Announcing the DecSystem 5810    DATE: 05-Jan-1990

      AUTHOR: Bill Peters                       TD #: 000179
      DTN: 293-5887
      ENET: MSBCS::PETERS                      CROSS REFERENCE #'s: NONE
      DEPARTMENT: CSSE 		              (PRISM/TIME/CLD#'s)  

      INTENDED AUDIENCE: U.S/EUROPE/GIA        PRIORITY LEVEL: 1
      (U.S./EUROPE/GIA)                         (1=TIME CRITICAL,
                                                 2=NON-TIME CRITICAL)
      =====================================================================


********************************************************************************
*                                                                              *
*        A N N O U N C I N G   T H E   D E C S Y S T E M   5 8 1 0  !!!        *
*                                                                              *
********************************************************************************

                     IMPORTANT FIELD INTRODUCTION NOTICE
                     -----------------------------------

The DecSystem 5810 began shipping in limited volume on December 6th, 1989. The
following message relates important notes, both technical and non-technical
for the field support of this product. Please forward to your widest
distribution.

IF YOU NEED HELP:
----------------

Notesfile:  A notesfile exists for discussion of current 5400 and 5800 topics.
You will find it on SASE::DECSYSTEMS.

Support/Other:

Escalate as with any released product, but if your needs are time critical,
or an answer can't be found... call me direct, Bill Peters, 508-264-5887, or
send mail to MSBCS::PETERS. A support area with world read exists on 
MSBCS::DISK_PETERS:[000000.support] containing various notes.


TECH-TIPS:
---------

1. RBDs fail if invoked immediately after shutting down Ultrix or when run
   in random sequences.

   - Before beginning an RBD test session, execute an init sequence either
     by typing INIT or pressing the control panel button.

2. 5820 Support Statement. Some systems have been shipped under waiver as
   5820s, but these will not run the 2nd processor without V4.x Ultrix.

   - These CPU boards should be left in the machine until SMP upgrades and
     V4 software is available. However, the following warnings should be
     understood.

   - If there is a self-test failure in either of the CPUs, the system will
     (most likely) fail to boot. The failed processor must be removed from
     the system, BUT do not take it off the customer's site until a replace-
     ment can be found. Remember, functional or not, they own it.

   - If the EEPROM image does not match the ROM version a message will print
     saying that the console patch area is not usable. This can be corrected
     in the field in the same manner as a VAX 6000. However, the system will
     not boot until this problem is corrected. (See the console release notes
     in the support area (MSBCS::disk_peters:[000000.support])).

3. CACHE PARITY problems. The caches on the CVAX module (2nd level) and the
   R3000 module (1st level) have some unique problems related to R3000 
   functionality/bugs. Cache parity errors are not detected or reported.

   1st level cache errors:

   - These errors will automatically cause the CPU to perform a read miss
     cycle and bring the requested data into the R3000 buffers from external
     memory (or 2nd level Cache). There is a bit in the CPU %status register
     that will set indicating a parity error has occured (PE). Unfortunately,
     a timing problem in the R3000 read cycle causes spurious PE indications
     rendering the whole scheme useless. The result of this is that the only
     way to determine that the first level cache is deteriorating is upon
     recieving severe performance complaints. 1st level cache errors do not
     cause data corruption.

   2nd level cache errors:

   - The R3000 does not check CDAL parity on a read miss cycle. Consequently,
     if a read hit occurs in 2nd level cache and the data is corrupt, the
     R3000 will consume it. This has two potential outcomes:

	1. The system is in an I fetch cycle and the resulting corruption
	   creates a reserved instruction fault. These should result in a
           panic trap and an exception frame would be found both on the
           console and in the error log.

	2. The system is in a D fetch cycle and the corruption causes a
           wrong number in a calculation or a bad branch offset, etc. In
	   one case you might actually see a wrong number at the application
	   level, but most likely you will see untracable file corruption
	   or system crashes. On a system crash there is also no likely
	   traceable pattern since such events would be totally random.

   These caches are to be fixed by April 90 with a mandatory retrofit FCO.
   In the meantime, they have been strenuously screened in manufacturing to
   ensure that the infancy has been removed from the cache rams.

   CORRECTIVE ACTION:

   All crashes should be persued as diagnosable system events. (see Al Delorey's
   paper on Ultrix/RISC crash debugging, also in support area.)
   File system corruption is quite common when Ultrix systems go down
   unexpectedly, so file system corruption alone is not a symptom of bad
   caches. RBD 5 can be used to exercise the KN58 caches and try to
   catch a bad RAM. Subtests 22 thru 27 should also be selected as these do not
   run by default. RBD 4 can be run to concentrate on just the second level
   cache, but none of the subtests run by default so you must select one.
   Test 7 is the data ram test.  (See Options and Maintenance Manual). 

   If you elect to replace a CPU as a troubleshooting step, DO NOT RETURN
   THE CUSTOMER'S CPU TO LOGISTICS, UNTIL YOU VERIFY THE FIX. Reason: These
   modules are not repairable and if simply replaced for troubleshooting
   reasons the available FS stock will be rapidly depleted.


Non-Technical Notes:
--------------------

All manuals and diagnostics are orderable today by using the part numbers
provided here (except as noted). Branch Starter Kits are on the way, but
if you do not see one there is only one thing you really need to have to
get by.

Each system ships with a VDS tape that is compatible with the 5810. The
latest 6300 diagnostics will still run on this machine PROVIDED you use
the VDS supplied by the 5810 operations kit.

NOTE: You can build a bootable VDS partition on an Ultrix disk. See the
Release Notes (support area) for details.

BRANCH STARTER KIT:
------------------

     -----------        READ_ME_FIRST.DS5800     ! This memo.
     EM-01851-01        DEC-5800 FIELD MAINTENANCE PRINTSET
     EK-580AA-MG        DEC-5800 Options and Maintenance (Field Serv. only)
     AA-FK99B-TE	DEC-5800 VDS RELEASE NOTES
     AQ-FK98B-DE        DEC-5800 VAX DIAGNOSTIC SUPERVISOR & CMPLT DIAG TK50
     -----------        Console Release Notes V1.0 by Gary Grebus
     -----------        Ultrix/RISC Debugging by Al Delorey

DOCUMENTATION NUMBERS
---------------------

     EK-580AA-OM           DEC-5800 Owner's Manual
     EK-580AA-IN           DEC-5800 Installation Guide
     EK-580AA-TM           DEC-5800 System Technical User's Guide (Not @ FRS)
     EK-580AA-MG           DEC-5800 Options and Maintenance (Field Serv. only)
     EK-580AA-UP           DEC-5800 CPU/Memory Installation Manual (Not @ FRS)
     MP-01851-01           DEC-5800 FIELD MAINTENANCE PRINTSET
     EM-01851-01           DEC-5800 SELF-MAINTENANCE PRINTSET
     

FIELD SERVICE KIT NUMBERS
-------------------------

     00-Z3990-HW        DEC-5800 FIELD SERVICE COMPLETE DIAGNOSTIC KIT
     AQ-FK98B-DE        DEC-5800 VAX DIAGNOSTIC SUPERVISOR & CMPLT DIAG TK50
     AQ-FL01B-ME	DEC-5800 VAX DIAGNOSTIC SUPERVISOR - CONSOLE TK50
     BB-FL04B-DE        DEC-5800 VAX DIAGNOSTIC SUPERVISOR & CMPLT DIAG MAGTAPE
     AA-FK99B-TE	DEC-5800 VDS RELEASE NOTES


KN58A-AA consists of: 
---------------------
	
	T2025-0		X3PB (R3000 CPU module)			Qty=1
	T2026-0		X3PA (Hyperion Upgrade CPU module)	Qty=1
     	20-32062-01	D section Interconnecting PWB           Qty=1
     	20-32061-01	E section Interconnecting PWB           Qty=1


BASIC OPERATIONS KIT [BT-ZL302-C5]
----------------------------------
 
 This is the box from SDC, delivered with the system. The contents of the kit,
 and kit numbers have all been confirmed by the SDC and diagnostics groups.

   BT-ZL302-C5 consists of: 
	
 	EK-580AA-OM	DEC-5800 Owner's Manual			Qty=1
 	EK-580AA-IN	DEC-5800 Installation Guide		Qty=1
	AQ-FL01B-ME	TK50 CONSOLE w/ the following data:	Qty=1

		 VMB.EXE		! VMB
		 DIAGBOOT.EXE		! 2ndary bootstrap
		 ELSAA.EXE		! Isis Diag Supervisor
		 ELSAA.HLP		! VDS help
		 EVSBA.EXE		! Autosizer
		 EVSBA.HLP		! Autosizer help
     		 EVGDA.EXE		! CI EEPROM utility
     		 EVGDA.HLP		! CI EEPROM utility help
		 EVRLB.EXE		! RA70/RA60/80/81/82 Formatter
		 EVRLB.HLP		! Formatter help
		 EVRLK.EXE		! Bad Block Replacement Utility
		 EVRLK.HLP		! Bad Block Replacement Utility Help


                     *** DIGITAL INTERNAL USE ONLY ***
84.2ULTRIX V3-1CKERNEL::BLANDtoward 2000 ...Tue Feb 06 1990 06:3060
================================================================================
Note 12.0                BZ Ultrix V3-1C rel RISC update              No replies
CSC32::J_MACGOWN "PS-HW>BOOT/R5:10 Colorado_springs" 55 lines   5-JAN-1990 03:36
--------------------------------------------------------------------------------

Subj:	BLITZ_ULTRIX_V3-1C_release_RISC_update

**************************************************************************
                 DIGITAL EQUIPMENT CORPORATION CONFIDENTIAL
                 ------------------------------------------
             F O R      I N T E R N A L      U S E      O N L Y
***************************************************************************
      TITLE: ULTRIX V3.1C Release              DATE: 26 December 1989

      AUTHOR: Jean Pinard                      TD #: 000167
      DTN: 381-0509
      ENET: guru::pinard                        CROSS REFERENCE #'s:
      DEPARTMENT: ULTRIX CSSE                   (PRISM/TIME/CLD#'s)  

      INTENDED AUDIENCE: All                    PRIORITY LEVEL: 1
      (U.S./EUROPE/GIA)                         (1=TIME CRITICAL,
                                                 2=NON-TIME CRITICAL)
      =====================================================================



      PROBLEM: 

	Performance problems on DECsystem 5400 and 5800, and new
	release of ULTRIX-32, replacing V3.1A Software.  

	A number of bugs were found in the network code. Its hard to
	say one way or another that a customer will see a difference.
	The nature of the bugs found, cause packets to be dropped,
	which in turn caused retransmissions.  This class of bug was
	on all the risc systems. Also the 5400 and 5800 were accounting
	for space in the socket buffer with an algorithm that was based
	on `vaxisms'.  In testing this had a greater effect.
  

      RESOLUTION/WORKAROUND:

	ULTRIX-32 V3.1C includes both performance enhancements and
	bug fixes. V3.1C is scheduled to FRS on 12/28/89. V3.1C is
	also replacing V3.1A and is being shipped to all customers
	who have received V3.1A.

	SSB has had a supply of the V3.1C kits to fill pre-release
	orders for the DECsystem 5810 since 12/08/89.  The replacements
	for the V3.1A kits may have already have been shipped or are
	currently in the process of going out.


      ADDITIONAL COMMENTS:

	Any one planning on ordering V3.1A (QA-VYVAL-H5) should now
	order V3.1C (QA-VYVAM-H5).


                     *** DIGITAL INTERNAL USE ONLY ***
84.3New DECsystems/DECstations.COMICS::TREVENNORA child of initTue Aug 14 1990 21:5818
    
    
    
    For those of you following the DECsystems/DECstations saga....
    
    The DECsystem 5900 (CMAX) has been cancelled. The subsystems could not 
    keep up with the CPU sufficiently well to realise its full performance, 
    and Mipsco could not deliver sufficient quantities of the 50 MIPS CPU 
    in time to make the box competitive.
    
    The MIPSFAIR-2 and the MIPSMATE will, however be amongst us within the
    next 8 weeks or so. The MIPSMATE is a 30 (RISC) Mips workstation - 
    reckoned to be about 20 VUPS, based on the ECL R3000 chip from Mipsco.
    The MIPSFAIR-2 is a follow-up product to the DECsystem 5400, and will
    deliver 25 (RISC) Mips) - or about 18 VUPS. 
    
    Alan T.