Why so little parallelism?
|
From: lynn on 9 Nov 2006 19:13 Jan Vorbrüggen wrote: > Yes. Or the thing TMC built - what was it called, The Data Vault? old post by somebody from long ago and far away Newsgroups: comp.arch Subject: Re: *big iron* Date: 28 Sep 89 18:12:07 GMT Organization: Thinking Machines Corporation, Cambridge MA, USA Actually, the current DataVaults have 42 drives. Though the bus to the DV is 64 bits wide, it is broken down into a 32-bit data path inside the DV. There are 32 data drives, 7 ECC drives, and 3 hot spares, each of which can be switched into any of the other 39 channels. We also offer double-capacity DVs with 84 drives; no more bandwidth, just a 2nd tier of drives off of each channel. .... snip ... And the following for a lot more drift (although also mentioning datavault) .... note the Almaden reference can be found here: http://www.almaden.ibm.com/StorageSystems/Past_Projects/TSM.shtml which traces its history to *CMSBACK* which i had originally done more than ten years earlier: http://www.garlic.com/~lynn/2006t.html#20 Why these original FORTRAN quirks?; Now : Programming practices http://www.garlic.com/~lynn/2006t.html#24 CMSBACK we had funded part of the Unitree product work from our ha/cmp project (aka reference to rft/lcmp): http://www.garlic.com/~lynn/subtopic.html#hacmp From: lynn Date: Fri, 8 Mar 91 17:55:16 EST Subject: LANL Unitree meeting We just got back from a joint LANL/LLNL/Discos/IBM meeting at Los Alamos (we also had an earlier Unitree/IBM/ACSC meeting on Tuesday in LA). Partly purely as coincidence, on the flight down, I ran into xxxxxx with two of his people on their way to Tucson to discuss the Almaden workstation/pc backup/archive facility. It seems to be a coincidence since one of the things brought up at the LANL meeting was a vendor that has had a similar product (with a MVS backend) on the market. The ******* comment was that this vendor now has the product ported to an Unitree (server) backend. Functions appear to be identical, providing client registration with archive/backup policy requests that are then scheduled (potentially offshift on a regular basis) ... with the server "pulling" the files ... not the client pushing the files. We discussed the RFT/LCMP enhancements for concurrent Unitree operation on multiple server platforms (sharing same physical disk drives). Also repeated some of the discussion that we had a couple weeks ago with ******* research about some possible near-term technology enhancements. Also has some discussion about the ANT stuff that ****** did for Univ. of Mich. IFS system and the discussions that have occured regarding all of their stuff on Unitree/RFTLCMP platform. Including the advantages of having NFS, AFS3, AFS4 (and possibly other protocols) all pointing to the SAME IEEE MSS-2 bitmap files. This (along with automatic Unitree archiving facility) is also what many of the other major customers are asking for with respect to Andrew/OSF. We were able to come away pretty much addressing all of their requirements except for a near-term tape backup for their connection machine. The HIPPI D2 & tape-array products aren't yet on the market .... so they have an interim solution that would utilize four 3490s driven in parallel as a logical tape array. Because of the interim nature of the requirement, it didn't seem to be worthwhile to address it with software in the RS/6000 (either via a RS/6000 adapter card emulating 370 control unit or by one of the NSC A51x remote device adapters ... its been going on eight years since I've done much NSC A51x remote device programming). The connection machine is writing data to the data vault (a box with 32-drive disk data array, 7 ECC drives, and 3 spare drives that are electronically switchable into the configuration). The requirement is to periodically back data from the data vault (out over the HIPPI interface) to tape (files that are currently on the order of 10s of gigabytes, but growing eventually to potentially terabytes). The proposed solution is that LANL go ahead and write a 3490 parallel tape driver for MVS that is a Unitree agent. Unitree (running on rs/6000) would control all standard operations ... but there would be a new feature added allowing data & control paths to be seperated ... with a modified "high-performance" Unitree FTP program running on the CM's SUN machine (CM external interfaces are controlled thru Sun machines). It would talk to the Unitree RS/6000 server code, but requesting parallel tape migration. The RS/6000 would notify the MVS parallel tape agent ... and there would be a direct HIPPI data path set up between the data vault to the MVS/3090 for actually moving the data. In effect, the 3090/MVS system would be operating as a tape controller for the Unitree/RS6000 system. As another aside, ********* commented that Convex has given all of their Unitree high-performance enhancements back to ******* for encorporation into the standard product. And for one of my favorite subjects ... that I also brought up when we were dealing with the NCAR/Mesa possibilities ... was the significant advantages of using a Semantic Net in the Unitree Nameserver (i.e. effectively the function that implements the file directory). ******** and some of the other people wanted to specifically follow-up on that. I related one of the things that we had looked at in the NCAR/Mesa timeframe regarding all the NASA tapes containing images of the back side of the moon ... and the difficulty in being able to find any specific image &/or images that fit specific criteria. .... snip ...
From: Eugene Miya on 9 Nov 2006 18:45 > > You guys have never talked about Cray disk. 8^) >> Much less the hardware aspects of their file systems. In article <4rhn8dFr6he0U1(a)mid.individual.net>, =?ISO-8859-1?Q?Jan_Vorbr=FCggen?= <jvorbrueggen(a)not-mediasec.de> wrote: >Yes. Or the thing TMC built - what was it called, The Data Vault? Hey, I speak the truth. Unless I am trolling for data. ;^) Yes, I have to find a Data Vault for the Museum, a big bank of 80 MB Fujitsu disks later the 160 MB Eagles. Now I carry 2 GB on my Swiss Army Knife. >> They likely do more in house work as integration > >But we weren't talking the TLA's inhouse work, we are talking what >Cray et al. did for them seemingly in the open. Even if it was just >consulting - you can't just hide a few thousand person years from the >bottom line. You guys have never mentioned the other consulting firms Cray belong to which is not a thing that I should start off. I suspect Jan that you are thinking too business like. I think ...I have to think how to word this a fair portion of stuff is out there but people don't know how and how to read into it. And I don't mean to be too coy, because I don't have a clearance. I don't want to lose chances to visit. You can't easily hide stuff with publically traded firms and you can do more with privately traded ones but it is doable. >Look at the effect of GCHQ inventing asymmetric crytography...which was >non-existent. Some years later, three guys in academia have the same idea, >publish it, and now it's in everybody's online banking system. Yes, we just held a celibration on that last week. Whit was there, Betzos was there. I would not quite say online banking. A form is sort of there. I would have said 5 academics (D-H and RSA). But I think that's more symmetric. >Just on principle, I don't like systems without feedback and control, like >the spooks are. No, we are merely out of their loop. At best we are on their periphery. You guys can ask similar questions of the various versions of the IBM STRETCH and where it sat in what systems. --
From: Eugene Miya on 9 Nov 2006 18:47 In article <0glc24-qqu.ln1(a)monolith.nodomain>, Glen Overby <coreSPAMsample(a)charter.net> wrote: >Del Cecchi <cecchinospam(a)us.ibm.com> wrote: >>We have disk drives because of them? Who does this refer to? Certainly >>not CDC or Cray (company or man). The customer for the first RAMAC I thought was the Fort. Certainly close if not the first. CDC had a line of pretty drives resold as the RP06 and other models. >I don't know what Eugene was refering to, but the Seagate facility in >Shakopee, MN has its roots in the CDC disk drive division (spun off from CDC, >as I recall, as Imprimis). Not that they _invented_ the disk drive, and >they've certainly advanced well beyond what they were doing as CDC. Anyways I'm out of here for the weekend. --
From: Eugene Miya on 9 Nov 2006 18:54 In article <1163117623.406960.182080(a)i42g2000cwa.googlegroups.com>, <lynn(a)garlic.com> wrote: >From: lynn >Date: Fri, 8 Mar 91 17:55:16 EST >Subject: LANL Unitree meeting Ah UniTree (now EMC). The DOE's attempt at a universial bit file system. >We just got back from a joint LANL/LLNL/Discos/IBM meeting at Los >Alamos (we also had an earlier Unitree/IBM/ACSC meeting on Tuesday in I wonder how the storage war is going to shape up? Will tape really die as Jim Gray predicts or will tape drives be relgated to data retrieval devices or one last read off tape? >As another aside, ********* commented that Convex has given all of >their Unitree high-performance enhancements back to ******* for >encorporation into the standard product. This implies Convex was in UniTree's camp. Convex had their very storage manager CSM which was not a bad system but never caught on. Too bad it never got along past 2.0. >And for one of my favorite subjects ... that I also brought up when we >were dealing with the NCAR/Mesa possibilities ... was the significant >advantages of using a Semantic Net in the Unitree Nameserver (i.e. Hey Tim Berners-Lee has taken that name now. >effectively the function that implements the file directory). >******** and some of the other people wanted to specifically >follow-up on that. I related one of the things that we had looked at >in the NCAR/Mesa timeframe regarding all the NASA tapes containing >images of the back side of the moon ... and the difficulty in being What? >able to find any specific image &/or images that fit specific >criteria. --
From: lynn on 9 Nov 2006 20:31
Eugene Miya wrote: > This implies Convex was in UniTree's camp. Convex had their very > storage manager CSM which was not a bad system but never caught on. > Too bad it never got along past 2.0. re: http://www.garlic.com/~lynn/2006u.html#19 Why so little parallelism? it wasn't a "camp" thing ... there was proposal from several of the NSF funded supercomputing centers (CNSF, NCSA, PSC, SDSC) for NSF funding for evaluation and selection of a common mass storage archive solution ..... which strongly leaned towards Unitree on Convex platform. Just another one of those things that was happening in the transition from strictly proprietary software to more open environment. We got pulled into situation to push unitree on rs6000 as an alternative solution. |