alan@globalcenter.NET (Alan Hannan) writes:

...

For total system uptime 90.0% (one nine or less) Desktop systems. 99.0% (two nines) Intermediate business systems 99.9% (three nines) Most business data systems and workgroup servers 99.99% (four nines) High-end business systems and your friendly neighborhood telco 99.999% (five nines) Bank Data Centers and Telco Data Centers, some ISPs 99.9999% (six nines) Only God and Norad live here. 99.99999% (seven nines) Even God doesn't have pockets this deep.

What's your source for this data?

Here are some availability parameters I understand are used for US Government Communication Service acquisitions by the FAA and DOD. I don't know what, if any, study or research went into these definitions. There seems to be a lot of exageration in both the stated requirement and deliverability of many availability numbers. However, the table below are some of the sanest ones I've seen. The most extreme availibility number I give even the slightest credence was for the AT&T Master Clock in Hillsboro, Missouri at 9 nines. I've never confirmed it with AT&T though, and wouldn't be surprised if it was less. Service Service Expected Expected Type Scope Availability Restoration Time Critical Functions or Services 0.9999987 <6 seconds which, if lost, would prevent the network/ system from exercising safe operation and control for the end users Essential Functions or services 0.999 approximately which, if lost, would 10 minutes reduce the capability of the network/system to exercise safe operation and control for the end users Routine Functions or services 0.99 approximately which, if lost, would 2 hours not significantly degrade the capability of the network/system to exercise safe operation and control for the end users I took this table from another publication, which gave the reference as U.S. Federal Standard 1037B, Telecommunications Glossary. A note was included "The expected availability values require information as to the population and interval over which they have been calculated." -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation