home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / mswindo / programm / win32 / 304 < prev    next >
Encoding:
Text File  |  1992-07-28  |  5.0 KB  |  115 lines
  1. Newsgroups: comp.os.ms-windows.programmer.win32
  2. Path: sparky!uunet!microsoft!hexnut!leefi
  3. From: leefi@microsoft.com (lee fisher)
  4. Subject: re: Does NT's SMP handel processor failure?
  5. Message-ID: <1992Jul27.041246.7129@microsoft.com>
  6. Date: 27 Jul 92 04:12:46 GMT
  7. Organization: microsoft corp., redmond, wa
  8. Lines: 105
  9.  
  10. hmm, i can't find the original article... anyway, here's a response from
  11. a co-worker (posted with his permission) regarding this NT SMP discussion.
  12. hope this clarifies things...
  13.  
  14. the question:
  15.  
  16. > The question is: On an N processor CPU, if one of the processor fails,
  17. > does NT "catch" the failure, and eliminate that CPU from eligibility
  18. > to run any other threads?
  19. > 
  20. > The reason this is important is that if the answer is yes, then
  21. > an N processor CPU should be N times as reliable as a 1 processor
  22. > CPU( Since they would all have to fail before you completely lost
  23. > function.) If the answer is no, then it would be 1/N'th as reliable,
  24. > since any one processor failing would garbage all threads scheduled
  25. > to the failing processor.
  26. > 
  27. > On Compuserve, someone said they had been trying and failing to
  28. > get a definitive answer on this question. Does anyone know for
  29. > sure?
  30.  
  31. the response:
  32.  
  33. > People have been kind enough to foreword me your posting on either
  34. > Compuserve or Usenet. I would like to take a moment to add some
  35. > comments/points of my own to your debate. I apologize for the length of my
  36. > message, I did try to keep it reasonably succinct.
  37. > 
  38. > --- Fault tolerance of SMP machines ---
  39. > 
  40. > First of all, if a processor fails during runtime Windows/NT will crash.
  41. > 
  42. > Next, I want to point out that you need *special* hardware to be able to
  43. > continue running when a processor crashes. No x86 based SMP machine
  44. > currently has the required hardware to make this support even possible.
  45. > So, yes, I will take the bet that stated the MP OS/2, assuming it appears,
  46. > will actually continue upon processor failure because it can't be done on
  47. > the current hardware. (now if IBM provides it via a special FT enabled
  48. > computer, that's a different story).
  49. > 
  50. > --- Reliability of SMP machines ---
  51. > 
  52. > Yes an N processor machine is more apt to crash then a 1 processor
  53. > machine.  Let's say out of every M crashes in a year due to faulty
  54. > hardware, 1 is due to a broken processor. Then an N processor machine
  55. > would crash M+N-1 times for the same period of time (all other things
  56. > being equal). Now I don't think every hardware crash has been caused from
  57. > a failing processor, so I don't think the odds of crash just increased a
  58. > factor N-1 times for the given period. Ie:
  59. > 
  60. >   These numbers are just examples - I don't know the true statistics - if
  61. >   you have them, please provide the reference for them. They would be
  62. >   valuable in attempting to make accurate determination of this problem.
  63. > 
  64. >   Let's assume:
  65. >     100 hardware crashes a year, 1 due to a CPU failure
  66. > 
  67. >   If we used 4 times the number of CPUs and left everything else the same.
  68. >   We would have:
  69. >     103 hardware crashes a year, 4 due to CPU failures
  70. > 
  71. >     or...
  72. > 
  73. >     400% the number of CPU failures, but only around 3% more total crashes 
  74. >     (due to hardware). (From machines which ideally provide close to 4 times 
  75. >     the processing power)
  76. > 
  77. > However, it also a fact that moving from a UP platform to an MP platform
  78. > does not leave the rest of the hardware 'equal', so there are other
  79. > factors yet to be calculated in. (On the 'down side' there is extra
  80. > hardware in an MP machine which could break. Plus there is typically more
  81. > stress provided to the other parts of the box. On the 'up side' many MP
  82. > machines are fault-tolerant to the more common problems so they are apt to
  83. > be more stable in these areas then most UP machines).
  84. > 
  85. > --- Other ---
  86. > 
  87. > Multi-processor support in Windows/NT is intended to give users more
  88. > processing power. Sure I would love to provide FT abilities at the same
  89. > time, but what the real intention of multiple processors in this 'context'
  90. > is to get more processing-power for the user - that's how the machines are
  91. > designed, and that's how Windows/NT utilizes them.
  92. > 
  93. > Other machines do things like use 2 processors tied together which run the
  94. > same bits of code and are expected to produce the same bits of output. If
  95. > they differ, or one simply ceases to function, then they are stopped and
  96. > the OS can sort out the problem without risk to the integrity of the rest
  97. > of the machine.  Obviously here is a different 'context' where a
  98. > multiprocessor machine is designed to be fault-tolerant, not to increase
  99. > performance. (and then, of course, you get into hybrid designs which want
  100. > to do both).
  101. > 
  102. > -------------
  103. > 
  104. > I tried not to color my opinions more then necessary :^). I believe the
  105. > SMP support in Windows/NT is a good and viable feature.
  106. > 
  107. >      Thanks for listening,
  108. > 
  109. >      Ken Reneris
  110. >      Microsoft Corp.
  111. >      kenr@microsoft.com
  112. __
  113. Lee Fisher, (not a spokesperson for) Microsoft Corp., Redmond, WA, USA
  114. leefi@microsoft.com, {uunet,uw-beaver,sun,sco,decvax}!microsoft!leefi
  115.