Conference 7.286::digital

    No MTBF STATS...but Let's connect on Friday before another weekend
    blows us by.
    
    You might want to give Tom Walker a call for info on MTBF data. Tom
    is part of the competitive watch team covering workstations. You can
    reach Tom by calling 407-6602100.
    
    Russ the ISSMister

RE: .0

I use an automated system which gives me turn-around within 24 hours:
all you need is the part #.  I last used this system about 3 months
ago, so it should still work.

Fill out the form below, and mail it to either MTBF @OGO or CSSE::MTBF.
You will get an answer via the e-mail address you specify.

-- Ken Moreau


		MTBF/MTTR Request Form
		----------------------

Fill in the information below, and send this memo to either MTBF @OGO or
CSSE::MTBF.  The information, along with the required disclaimer, will
be sent to you at the ALL-IN-1 address or VMS address you specify below.

************************************************************************
*** IMPORTANT - AN AUTOMATED SYSTEM WILL PROCESS AND REPLY TO YOUR   ***
***     REQUEST.  PLEASE DO NOT DEVIATE FROM THIS FORMAT.            ***
************************************************************************

If you have any questons, please write or call the ADEG Program Engineering
Group at GSGPROGENG @MKO, or DTN 264-4727.

YOUR NAME:

YOUR ALL-IN-1 ADDRESS:
		(Example: JOHN JONES @OGO)
or
YOUR VMS ADDRESS:
		(Example: CSSE::JONES)

YOUR COST CENTER:

YOUR BADGE NUMBER:

CUSTOMER NAME:

CUSTOMER LOCATION:

BUSINESS REASON FOR RELEASING THIS INFORMATION:


Using one line per part number, list the part numbers for which you need
reliability (MTBF/MTTR) data below between the words "BEGIN" and "END".  Please
use the 2-5-2 part number format (00-TK50-AA) or you WILL NOT receive the
information that you requested.

DO NOT REMOVE THE WORDS "BEGIN" AND "END".

BEGIN


END

Ken,

Good idea but the automated system died on Oct 31 due to lack of funding. BTW,
the data had become pretty stale over the last year or so. Here's what the 
header looked like during its last month. Trust me, it's gone.


    #14         26-OCT-1995 06:33:42.42                                     MTBF
From:   CSSE::MTBF "26-Oct-1995 0830 -0400"
To:     TURCOTTE,DECIDE::MOFFITT
CC:     MTBF
Subj:   COMPLETED_MTBF_REQUEST

*******************************************************************************

      NOTICE:  This system will END-OF-SERVICE as of OCTOBER 31, 1995.


*******************************************************************************


I made a couple of suggestions to Tony off line.

enjoy,
tim m.

    I recently went through a similar exercise and for very much the same
    reasons. 
    	Firstly I found that entries in the relevant notes conferences
    helped. Secondly I was told that if I was to release these figures to a
    customer the source should be the product manager.
    
    	Hope this helps,
    
    	Tom Kempster

    
    Hi,
    
    Dan Riccio, wrksys::riccio was the Mechanical Engineer for the
    AlphaStation 200 and 250, he could tell you the MTBF, as I remember
    they were quite high.
    
    /art

I recently had the same problem and was told the owner of MTBF info process for
the SBU is:-

Rick Howe @MRO (RELYON::HOWE)

If you mail him the part nos, he should be able to help.

