| 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 |
The DECsystem 5800 series has finally started shipping. We expect
to convert the ULTRIX group 6310 to a DECsystem 5820 in January
(any volunteers to assist hardware wise!?). The DS5800 shipment
is about two months behind schedule, mainly because of the various
speed matching problems with existing components of the system -
I gather.
This is a blitz which has come out from Bill Peters to the Various
ULTRIX mailing lists. I place it here for your reference, and further
re-distribution as required.
Alan T.
*** DIGITAL INTERNAL USE ONLY ***
********************************************************************************
* *
* 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 ***
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 80.1 | 5800 | KERNEL::MOUNTFORD | Fri Jan 12 1990 09:07 | 149 | |
Moved by moderator:
-------------------
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
| |||||