[EMAIL PROTECTED] (Craddock, Chris) writes:
GOOGLE is certainly a loosely coupled architecture, but as you of all people would know, there are significant differences between that and a parallel sysplex. The main feature they (and Amazon as well btw) focus on is the full burdened price of their computational units including power, cooling, footprint etc. and that makes economic sense for them given the nature of their business application.
so the issue is effectively how fast fault isolation/recovery/tolerant technology becomes commodized. this is somewhat the scenario that happened with RAID ... when they first appeared, they were frequently depreciated compared to "mainframe" DASD ... but since then, they've effectively turned into the standard. for a little drift, i've repeated several times before what I did for i/o supervisor for the dasd engineering and product test labs (bldg. 14 & bldg 15) http://www.garlic.com/~lynn/subtopic.html#disk they had "testcells" ... basically hardware under development ... the term testcells somewhat come from the security provisions ... the test hardware were in individual heavy steel mesh "cages" (testing cells) ... inside a secured machine room. they had tried doing testing in an operating system environment ... but at the time, MVS had a MTBF of 15 mins operating with a single testcell. i undertook to rewrite the i/o supervisor so that it would never fail ... even when operating half-dozen to a dozen testcells concurrently .... allowing the processor complex then to also be used for some number of other tasks concurrently. bldg 14/15 tended to get early engineering models of processors ... also as part of disk testing. however, in the "stand-alone" mode of operation ... the processors were dedicated to scheduled i/o testing (which tended to be less than one percent cpu utilization). with the bullet proof i/o supervisor ... the idle cpu could be put to other tasks. at one point, bldg. 15 got the first engineering 3033 (outside of POK) dedicated for disk i/o testing. however, once we had testing going on in an operating system environment, we could take advantage of essentially, an otherwise idle processor. one of the applications that we moved onto the machine was the air bearing modeling that was going on as part of the development of the 3380 floating heads. SJR had a 370/195 that was being operated as an internal service ... and the air bearing modeling might get an hour or so a couple times a month. however, with essentially an idle 3033 sitting across the street ... we could drastically improve that (the 370/195 was peak rated around 10mips ... but most codes ran in the 5mip range ... and the 3033 was in the 4.5mip range ... but essentially unlimited amounts of 3033 time was still better than a couple hrs of 370/195 time a couple times a month). -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
