3 ms·
I don't really understand their methodology for computing failure rate. The page says they calculate the rate on a per annum basis as: ([#drives][# failures])
by gradstudent 11y ago
I don't really understand their methodology for computing failure rate. The page says they calculate the rate on a per annum basis as:
([#drives][# failures]) / [operating time across all drives]
Wat? The numerator and denominator seem unrelated. What is being measured here?
To me, it would make more sense to look at time to failure. Together with data on the age of the drive and the proportion of failures each year one could create an empirical distribution to characterise the likelihood of failure in each year of service. That would give a concrete basis from which to compare failure rates across different models.
- deleted 11y ago[deleted]
- eterm 11y agoSurvival data is tricky to model. They have just done an overall average number of failures per running hour. There do seem to be a lot of factors not taken into account here such as drive ages, (in both running time and elapsed), etc. With right censored data (as this is), if you measure age at death but then you're only modelling already failed drives, so you'll under represent good drives. It would be good to see some statistics done so we can see confidence intervals around a hazard rate at different ages.
- deleted 11y ago[deleted]
- gcb0 11y agoyep. it is not science. they don't have... they don't even consider a null hypothesis. It is raw data that they provide in an excellent fashion. You can consume it raw and trust their high driver numbers to drive p high enough for you, or you can use their data for real science. either way, it is a great deal that they take the time to share it.
- snaily 11y agoAre you referring to the "(100*drive-failures)/(drive-hours/24/365)"? There's no multiplication of total # of drives and # of failures in there. It's all just a scaling: you have a number of broken drives in a corner of the datacenter in the wire bucket that says "broke during 2015", you count them, divide by total hours of that type of disk running (since they may have been brought in commission at different points), and then scale it so you get it in percent-per-year, not likelihood-per-hour. It smells of someone explaining code, rather than illustrating an important engineering formula, but there's nothing wrong with the rescaling calculation per se.
- gradstudent 11y ago> Are you referring to the "(100drive-failures)/(drive-hours/24/365)"? There's no multiplication of total # of drives and # of failures in there. Perhaps the problem is the specific example given. 100 is the size of the drive fleet and also the multiplier required to convert to percentages. Let's assume you are right and the 100 in the equation is not #drives. Even so, I find the approach questionable. If the point is calculate the proportion of failures then that (overly simplistic) calculation is: [#failures] / [ #drives] = 5 / 100 = 5% failure rate. But this isn't what's calculated. Instead the author calculates the proportion of drive-years per annum affected by failure. For the 100 drives in the example the cumulative number of operational hours given in 2015 is 750K hours (out of a possible 876K hours, had the drives been operating 100% of the time). That's a problem because 750 / 876 = 85.6% of total time. 5 / 85.6 = 5.84% "failure rate" which seems to me an overstatement. The problem gets worse as the number of operational hours decrease. Imagine for a moment the 100 drives only operated 50% of the time in 2015. We have: 100 (5 / ((875K*0.5) / 875K)) = 10% "failure rate". This despite only 5% of the drives having failed. Wat?