| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2653.1 | I said my piece. | 34873::SCOTTG | Greg Scott, Minneapolis SPS Support | Sun Sep 05 1993 02:05 | 80 |
| Here's mine. I did some research and found a bunch of PR people. Feel
free to use my distribution list.
If you like Digital defending itself, and you want to encourage more of
this, send your cards and letters!
- Greg
From: ANGLIN::SCOTTG 4-SEP-1993 23:58:17.58
To: @PR_KUDOS.DIS
CC: SCOTTG
Subj: Kudos for a job well done - Digital finally defends itself!
I would like to give a heart-felt THANK YOU to Digital's PR people for
defending Digital's integrity in the press recently.
Let me explain:
On Aug 10, we had a meeting with our local DECUS LUG here in
Minneapolis. My copy of the August 9 "Digital News And Review", our
favorite trade paper, also arrived that morning. I wanted to read it,
but didn't get the chance that day.
Late in the afternoon, the DECUS people arrived and we all sat down in
the meeting room. Almost immediately, they started barking questions
about the latest column from James Moody in the August 9 DN&R. Judging
by their questions and comments, Moody printed some statements that
were down right false.
Since I had not yet read Moody's column, the best I could tell them was
not to believe everything in the press.
I read Moody's column the next day. It was a true hatchet job.
Moody's facts were all wrong, and the conclusions he drew from his
incorrect facts were also bogus.
Based on conversations with several of my peers, I learned people all
over the USA had customer experiences similar to mine because of that
article. Moody's column damaged Digital's reputation everywhere.
Just this week, I opened the latest DN&R and turned to the editorial
page. I believe the date was August 23. I read the letter to the
editor from Judith Abrahamovich and my heart started to pound. Not
only did Judith aggressively defend Digital, she did a great job of it!
It is about time somebody stood up and defended our company against
these defamatory articles. In my 12+ years with Digital, I cannot
remember Digital ever defending itself in the press. Judith's letter
was like a breath of fresh air. It even brought back some of the pride
I felt for our company in years past.
Having been critical of Digital's management in the past, I want to
give a hearty THANKS for this letter. This was a good job.
After all these years, it feels good to see Digital finally show some
backbone. I want you to know those of us in the field who deal with
Digital's customers every day appreciate this new attitude. Keep up
the good work!
- Greg Scott
Software Consultant
OpenVMS Partner
Minneapolis
distribution list:
nm%VMSMKT::JUDITH ! Judith Abrahamovich, press relations
nm%HYEND::RYOUNG ! Rich Young, corporate PR
nm%MEMIT::MAHER_J ! Jeannette Maher, corporate PR
nm%ASABET::SHIPMAN ! Janet Shipmen, corporate PR
nm%ASABET::J_GIBSON ! Jeffry Gibson, corporate PR
nm%MSBCS::VARLEY ! Jack Varley, corporate PR
MTS$::"MLO::CHARLIE HOLLERAN" ! Charlie Holleran, vp corporate PR
nm%MSBCS::SWANTON ! Ken Swanton, OpenVMS Marketing
nm%MILPND::R_JOLLS ! Bob Jolls, vp Marketing
nm%MSBCS::DEMMER ! Bill Demmer, vp CSG
MTS$::"MLO::ED LUCENTE" ! Ed Lucente, vp Sales
MTS$::"MLO::BOB PALMER" ! Bob Palmer, CEO
|
| 2653.2 | Beginning of positive trend, or flash in the pan? | 4106::GARROD | From VMS -> NT, Unix a future page from history | Sun Sep 05 1993 12:07 | 135 |
|
Re .0
Before you get too excited. I agree that this is a step in the right
direction. But unfortunately the old standard of stealth public
relations is still alive and well.
The key test will be to see if what happened in .0 is the start of a
trend or just a flash in the pan. Read the attached to see a very
recent example of the old thinking.
Dave
<<< VAXWRK::$1$DUS6:[NOTES$LIBRARY]ALPHANOTES.NOTE;3 >>>
-< Alpha Support conference >-
================================================================================
Note 2678.0 DATAMATION letter to the editor 34 replies
ARNOLD::ECK 52 lines 18-AUG-1993 09:15
--------------------------------------------------------------------------------
The August 15, 1993 edition of DATAMATION has a letter to the editor
from Thomas P. Oberst, Strategic Technology Inc., Sherborn, MASS.
He comments on DATAMATION's article "Can Digital Sustain Alpha's
Edge?", in the March 1, 1993 edition.
I will not post the entire article, rather highlights and his key
points for discussion. Misinformation is dangerous and perhaps our PR
department would like to send DATAMATION a counterpoint.
"..... The SPECmark 89 performance figures that you published were only
for Alpha running VMS! These numbers cannot be extrapolated to other
operating systems such as OSF/1 or Windows NT. Digital had to spend
eight months modifying VMS, VMS libraries and VMS internals to get the
performance numbers they did. Internally, as late as December 1992,
tests showed that a 20MHz (not a typo) Alpha running Ultrix or OSF/1
ran only marginally better than the earlier, Mips R3000-based,
Decsystem family, which Digital still offers. When you say that
Digital is a leader in price/performance, you shoudl qualify that by
saying that Digital is the price/performance leader only in the VMS
operating system space.
Moreover, you report that Alpha is a 64-bit machine. It does have a
64-bit architecture, the same way the Mips R4400 and the Sun Version 9
SPARC are 64-bit RISC architectures. The truth is that the 21064 chip
only has 41 bits, which are usable for address space translation from
the chip's Translation Lookaside Buffer. Current users could not
address 64 bits even if they had applications allowing it.
.....DEC has not published benchmarks becouse the performance of Alpha
is a disaster. It is bad for VMS and terrible for OSF/1 or Ultrix or
Windows NT. A large part of the reason for DEC's finally deciding to
drop Ultrix as a supported operating system for Alpha is the fact that
performance was almost equal to the performance of the previous
generation R3000 running at 50MHz.
.......Moreover, it is DEC and not HP, Sun or IBM that is new to the
fast-moving RISC space. ..... Finally, there are some strong technical
arguements as to why Alpha's current implementation will not perform as
well in running process-intensive or thread-intensive commercial
applications. I would be very happy to cover these at another time if
you believe they would be of value.
Bob Palmer is an outstanding leader, and DEC has the talent and
depth to win in the RISC space. Alpha has great potential. However,
DEC should not be projecting that potential ahead of its time. Alpha's
success will be highly dependent on how fast DEC can learn and
implement and improve Alpha. Time to market over the next 10 years
will be the key. Making Alpha suitable for UNIX is the other. Here
they are clearly lagging."
-------------------------------------------
Comments?????????
<<< VAXWRK::$1$DUS6:[NOTES$LIBRARY]ALPHANOTES.NOTE;3 >>>
-< Alpha Support conference >-
================================================================================
Note 2678.27 DATAMATION letter to the editor 27 of 34
MSBCS::BHANDARKAR "Good enough is not good enough" 56 lines 2-SEP-1993 13:38
-< Unpublished Response >-
--------------------------------------------------------------------------------
Corporate PR is unwilling to send a response. Here is a copy of the response
that I had drafted. Feel free to use this information if a customer asks about
the letter.
Dileep
In the August 15, 1993 issue of DATAMATION, Thomas P. Oberst, a former Digital
Equipment Corporation employee, provided some highly inaccurate information on
the performance of our Alpha AXP systems.
We, Digital Equipment Corporation, first released SPEC benchmark
results based on the OpenVMS AXP operating system in November of 1992.
When our DEC OSF/1 AXP operating system was released in March 1993
(2 weeks after your feature article on Alpha's Edge), we released
SPEC benchmark results based on that operating system. Our DEC OSF/1 AXP
results were about 10% faster than the previously published OpenVMS AXP
results for the SPEC integer benchmarks; floating-point results were
comparable. Also, Digital never had a 20 MHz Alpha system that
Mr. Oberst claims to have seen internally. Our Alpha AXP systems' clock
rates range from 133 MHz through 200 MHz.
We are extremely proud of the outstanding performance of our Alpha AXP systems.
We were the first vendor to break the 100 SPECint92 barrier in November 1992,
and that feat has not yet been matched by any of our competitors. Our DEC 3000
Model 500X AXP running DEC OSF/1 AXP is the world's fastest UNIX
workstation based on its SPECint92 and SPECfp92 ratings.
Our performance leadership is not confined to SPEC CPU intensive benchmarks. Our
DEC 10000 Model 610 AXP has the distinction of being the fastest machine
to perform the 100 megabyte SORT benchmark defined by database experts
in the December 1985 issue of DATAMATION. As further proof of our commercial
performance, we recently announced the world's fastest TPC-A results for a
relational database on a uniprocessor system. We know of no other new
architecture that has established such widespread performance leadership
within its first year of deployment.
Presently, the Alpha AXP product family includes five workstation models, three
multiprocessor servers, and one personal computer. Several of these products
have won awards for excellence at computer shows and in industry publications.
This is only the beginning; several performance enhancements through
compiler improvements, operating system enhancements, new hardware platforms,
and faster chips are planned for the near future.
Finally, while Alpha AXP is relatively new to the market, RISC is not new to
Digital. I have been personally involved in RISC projects at Digital for almost
10 years, as have others. The vast experience that our designers have
accumulated on previous RISC projects has allowed us to achieve a leadership
position with Alpha AXP at introduction and will enable us to sustain it in the
future.
Dileep Bhandarkar, Ph. D.
Technical Director
Computer Systems Group
Digital Equipment Corporation
|
| 2653.3 | | 2082::LIONEL | Free advice is worth every cent | Mon Sep 06 1993 07:28 | 18 |
| In 1983, a former Digital VP who had moved to a competitor wrote
a letter to Datamation slamming the then-new MicroVAX I for not
being compatible with existing VAX applications. With the blessing
of Corporate PR, and the necessary reviews by Consulting Engineers,
I wrote a letter of rebuttal that was published in a subsequent
issue.
Over the years, I HAVE seen a number of similar letters published,
though I admit that they are far fewer than they ought to be,
especially considering that some of our strongest competitors
(IBM, for example), waste no effort in refuting misstatements
made about them in the press.
I agree that Digital as a corporation is nowhere near aggressive
enough in responding to misinformation. We can't afford to be
trod on like this.
Steve
|
| 2653.4 | So let's make sure this time isn't a flash in the pan. | ANGLIN::SCOTTG | Greg Scott, Minneapolis SPS Support | Tue Sep 07 1993 13:15 | 6 |
| I propose we all use this opportunity to make sure a good trend starts.
Let's do a MASSIVE letter writing campaign to everyone in PR and all
the zillions of vice-presidents who have anything to do with it. Maybe
a little positive reinforcement will do some good.
- Greg
|
| 2653.5 | What was the article about? | TERSE::FANTOZZI | | Tue Sep 07 1993 13:25 | 6 |
|
What exactly did Digital News & Review write in the article that caused
a huff??
Mary
|
| 2653.6 | | DYPSS1::COGHILL | Steve Coghill, Luke 14:28 | Tue Sep 07 1993 14:19 | 4 |
| Didn't Digital recently send a letter to our customers explaining
Sun's lastest tissue of lies concerning their products vs. the Alpha
AXP? I thought that was unprecedented. It seems that corporate is
coming out of their passive shell.
|
| 2653.7 | Congrats Judith...Thanks from Dallas | DPDMAI::WISNIEWSKI | ADEPT of the Virtual Space. | Tue Sep 07 1993 14:48 | 34 |
| Even a cornered dog will bite;-)
Judith's letter was very well written and address the inaccuracies
that DN&R had regarding Version 6 of OpenVMS -- Thanks Judith.
Now as to PR.
It's my opinion that Corporate should have folks doing this by
identifying misstatements in the press or article and pushing
for a correction or a retraction.
As was said before other companies waste no time if anything is
erroneous about their products we should be no different.
This should not be a drawn out process or "When we become aware
of the problem"
There should be a full time, staffed position (technical marketing)
who reads the trades, knows the editors, and most importantly
the Advertizing Sales people for those rags and is tasked with
rebutting or putting a spin on any, that's A-N-Y negative article
in the press about Digital.
There was a rumor about the IBM person who was tasked with making
sure that IBM was always in the "In the News" column of the WSJ.
As the FOAF relayed it to me the day after IBM had no article (good,
bad, or indifferent) in that column that person was fired and replaced
by another PR person...
Sorry this is war and we need to be as agressive as it takes to get
our point of view out...
John Wisniewski
|
| 2653.8 | We WANT corporate to come out of their passive shell! | ANGLIN::SCOTTG | Greg Scott, Minneapolis SPS Support | Tue Sep 07 1993 19:28 | 33 |
| James Moody wrote the offending DN&R column in the Aug 9 edition.
Judith's rebuttal is a letter to the editor in the Aug 23 edition.
re .6:
> Didn't Digital recently send a letter to our customers explaining
> Sun's lastest tissue of lies . . .
Oh, boy, I just can't resist this one. Nope. Nobody from corporate
put that Sun response together. And nobody from corporate sent any
letter to our customers on that topic.
The Sun response came from the Minneapolis local office. I know that
for a fact because that's where I live. And we wrote the dad-blamed
thing here if you're talking about the one I think you're talking about.
We are in the middle of a battle with Sun at a major customer here. We
needed a white paper that would answer Sun's latest round of lies. We
couldn't find anything from corporate to meet our needs. So we did our
own with lots of help from good people all over the company. I spent a
few late nights putting the whole thing together. Once we had it done,
we shared it with the rest of the company. Anyone who wants a copy is
welcome to it.
Why do you think I'm trying to encourage EVERYONE to write to the PR
people now and reinforce the good behavior from Judith's response? The
***COMPANY*** needs to do more of what Judith did, so ***WE***
don't have to do it on our own at night.
So write your letters and post 'em in here! It seems to me we have an
opportunity to make a difference if enough people care.
- Greg
|
| 2653.9 | More on DATAMATION | CSOA1::ECK | | Wed Sep 08 1993 10:15 | 17 |
| The two notes posted from the Alpha Support Conference in .2 of this
string needs further comment. As you could probably tell several notes
in the Alpha Support Conference were NOT posted (Editorial freedom??).
PR immediately jumped on the issues raised in a Letter to the Editor of
DATAMATION from a former Digital employee. It was determined by PR that
a war of Letters to the Editor would not be productive and a better
strategy would be to approach the Editor and review the facts
personally. The objective of this approach would be for DATAMATION to
write a favorable and positive article on Alpha.
INHO, our PR department is doing a much better job than in previous
years. We in the field are now copied (via US Communications) on public
relations articles prior to their release to publications. I'm seeing
more and more news released about Digital products and services in the
rags I read. Our ad compaign for PC's dominates popular publications.
Rumor control and damange control is tough, but give our folks a
chance.
|
| 2653.10 | Mnemonic device | DECC::AMARTIN | Alan H. Martin | Wed Sep 08 1993 12:30 | 7 |
| Re .0:
>I don't remember if it's libel or slander when the press publishes damaging
>stories that are just not true, ...
Slander is Spoken.
/AHM
|
| 2653.11 | All the lies that are fit to print | FUNYET::ANDERSON | OpenVMS Forever! | Wed Sep 08 1993 12:46 | 22 |
| James Moody's "OpenVMS Tactics" column in the August 9 issue of Digital News and
Review contained the following:
Digital admitted at DECUS in Atlanta that OpenVMS version 6.0 does not
contain all of the features in the current release of OpenVMS version 5.5-2,
and that it would not have complete compatibility for at least a year. How
can a new release of the operating system have fewer features than the
current one? The answer has a lot to do with Alpha. One of the most
commonly asked questions in Atlanta was whether or not to install OpenVMS
version 6.0. The answer is going to depend upon a number of conditions, but
might very well be a resounding "NO!"
Of course, this is not true, as OpenVMS VAX V6.0 is a superset of OpenVMS VAX
V5.5-2. Mr. Moody apparently confused the features in OpenVMS AXP V1.5 with
those in OpenVMS VAX V6.0. Starting with the wrong facts, the rest of the
column had even more incorrect facts and conclusions.
I could not believe that an article like this could appear in a magazine like
Digital News and Review. Spreading ridiculous comments like these about OpenVMS
is obviously bad for Digital and I'm also glad that we spoke up for ourselves.
Paul
|
| 2653.12 | "Some" truth in what J.M. said? | CSC32::M_BLESSING | Mike Blessing, CSC/CS Alpha Support | Wed Sep 08 1993 13:28 | 20 |
| I don't know what James Moody was trying to say (and I don't
have his column in front of me), but I think there is "some"
truth in the quotes I have read.
There ARE features that exist in the 5.5-2 family of versions
that are missing from 6.0, that will re-appear in 6.1.
Some examples:
o can operate in mixed-arch cluster with AXP
o will (without extra effort) build images that can
be translated to run on AXP
o support for Media Management Extensions
o support for VAX 4000 Model x00A (in 5.5-2H4)
o support for DEC SCSI TCQ driver kit
o support for DEC LAN Device driver kit
There are also some features in 5.5-2 and missing in 6.0 that
probably won't be coming back later:
o ability to run old queue manager
o support for VAXft machines (VAXft 810 supported by 5.5-2HF)
|
| 2653.13 | DN&R == National Enquirer? | ODIXIE::SILVERS | dig-it-all, we rent backhoes. | Wed Sep 08 1993 20:23 | 14 |
| Yup! - I 'discovered' some of what is mentioned in .-1 when I upgraded
the machines in our office.....
While Moody may write like a 'National Enquirer' reporter, our PR folks
responding with somewhat less than accurate letters to the editor may
do more harm than good.
I have to 'present' VMS V6.0 to the Tallahassee, FL DECUS LUG (the
state of florida does alot of their business on DEC (ooops, digital)
gear) next week. I'm still wrestling with how I'll handle questions about
moody's article and about the DN&R 'benchmarks' concerning the DEC
2000/300 vs. the higher end servers.
Enjoy, Ds.
|
| 2653.14 | DN&R DEC 4000 Performance "White Paper" | MAY11::WARCHOL | | Thu Sep 30 1993 17:21 | 365 |
| From: PSDVAX::PSDVAX::AJGAONKAR "DTN: 223-8927, ESB Prod. Mgmt 29-Sep-1993 1604" 29-SEP-1993 16:07:55.63
To: LIDINGTON,COLLINS,LANDO::ROBIE,LANDO::LONG,BLOUNT
CC: WRKSYS::SAILOR,WRKSYS::BREDA,MSBCS::QUATROMONI,@COBRA_CORE_TEAM.DIS,AJGAONKAR
Subj: FYI:"White Paper" response to DN&R articles on DEC 4000 - Pls distribute
DN&R DEC 4000 Performance "White Paper"
=======================================
By: DEC 4000 Engineering
In the 13 September edition of Digital News & Review an article was
published comparing the DEC 2000-300, the DEC 3000-400 and the DEC
4000-600 servers. This article is the culmination of several previously
published articles on Alpha AXP server performance testing.
This article has caused consternation within the installed base,
particularly with customers who are in the process of accepting delivery
of DEC 4000 servers or in the process of issuing purchase orders for
new DEC 4000 servers.
Unfortunately, the article is inaccurate in several critical ways. Thus
the conclusions are incorrect. The purpose of this White Paper is to
provide corrections to the inaccuracies and to provide direct rebuttal
data that can be used to reassure customers that the DEC 4000-610 system
clearly provides significantly higher disk performance than the DEC 2000
for applications where a single disk drive configuration is inadequate.
The DEC 2000 server remains the Alpha AXP server of choice for
applications not requiring the large storage, physical memory and faster
CPU performance of the DEC 4000.
In order to understand the inaccuracies within the DN&R article, an
understanding of the DEC 4000 I/O subsystem is necessary. This paper is
organized to point out the areas where the DN&R article test process
produced misleading results, to provide a basic understanding of the
DEC 4000 I/O subsystem and to communicate base fast SCSI performance
information that was measured in our Engineering labs. In addition,
data is provided for Beta-test versions of the Futurebus+ IPI disk
controller from Genroco, using Elite-3 disk drives from Seagate.
This data shows the impressive performance achievable with Futurebus+
based I/O controllers.
Quotes and Responses from Digital News & Review Articles
========================================================
Quote
-----
DN&R, August 23, 1993 page 57 "DEC to serve up OpenVMS on Alpha PC"
"But DN&R Labs beta tests of the [DEC 2000 Model 300s] EISA-based
I/O subsystem show that its SCSI I/O performance, which depends on
Adaptec's EISA-bus card, outdistanced that of a DEC 4000 Model 610
and a DEC 3000 Model 400s using DEC's SCSI adapter. The 4610's
adapter uses the 128-bit Futurebus+ I/O bus."
Response
--------
DN&R does not understand the DEC 4000 I/O subsystem architecture (see
attachment 1).
+ There are two versions of the system I/O board, one that supports
DSSI/SCSI and one that supports fast SCSI. DN&R labs performed this
test with a single fast SCSI drive, but did not use the corresponding
fast SCSI adapter! The DEC 2000 system was configured with a fast SCSI
adapter which, as expected, provided higher performance.
+ The Futurebus+ I/O bus on the DEC 4000 is not 128-bits wide, it
is 64-bits wide.
+ The DSSI/SCSI adapter for the 4610 does not reside on the Futurebus+.
It resides on a separate local-bus on the system I/O board.
+ The performance achievable with a single SCSI drive would not saturate
the fast SCSI controller available on any of the systems - so
the test results are not representative of the "SCSI performance" of
any of the systems.
Quote
-----
DN&R, September 13, 1993 page 31 "A royal controversy over
controlling AXP interests?"
"With a separate processor in its I/O subsystem, like the mainframe-
class DEC 7000, the DEC 4000 sustained the highest level of QIO
processing at 8,200 QIOs - each averaging about four blocks in size
- per second."
Response
--------
The DEC 4000 and the DEC 7000 have intelligent I/O controllers to
reduce CPU overhead during I/O, but neither has a separate I/O
processor. This test, which was performed with a memory-resident RAM
disk, does not involve the I/O subsystem. The test is a measure of
CPU, cache and memory performance.
Quote
-----
"These benchmarks clearly identify the Futurebus+ adapter on the
DEC 4000 that handles I/O for both SCSI and DSSI devices as a
bottleneck. The tests which show a limit of about 2.8MB per second
on SCSI throughput, corroborate earlier results..."
Response
--------
These benchmarks clearly demonstrate that fast SCSI drives run faster
when you connect them to fast SCSI controllers! The measured read
bandwidth of the local-bus fast SCSI adapter on the DEC 4000 model 610
(using RZ28 drives) is 7.4MB per second per fast SCSI bus and 22.6 MB
per second for the entire I/O module (4 controllers) - see attachment 2.
Real Futurebus+ adapter performance, as measured on a Futurebus+ IPI
adapter from Genroco (currently in Beta test) comes to 14.1 MB per
second per adapter. Measurements with three of these adapters scales
to an aggregate of 36.1 MB per second.
A measure of the real DEC 4000 I/O performance was obtained using three
Genroco Futurebus+ controllers operating concurrently with the
local-bus fast SCSI adapter. The total disk read bandwidth measured was
a very impressive 58.3 MB per second !
Quote
-----
"With five ESE53 drives, the peak QIO load was only about 950 QIOs
per second, or about 2MB per second of user data."
Response
--------
There is no ESE53 drive, the DSSI solid state drive is the EF53.
In this type of test (small [2KB] QIO's) a single controller will be
QIO limited, not bandwidth limited. In their tests DN&R Labs connected
all five EF53 drives to one DSSI bus.
A more representative test, that takes advantage of the built in I/O
capabilities of the DEC 4000, would be to distribute the EF53 drives
across the four local-bus controllers, where EACH of the four
controllers can support up to about 1,000 QIO's per second. Such a
test would show QIO performance on the DEC 4000 at over 3400 (2KB)
I/O's per second - or the point where the CPU or the disks become
saturated.
Quote
------
"Adjusting for the overhead associated with the small QIO packets
generated by the Load benchmark, it appears the current I/O adapter
on the DEC 4000 can handle a maximum of about 900 to 1,000 QIOs per
second - a far cry from the system's potential of handling up to
8,000 QIOs per second."
Response
--------
This test really understates the QIO performance of the DEC 4000 I/O
module. The 900-1000 (2KB) QIOs per second is for only one of the
four DSSI/SCSI controllers on the DSSI/SCSI I/O module. The I/O module
can support over 3400 (2KB) QIO's per second. In lab tests, the
Genroco Futurebus+ IPI controllers demonstrated that they could
process 1400 (sequential,2KB) QIO's per second.
Please do not contact Digital News and Review directly. All issues or
comments to be directed to DN&R should be sent to Karen Quatromoni of
AVS Public Relations at MSBCS::QUATROMONI
For additional information and clarification of data presented in this
paper please contact:
Gary Lidington via VAXmail PSDVAX::LIDINGTON
Mike Collins via VAXmail PSDVAX::COLLINS
Kami Ajgaonkar via VAXmail PSDVAX::KAMI
Attachment 1
DEC 4000 Disk I/O Subsystem Architecture
========================================
The objective of the DEC 4000 I/O architecture was to provide high I/O
performance as a standard attribute of the system. To achieve this
objective, the DEC 4000 was implemented with four integral I/O
controllers using a dedicated high performance local-bus on a single I/O
module. For multiple disk drive configurations, typical of applications
that this system was designed for, the drives were expected to be
distributed across all the controllers to give the maximum possible I/O
performance. More I/O capacity was available through a Futurebus+ I/O
backplane where additional disk controllers (or other options) could be
added.
The local-bus is a chip level interconnect that resides on the system I/O
module. The four disk controllers that come with the DEC 4000 base system
reside on this local-bus - not on the Futurebus+. There are two
available I/O modules, one that has four DSSI/SCSI controllers and one
that that has four fast SCSI/SCSI controllers. Both versions of the I/O
module also contain a fifth "SCSI only" bus for connecting other
peripherals like tapes and CD readers.
The SCSI bus controllers on the local-bus are based on the NCR 53C710
chips running control scripts out of local RAM. The hardware difference
between the two I/O modules is that the DSSI/SCSI version adds DSSI
transceiver chips to each of the four disk controllers. The result is
that each controller can support either DSSI or SCSI disks. On the
DSSI/SCSI I/O module these transceivers make it necessary to limit the
bus speed to the maximum DSSI rate even when running in SCSI mode. This
restriction does not apply to the Fast SCSI version of the I/O module.
The Digital News and Review SCSI bandwidth numbers were taken using a
fast SCSI drive connected to the DSSI/SCSI version of the I/O module -
thereby limiting the drive to DSSI maximum transfer rates. On the other
Alpha systems in the DN&R article, this same drive was connected a SCSI
I/O controller allowing the drive to transfer at the higher rates of
either a standard or fast SCSI I/O bus. It should be noted that if the
DEC 4000 was configured without DSSI capability, using the fast SCSI I/O
module in the DN&R tests, the drive could be run at the fast SCSI I/O
rates.
The bandwidth bottleneck described in the article results from the
maximum transfer rate of a single DSSI bus (just over 3MB/s) running in
SCSI mode. Note that there are four of these busses on a DEC 4000 with a
DSSI/SCSI I/O module, so the total system disk bandwidth is four times
the single bus bandwidth or about 12MB/s.
DEC 4000 I/O performance using the fast SCSI I/O module in different
configurations and transfer sizes are shown in attachment 2. These
configurations and test conditions were chosen to illustrate both the
maximum bandwidth and maximum I/O rate of the individual controllers and
the entire I/O module. At the I/O module maximum I/O rate of about 3500
I/O's per second (using 2KB transfers) the data rate is only 7MB/s. Thus
the performance of the fast SCSI and DSSI/SCSI I/O modules, in terms of
maximum I/O rate, are comparable.
As a reference point, with random accesses the typical maximum I/O rate
for a single high performance mechanical drive is about 60 I/O's per
second. Typical solid state drives will have a maximum I/O rate of 500+
I/O's per second for random accesses.
The Futurebus+ is a module level interconnect with six backplane slots. A
disk controller that can be attached to the Futurebus+ is the Genroco IPI
controller. Each Futurebus+ IPI controller supports one IPI bus.
The DEC 4000 performance using the Futurebus+ IPI controllers in various
configurations and transfer sizes is shown in attachment 2 (note that
very large queue depths were necessary to determine the maximum I/O rate
for the controller as these drives were optimized for large transfers).
Both the local bus and the Futurebus+ can operate simultaneously.
Attachment 2 includes the disk read bandwidth measured for the entire DEC
4000 I/O subsystem.
Attachment 2
DEC 4000-610 Fast SCSI Performance
==================================
Local-bus fast SCSI controller performance
Controller read bandwidth was measured with RZ28 drives doing 127 block
(64KB) sequential reads across the entire surface of the platter. (queue
depth= 3)
Single fast SCSI drive - 4.8MB/s (drive limit)
Single fast SCSI contoller - 7.3MB/s
Two drives, two controllers - 9.6MB/s
Three drives, three controllers - 14.4MB/s
Four drives,four controllers - 19.5MB/s
For fast SCSI I/O module - 22.6MB/s
(8 drives total, 2 per controller)
Controller I/O's per second was measured with RZ28 drives doing 4 block
(2KB) sequential reads across the entire surface of the platter. (queue
depth= 3)
Single fast SCSI drive - 1075 I/O's per second (drive limit)
Single fast SCSI controller - 1210 I/O's per second
Two drives,two controllers - 1646 I/O's per second
Three drives,three controller - 2415 I/O's per second
Four drives, four controllers - 2824 I/O's per second
For fast SCSI I/O module - 3464 I/O's per second
(8 drives total, 2 per controller)
DEC 4000-610 IPI Performance (Beta test hardware)
=================================================
IPI controller read bandwidth was measured with Seagate Elite-3 drives
doing 120 block (60KB) sequential reads across the entire surface of the
platter (queue depth=3).
Single IPI drive - 10.6MB/s (drive limit)
Single IPI controller - 14.1MB/s
Four drives,two controllers - 26.7MB/s
Six drives,three controllers - 36.1MB/s
IPI controller I/O's per second was measured with Elite-3 drives doing 2
block (1KB) sequential reads across the entire surface of the platter.
(queue depth=64)
Single IPI drive - 1470 I/O's per second (drive limit)
Single IPI controller - 1765 I/O's per second
Three drives,three controllers - 4919 I/O's per second
DEC 4000-610 Total Disk I/O Performance
=======================================
IPI controller read bandwidth was measured with Seagate Elite-3 drives
doing 120 block (60KB) sequential reads across the entire surface of the
platter. (queue depth =3)
Fast SCSI I/O module read bandwidth was measured with RZ28 drives doing
120 block (60KB) sequential reads across the entire surface of the
platter. (queue depth =3)
Total system Disk read bandwidth 58.3 MB/s
IPI controller component 35.7 MB/s (6 drives, 3 controllers)
Fast SCSI I/O module component 22.6 MB/s (8 drives, 4 controllers)
|
| 2653.15 | Spread the good word? | GOTIT::harley | Pay no attention to that man behind the curtain... | Fri Oct 01 1993 11:07 | 4 |
| Should a sanitized (Ie, fix the NODE::USER mail addresses) version of
.-1 be posted to USENET?
/harley
|
| 2653.16 | Without having read it... | DRDAN::KALIKOW | Technology hunter\gatherer | Fri Oct 01 1993 12:17 | 2 |
| ... if it's a fact-based rebuttal of bad press, YESS!!!
|
| 2653.17 | Jensen finally opens VMS | MSBCS::BROWN_L | | Fri Oct 01 1993 12:34 | 4 |
| Now that VMS engineering is exposed to the real "open" world by
having their peripherals compete with PC peripherals on Jensen's
(aka DECpc AXP 150 aka DEC2000 model 300) EISA bus, you should
expect to see a lot more of these type of damage control memos...
|
| 2653.18 | Ask the author before reposting in public | HYDRA::BECK | Paul Beck | Fri Oct 01 1993 12:44 | 4 |
| re .15
I wouldn't post anything on the USENET without permission of the author.
|
| 2653.19 | I totally agree with .-1 | GOTIT::harley | Pay no attention to that man behind the curtain... | Fri Oct 01 1993 13:04 | 7 |
| re .-1
I totally agree, posting of mail to USENET without the author's
permission is extremely bad netiquette; I was more or less wondering
aloud how far_and_wide the memo would travel.
/harley
|
| 2653.20 | In my .16, I assumed (!?!) the author was asking the Q... | DRDAN::KALIKOW | Technology hunter\gatherer | Fri Oct 01 1993 14:20 | 1 |
| i.e., <blush>
|
| 2653.21 | | RCOCER::MICKOL | $SET DEC/BRAND_IMAGE=DIGITAL | Sun Oct 03 1993 01:17 | 9 |
| Well, I hope someone is writing a rebuttal to the article in a recent DN&R
(September 27, 1993) regarding the MTI StingRay II vs. our StorageWorks HSJ40.
We just presented the StorageWorks technology to our corporate account and now
this article comes out. It really puts the HSJ40 in a poor light and appears
to once again be based on mistruths. Even I wouldn't buy an HSJ after reading
the article...
Jim
|