Everhart, Glenn
From:	Fred Kleinsorge [kleinsorge@star.enet.dec_nospam.com]
Sent:	Monday, August 31, 1998 12:18 PM
To:	Info-VAX@Mvb.Saic.Com
Subject:	Re: [Q] processors
Jerry Leichter wrote:
> 
>         Anyone happen to know how many processors OpenVMS can support in a
>         single computer? Is the number different for a VAX or an Alpha system?
>         Got any URLs or other references I could look at?
> 
> A limit of 16 processors is fairly well embedded in the VMS design by the use
> of bitmasks to represent various processor-specific things.  This was a
> deliberate design decision, as it made various things much faster on VAXes at
> little perceived cost, since at the time - and even today - hardware limita-
> tions made larger SMP configurations unlikely.
> 
> Some background:  CPU speeds have been increasing faster than memory speeds
> for years, a trend that shows no sign of changing.  The big cost component in
> high-end systems today - as it has been for many years - is memory that can
> keep the CPU fed.  Feeding *multiple* CPU's makes the problem all that much
> harder.  The "knee in the curve" beyond which adding extra CPU's gains you too
> little to be worth the cost for all but very specialized applications has
> remained at about 6 CPU's for years.  There *are* commercial machines out
> there now with (considerably) more CPU's, but they don't try to provide a
> completely symmetric environment.  OS support for them would be quite
> different, internally, than VMS's SMP support, so the 32-CPU limitation
> wouldn't be signficant - the code would have to reworked anyway.
> 

  The OpenVMS Alpha limit today is 32 processors, limited by the
  console datastructures.  Were a 17-32 processor system built, it
  would work... in theory.  When > 32 CPU systems are available,
  it is a bit of work to change things, but the effort has already
  been scoped out.

  However, how well a 17+ system would work might be debateable,
  and vary widely.  Researchers in the early 70s predicted that SMP
  performance on a typical workload would begin to flatten out
  at about 8 processors (Minsky et al)... and that has indeed
  proved to be fairly accurate +/- 2 processors.  The cost of
  synchronization to shared resources in a SMP system forces SMP
  designs down paths that would seem to inevitably lead to multiple
  schedulers and application domains.

  Unless you happen to have a highly parallel application, and
  something that can be highly tuned and configured -- general
  workloads would be far better along to use Galaxy, and create
  multiple domains in a VMS cluster environment.  Allowing data
  sharing via shared memory interconnects, direct storage connection,
  and the ability to balance CPU load by moving CPUs between domains.


 _Fred