home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / vms / 13579 < prev    next >
Encoding:
Internet Message Format  |  1992-08-12  |  3.2 KB
  1. Xref: sparky comp.os.vms:13579 comp.sys.dec:4491
  2. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!mips!sdd.hp.com!ux1.cso.uiuc.edu!mp.cs.niu.edu!fnnews!fndcd.fnal.gov!nagy
  3. From: nagy@nagy.fnal.gov (Frank J. Nagy:VAX Wizard&Loose Cannon)
  4. Newsgroups: comp.os.vms,comp.sys.dec
  5. Subject: Re: New VAXes/VAXstations: can these be realized?
  6. Message-ID: <1992Aug12.140056.1@nagy.fnal.gov>
  7. Date: 12 Aug 92 20:00:56 GMT
  8. References: <1992Aug11.212818.19498@thijssen.nl> <1992Aug12.092737.674@calmasd.prime.com>
  9. Sender: news@fnnews.fnal.gov
  10. Followup-To: comp.os.vms
  11. Organization: Fermilab Computing Division
  12. Lines: 49
  13. Nntp-Posting-Host: nagy.fnal.gov
  14.  
  15. >> What would make it impossible for DEC to make a multi(VAX)processor
  16. >> VAXstation in the same box as a 4000 model 60 or 90, for instance a four
  17. >> 32VUPprocessor VAXstation 4000 model 94? (imagine 120VUP on the desktop
  18. >> :)  VMS can't be the problem: it supports SMP since V5.0.
  19. > 
  20. > Technologically speaking, there's nothing keeping DEC from developing a
  21. > multiprocessor VAXstation based on the 32 VUP chipset.
  22. > 
  23.  
  24. Digital actually had a multiprocessor VAXstation.  Now what was that
  25. name... The VAXstation 3520 (2 CPUs) and 3540 (4 CPUs) as I remember.
  26. These were based on the same chip used in the 3100 on a board with
  27. two processors which fitted into an M-BUS backplane (which then had
  28. an adapter to a Qbus).
  29.  
  30. > Ah, but 4 32VUP processors does not equal one 120 VUP box.  The only time you
  31. > are ever going to take full advantage of having more than a single processor is
  32. > if there are multiple processes (or threads) in the compute queue ready for a
  33. > processor.  
  34.  
  35. Actually, a multiprocessor VAXstation makes even more sense today.
  36. It was noted that the VS 3520 ran pretty well - what happened was that
  37. the X server code ended up running on one CPU and the client application
  38. on the other.  Using X automatically guarantees that any display application
  39. is going to have >= 2 processes.  Also, the old VAX Workstation Software
  40. (VWS) is pretty much dead; this was a kernel-based graphics windowing system
  41. and was not useable on a multiprocessor.
  42.  
  43. > The development costs of such a system are probably prohibitive as well based
  44. > on the returns.  
  45.  
  46. I believe that the software costs to VMS should not be any more difficult
  47. than those needed for any new VAX since VMS supports SMP already.  The
  48. hardware might be just a tad more difficult (more board real estate for
  49. the second CPU, cache synchronization and the like) but its not clear it
  50. is worth it today when a 2x or 3x faster chip is just 4-6 months away
  51. anyway.
  52.  
  53. I do believe that 2nd or maybe 3rd generation of the Alpha machines will
  54. begin to see multiprocessor workstations reappear as a means of getting
  55. higher performance (remember that one of the means of getting the 1000x
  56. performance improvement in the Alpha lifetime is multiprocessing and this
  57. likely means across the entire line of Alpha systems).
  58.  
  59. = Dr. Frank J. Nagy   "VAX Guru & Wizard, Loose Cannon"  {{Group Leader!}}
  60. = Fermilab Computing Division/Distributed Computing Dept/Special Projects Grp
  61. = HEPnet/SPAN: FNDCD::NAGY (43123::NAGY) or FNAL::NAGY (43009::NAGY)
  62. = Internet: NAGY@FNAL.FNAL.GOV            = BitNet: NAGY@FNAL
  63. = USnail: Fermilab POB 500 MS/234 Batavia, IL 60510
  64.