Dave.

    Ignoring the politics:
    
    if you have access to TIMA/STARS (I don't), you can often find MTBF
    figures of some sort in the Product Service Plan for the widget you're
    interested in.
    
    regards
    john

  Even very high MTBF numbers are not meaningless.

  It is true for mere humans like you and I, who buy and use our
  disks one or two at a time, that an MTBF of 100K hours (11.4 years)
  isn't meaningfully different than an MTBF of 800K hours (91.3 years).
  After all, the disk will be obsolete in one or two years and truly
  ridiculous in five or ten years.

  But for people who assemble huge storage arrays of hundreds or
  thousands of disks, the law of large numbers starts to come into
  play. If these disks really have a uniform failure rate throughout
  their lives, then with a hundred disks, that 100K drive array starts
  to fail every 1000 hours (42 days). And a thousand-disk array, the
  failure occurs every 4.2 days. They'd better be using RAID! But
  RAID requires more disks, and that means more failures! Yipes!

  If, on the other hand, they buy that disk that runs 800K hours on
  average, then the hundred disk array runs an average of 8000 hours
  (333 days) between failures and even the thousand-disk array runs
  800 hours (33.3 days). RAID would still be nice-to-have, but or-
  dinary backup-to-tape might still be a sufficiently practical
  strategy.

                                   Atlant

    
    Yes,
    
    Yes, yes, yes you are right.
    But when a customer wants to know what level of availability he can
    guarantee to his users you will need AVANTO to give him the right answer. 
    With normal common sense and a pocket calculator you will not be able 
    to satisfy such complex problems as you describe them. And it is not
    true that 10 disks will give 800k devided by ten is 80k MTBF. That is
    only true if all disks are used by the same database and application and
    are not redundant and and and.
    We have utilised AVANTO many many times in situations where we had to
    answer questions from customers like "what do I have to do in order 
    to have no more then 16 hours of downtime average per year?"
    Would you recommend RAID or volume shadowing and/or clustering?
    We have even designed systems that will never be down, even in case of
    disaster. We have done this for customers with 8 node clusters and 150
    Gbyte of disk. 
    So once again, contact Dave Varner and Ron Rocheleau and don't start
    a debate here about the real value of MTBF and MTTR. As far as I'm
    cencerned only a few of us are qualified and the best one is Ron. 
    Use AVANTO with the customer and see for yourself what a great 
    thing we have. We have done it many times and customers are paying us
    big bundles of money to get the real Availability answers.
    
    Regards,
    
    
    Aad Kooijman.
    Business manager High Availability Services in Holland.
    So I'm not very very technical
                                  

Aad:

  You're "preaching to the choir". I wasn't arguing about the use-
  fulness of a complete model. I worked for both Field Service and
  CSSE, and models were our life! We knew how to get whatever
  answer we wanted from our models. :-)

  What I was debating was the statement that such large MTBFs are
  meaningless. They're definitely not, at least not if you have
  enough disks (for example) that the law of large numbers starts
  to apply. Ten disks? You're right -- the calculation isn't
  simply MTBF/10. But a hundred disks? Maybe. And a thousand
  disks? Probably.

  And yes, disks have wear-out mechanisms as well as other sources
  of failures. But I was trying to draw a simple illustration and
  not clutter it up too much with details. And the original note
  that talked about meaningless MTBFs had used disks as an example,
  so I followed suit.
                                   Atlant

    Re: MTBF vs. reliability/availability/maintainability - there are some
    really good replys in this notes stream, and some very valid positions.
    Unfortunately, our customers (who emerge from the great unwashed,
    uneducated masses) still ask for, and in some cases demand, equipment 
    MTBF as part of Digital's response to RFQs.  Try as one may, they can
    not be educated or coerced away from this position - in fact, they
    sometimes take on the "if you won't tell me, what are you hiding"
    attitude about the subject.
    
    Interestingly enough, most don't specify or care about the method used 
    to generate the number (DoD and other U.S. agencies being the 
    exception - MIL 217 only please), they just want the number and by not 
    providing it Digital risks being declared non-compliant in their proposal.  
    
    Also, I have never known a customer to come back with MTBF data and 
    say, " Oh, by the way, the equipment you sold me didn't meet the MTBF 
    you specified.  I think you should compensate me."  I have had them 
    cite me chapter and verse from the IBM/HP/Sun book as to why "my" 
    equipment was substsantially inferior to the competing product in 
    terms of "calculated" MTBF.  Then the discussions get really mundane.
    
    My .02 worth 
    
    	Bill
    
         
    
    

    Bill gets my vote. No numbers, no sale, in much of the OEM market I
    support. It doesn't matter if the numbers are meaningless, it doesn't
    matter than some of the OEM customers and/or their end users can't tell
    the difference between availability and reliability, it just matters
    whether they can drive their (?ISO9000?) quality process which says
    they have to crank the MTBF handle on a spreadsheet and come up with
    The Answer.
    
    regards
    john

    
    
    Hi guys,
    
    If your customer wants/needs MTTR and MTBF, give it to them. I do not argue
    with that. Just make sure you get a non-disclosure.
    I only want to point out that:
                       
    1. These figures do not tell the whole availability story.
    2. Digital has great services and applications to help our customers
       determine the 'real' availability. 
    3. We have been very succesful selling these services in Holland.
    4. We can, by using these services make IBM and HP look stupid.
    5. By positioning our High Availability services we have a unique
       selling point.
    6. We generated a million worth of NOR with these services within a
       year. Especially in the OEM market and with partners. We can help
       partners to design systems that will meet their Availability specs.
       The account managers love it because we see a lot of product sales
       as a result of these services.
    7. Digital has expertise that is second to none that you might want to use.
    8. The Availability Analysis Tool (AVANTO) is just great and we have
       used it hundreds of times. One of our ABU accounts bought k$ 600 worth
       of hardware and software as a result of an AVANTO exersise. Just to
       improve the availability of one of his VAX clusters.
    
    
    Best regards,
    
    
    Aad Kooijman.
    
	

    And just remember that MTBF is "mean time between failures", this
    statistical number is just that - the time between successive failures
    of the same piece of equipment. Hopefuly with our latest technology you
    or your customer or the equipment will not be around to argue whether 
    the second failure exceeded the MTBF.
    
    Just replaced an RZ23 in my vaxstation after the first failure - I've
    had this faithful beasty for about 7 years, the MTBF timer started at
    13:00 today....
    
    Steve.