The other day we discussed the “fail fast” principle in statistical modeling and computing.
According to wikipedia, the term “fail fast” dates from an article by Jim Gray, “Why Do Computers Stop and What Can Be Done About It?,” published in June 1985 as Tandem Technical report 85.7. Tandem was a company that made fault-tolerant computers—I think the name “tandem” referred to the idea of having two available processors, so that if one broke, the other was available.
In the words of Gray:
The process approach to fault isolation advocates that the process software module be fail-fast, it should either function correctly or it should detect the fault, signal failure and stop operating.
He elaborates:
Reliability and availability are different: Availability is doing the right thing within the specified response time. Reliability is not doing the wrong thing.
Expected reliability is proportional to the Mean Time Between Failures (MBF). A failure has some Mean Time To Repair (MTTR). . . . modularity and redundancy allows one module of the system to fail without affecting the availability of the system as a whole because redundancy leads to small MTTR. This combination of modularity and redundancy is the key to providing continuous service even if some components fail.
And some amusing history:
Von Neumann was the first to analytically study the use of redundancy to construct available (highly reliable) systems from unreliable components. In his model, a redundancy 20,000 was needed to get a system MTBF of 100 years. Certainly, his components were less reliable than transistors, he was thinking of human neurons or vacuum tubes. Still, it is not obvious why von Neumann’s machines
required a redundancy factor of 20,000 while current electronic systems use a factor of 2 to achieve very high availability. The key difference is that von Neumann’s model lacked modularity, a failure in any bundle of wires anywhere, implied a total system failure.Von Neumann’s model had redundancy without modularity. In contrast, modern computer systems are constructed in a modular fashion—a failure within a module only affects that module. In addition each module is constructed to be fail-fast—the module either functions properly or stops. Combining redundancy with modularity allows one to use a redundancy of two rather than 20,000. Quite an economy!
The whole article is worth reading. It fills me with nostalgia: the typewriter font, the careful writing, the order-of-magnitude reasoning, the openness about uncertainty, the comfort with physics, the whole non-B.S. quantitativeness of it all, the guys-in-short-sleeved-shirts-with-pocket-protectors vibe . . . Here’s an example:
Here’s another snippet:
The assertion that most production software bugs are soft—Heisenbugs that go away when you look at them—is well known to systems programmers. Bohrbugs, like the Bohr atom, are solid, easily detected by standard techniques, and hence boring. But Heisenbugs may elude a bugcatcher for years of execution. Indeed, the bugcatcher may perturb the situation just enough to make the Heisenbug disappear.
This is analogous to the Heisenberg Uncertainty Principle in Physics. I have tried to quantify the chances of tolerating a Heisenbug by reexecution. This is difficult. A poll yields nothing quantitative. The one experiment I did went as follows: The spooler error log of several dozen systems was examined. The spooler is constructed as a collection of fail-fast processes. When one of the processes detects a fault, it stops and lets its brother continue the operation. The brother does a software retry. If the brother also fails, then the bug is a Bohrbug rather than a Heisenbug. In the measured period, one out 132 software faults was a Bohrbug, the remainder were Heisenbugs.
And here’s a link to the cited article by Neumann, “Probabilistic logics and the synthesis of reliable organisms,” originally from 1952. Good stuff.
I really enjoy the “Heisenbug” and “Bohrbug” terminology! And somewhat adjacent to your own nostalgia, I find myself wistfully remembering the internet of my university days (c. 2000) when we still had Usenet and the “blogosphere” was starting to be a thing.
Agreed. The distinction is useful. It also explains why I often execute failed codes repeatedly without changing anything before attempting serious debugging.
I started coding with PL/I on IBM 360 in the early 1990s and this post made me misty-eyed…
I saw von Neumann mentions a “fiduciary level”:
Was he a hardcore Fisherian?
Anon:
Back in that era, mathematicians had some weird understandings of statistics. See for example the discussion here about Feller’s attitudes.
How is the “mathematicians had some weird understandings of statistics” remark related to von Neumann giving the name “fiduciary level” to a threshold used to reliably identify signals in redundant networks?
The Feller quote:
I’ve come to think of mathematicians as extremely rigorous about deductions relative to choice of premises. In this case though I don’t follow the argument. It is something like “if a method can be used to return wrong answers then it is wrong”. Essentially that a good method should render GIGO impossible. Fine, but obviously doesn’t apply to “frequentist” stats either.
So, as written in your paper, I don’t think much thought was put into this paragraph. Maybe it was added after the book was written, followed by some sort of review process. At that point you’d look for any excuse not to rewrite it based on an entirely new premise.
But did von Neumann just happen upon the term “fiduciary”? I wonder if it was more popular in some 1950s communities than usually portrayed.
For anyone unfamiliar with the history: https://en.wikipedia.org/wiki/Fiducial_inference
It also seems to touch on why independent replication is so important in the context of imperfect observations/calculations:
So stringing together a bunch of “p < 0.05 facts” (essentially, NHST) “asymptotically degenerates to total irrelevance”. However, independent replication fixes this. Then I guess that Gray 1985 paper discusses how modularity affects the required number of replications. Or is that straying too far from von Neumann’s original purpose (discussing neural networks)?
So linguistically, this usage of the term fast seems to be equivalent to “safe” and maybe come from nautical usage.
If I bring my boat into a slip, I “make it fast” by tying an appropriate knot in the mooring lines.
https://www.merriam-webster.com/dictionary/fast
But that wasn’t the usage you were using in the previous post was it? The idea wasn’t to have a Fail-Safe redundant system, the idea was to quickly detect failure so as to move on during debugging of models. In that sense fast was used like a race car, take only a little time or go at high velocity.
On page 4, the Gray paper cites Schlichting and Schneider [1983] as the source of “fail fast”, which is only a couple years earlier:
This must have been a well known principle earlier in software engineering well before that, even if it didn’t have a name.