Counting how little it stops and how fast it is

Machines break eventually. So you keep an average of how long it lasts and how long it takes to come back once broken.

• MTBF (mean time between failures) … the average time spent running from one failure to the next
• MTTR (mean time to repair) … the average time spent stopped, from the failure until the repair is finished

The names are long and easy to confuse, so remember them by the middle letter. B is between, the running side. R is repair, the stopped side.

Adding the two gives the whole time of one cycle. Time running plus time stopped is simply the time that has passed.

Availability is the fraction of the total time that was spent running.

The numerator is the time running, that is MTBF. The denominator is the total time, that is MTBF + MTTR. That is all.

One example. For a device with an MTBF of 80 hours and an MTTR of 20 hours, one cycle is 100 hours and it ran for 80 of them. So the availability is 80 / 100 = 0.8.

The answer is a number between 0 and 1. 0.8 means "running eight tenths of the time", and asked as a percentage it is 80 per cent.

Look at the formula and there are only two ways to raise it: lengthen the MTBF in the numerator, or shorten the MTTR that weighs on the denominator.

• Lengthen the MTBF … replace or inspect parts before they break. That is preventive maintenance
• Shorten the MTTR … connect from afar so you can investigate at once. That is remote maintenance

Watch out for one thing: lengthening the MTTR lowers availability. A sentence saying "remote maintenance lengthens the MTTR and raises availability" has both directions backwards and is wrong.

One more. The more kinds of device there are, the shorter the MTBF gets. With more places able to break, the time to the next failure shrinks. Choices reversing this come up too.

When two devices are combined so that both have to be running for it to be usable, that is called in series. A server and a network device, where losing either makes the work impossible, are like this.

Availability here is a multiplication. The reason is plain: you want the probability that "A is running" and "B is running" happen together, and multiplying the two fractions gives the fraction where both are up.

Put a device of availability 0.8 in series with one of 0.9 and you get 0.8 x 0.9 = 0.72. The characteristic of series is that it comes out lower than either of the originals. You are multiplying by a number smaller than 1, so it must fall.

In other words series gets weaker the more parts you add. That is the biggest difference from parallel, next.

A connection where the work carries on as long as any one of them is running is in parallel. Keeping two devices with the same role, the duplication you have seen, is this.

The formula looks a little complicated, but it becomes clear if you come at it from the probability of stopping, because a parallel arrangement only stops when all of them stop at once.

The fraction of the time A is stopped is 1 - A and for B it is 1 - B. The fraction where both are stopped together is their product, (1-A) x (1-B). What you want is the other side of that, so subtract it from 1.

Try devices of 0.9 and 0.8 in parallel. The probability of stopping is 0.1 x 0.2 = 0.02, so the availability is 1 - 0.02 = 0.98. Parallel comes out higher than either of the originals.

The shapes set in the exam mix series and parallel. The method is always the same: collapse the inner group into a single device, then work out the outside.

Here is an example. Tokyo and Osaka are connected directly by a line of availability 0.9. Add a detour via Nagoya, with Tokyo to Nagoya and Nagoya to Osaka both 0.9.

First the detour: nothing gets through unless both hops do, so it is series. Treat it as one line of 0.9 x 0.9 = 0.81.

Next, the direct line at 0.9 and this 0.81 are in parallel, since either route getting through is enough. The probability of stopping is 0.1 x 0.19 = 0.019, so the availability is 1 - 0.019 = 0.981.

The knack is working out whether the inner part is series or parallel first. Collapse them in the wrong order and the answer will not come out.

MTBF has a property that runs against intuition: line up many of the same device and the MTBF of the whole system gets shorter.

Think about it and it is obvious. If one machine breaks once every 100 hours, with 100 machines something breaks 100 times as often. So the MTBF of the whole is one machine MTBF divided by the number of machines.

One example. Line up 100 devices with an MTBF of 210,000 hours and the MTBF of the whole is 210000 / 100 = 2100 hours. That is, something breaks every 2,100 hours on average.

If it runs 140 hours a week, 2100 / 140 = 15, so a failure once every 15 weeks on average. It is a two-stage calculation: get the answer in hours, then convert to weeks.

How readily things fail is not the same throughout their life. Plot the failure rate against time and you get a shape high at both ends and low in the middle, like a bathtub. That is the bathtub curve.

• Early failure period … just after it starts running. Build defects and missed settings turn up one after another and the failure rate is high
• Random failure period … after it settles. Failures are rare and the failure rate is roughly constant
• Wear-out failure period … after long use. Parts degrade and the failure rate climbs again

One important thing follows. If you are measuring availability to compare products, you should measure in the middle, in the random failure period. Just after the start it comes out badly by the amount of the remaining defects, and at the end by the amount of the degradation. Neither is the real ability of the system.

From here the subject moves from not stopping to being fast. Even within speed there are three measures with different things being measured, so keep them apart.

• Throughput … how many were handled per unit of time. It measures the amount of work
• Response time … the time from asking until the answer starts coming back
• Turnaround time … the time from asking until the whole answer has come back

The only difference between response time and turnaround time is where you stop the clock. Ask for something to be printed and the time until the printer starts moving is the response time, while the time until all the paper is out is the turnaround time.

Response time can be broken into a sum: the processing at the terminal, the time on the line and the processing at the server. So if you want the server processing time, subtract the other two from the response time.

The basis of raising throughput is not letting the machine idle. Operator actions between jobs leave it with nothing to do and it drops accordingly, while devices such as spooling (writing the print data to disk first so you can move on to the next job without waiting for a slow printer) help.

But pack it too tightly and another problem appears. Just as with queueing at a counter, the busier it gets, the faster the waiting time grows. The idea that handles this is queueing.

Taking the wait at 50 per cent utilisation as 1, it is 4 times at 80 per cent, 9 times at 90 per cent and 19 times at 95 per cent. As utilisation approaches 1, the waiting time leaps up.

So the graph of CPU utilisation against average response time is not a straight line but a shape that rears up at the right-hand end. "It is only 90 per cent, so we are fine" does not hold here.

Finally, the way to measure performance and the steps for preparing.

Measuring is the benchmark test: actually running a standard program chosen to suit your purpose, turning the processing performance into a number and comparing products. Actually running it is the crux — neither estimating on paper from instruction counts nor building a model and simulating is a benchmark.

Preparing is capacity planning: planning how much resource to hold so you can bear the future volume. The order is always the same: measure where you are now, estimate the future volume, work out when the limit arrives, decide what to add.

Do not start from the far end. Decide on an expansion before measuring where you are and you have no grounds for what to add or how much.