From: kjb@calmasd.prime.com (Ken Brucker)
Newsgroups: comp.os.vms,comp.sys.dec
Subject: Re: New VAXes/VAXstations: can these be realized?
Date: 12 Aug 92 17:27:37 GMT
Organization: Computervision - A Division of Prime Computer

In article <1992Aug11.212818.19498@thijssen.nl>, lamhof@thijssen.nl (Lambert Hofstra) writes:

> What would make it impossible for DEC to make a multi(VAX)processor
> VAXstation in the same box as a 4000 model 60 or 90, for instance a four
> 32VUPprocessor VAXstation 4000 model 94? (imagine 120VUP on the desktop
> :)  VMS can't be the problem: it supports SMP since V5.0.

Technologically speaking, there's nothing keeping DEC from developing a
multiprocessor VAXstation based on the 32 VUP chipset.

> I guess the new Alpha technology would be less attractive to the
> customers if they can buy such machines. They would have to migrate for
> Alpha, but could get the same performance with VAX. This mgration will
> be a (big ?) problem anyhow, since it takes DEC quite some time to
> convert all layered products to Alpha, which brings me to my second
> question:

Ah, but 4 32VUP processors does not equal one 120 VUP box.  The only time you
are ever going to take full advantage of having more than a single processor is
if there are multiple processes (or threads) in the compute queue ready for a
processor.  Given one, single threaded, application on a 4 processor 32VUP/each
VAX and on a 1 processor 120VUP VAX, you're going to see the job complete much
faster on the single processor system (ignoring I/O contraints etc.)

The development costs of such a system are probably prohibitive as well based
on the returns.  I've got no idea how much it would cost to come out with a
multi-processor VAXstation using the new chipsets, but I doubt that the net
return would make it worthwhile since Alpha seems to be coming soon.  You may
actually be surprised with how quickly the layered products become available. 
Right now they are focused mostly on the development end so that the third
party can get in on the act.  I just saw an ad yesterday from TGV stating that
they've successfully ported Multinet to Alpha and could put all the lines of
code that needed to be changed on a single page.  That's quite a statement and
DEC should be proud that it's been able to produce an entirely new architecture
that allows such an easy code migration!

> What would be the biggest problem if DEC would build a VMS machine with
> one (or at least one) VAX processor and one (or more ) Alpha processor?
> I guess only one of the architectures would run VMS, and the other would
> be able to run images that are build for that processor, much like
> images that require a vector coprocessor.

There'd need to be some changes in VMS to support this.  I'm sure it would be
possible to run the Alpha in a similar mode to the vector coprocessor but is it
really worth it?  Alpha boxes are available to software developer houses and
DEC has quite a few products ready to go already.  They've got lots more work
to do still, but I strongly suspect they've targeted the applications with the
largest install base for the first wave of conversion to Alpha.

> This must be a big help for everyone that wants to use the fast Alpha,
> but can not yet make the switch, because some of the layered products
> aren't converted to Alpha. DEC would not have to delay Alpha systems
> any further because of lack of software for the machines, because
> customers would be able to run all their current software, and move
> their layered products to Alpha TURBO mode over a longer period of time,
> step by step. (kind of hardware compatibility mode, like on a 11/780 in
> the old days: what would have become of the VAX, if DEC had waited until
> all software was ported from PDP11 to native VAX code :-)

Something else of interest here...it is going to be possible to cluster an
Alpha system with the current VAX hardware.  So, why bother with all the
trouble of making VMS support both chip sets in one box when you can just use
the Alpha node for running Alpha available software, and fall back to your VAX
boxes for those products that haven't been converted yet.

As far as DEC delaying things for lack of software, there's a phased release
planned that will get Alpha into customers hands while additional applications
are still being migrated.  They aren't waiting until they have their entire
product set available on Alpha.

One thing about this new hardware ... since it is a RISC architecture, the
images are going to be larger.  At the last Anahiem DECUS I asked about the
sizes of the images and how much disk space it would now take to install VMS.
While they didn't know exactly how much additional space it was going to take,
the panel pretty much agreed that an increase of 25% to 30% could be possible.
Good thing we've got larger and larger capacity disks coming out!

Ken
-- 
-------------------------------------------------------------------------------
**  Ken Brucker -- VMS/Ultrix Systems Programmer/Mangler -- Computer Vision
 **  kjb@calmasd.Prime.COM  
  **  Practice Random Kindness and Senseless Acts of Beauty
Newsgroups: comp.os.vms