Larrabee delayed: anyone know what's happening?
|
Prev: PEEEEEEP
Next: Texture units as a general function
From: Del Cecchi on 25 Dec 2009 15:31 "Robert Myers" <rbmyersusa(a)gmail.com> wrote in message news:2f27ed88-f2db-4cde-a4b2-4016cd52805a(a)21g2000yqj.googlegroups.com... On Dec 25, 4:07 am, Bill Todd <billt...(a)metrocast.net> wrote: > Why try to use channel terminology to describe a configuration that > doesn't really fit it? IIRC the XT (ISA) bus didn't support masters > other than the host system: if so, then (at least from the hardware > viewpoint) the host called the shots (as it does in the channel > approach) but also handled the I/O devices (as it does not in the > channel approach). I wanted to elicit as specific an answer as I could, so I used a concrete example. PCI/XT bus devices could do bus mastering, so far as I know, but I'm not sure why it's relevant. It would have been not all that difficult to have intercepted I/O going either way to the 32- bit system and done whatever one cared to with it, so I'm still not sure what a mainframe channel has, other than careful and expensive engineering that pays far more attention to reliability than anything available outside the world of mainframes. Thanks for your explanations, which give me a much clearer picture of the various choices. Robert. ----------------------------------------- Please note that mainframe channels were first used on S/360 which came out in the mid 60's. They have evolved considerably since then. Perhaps you could discuss what the contemporary systems were doing at the time? GE 60x, Sperry Univac, SDS? What was DEC building? PDP8? PC's were not even a gleam in anyone's eye. del (sorry for goofy attribution)
From: Del Cecchi on 25 Dec 2009 15:41 "Anne & Lynn Wheeler" <lynn(a)garlic.com> wrote in message news:m3k4wb2bib.fsf(a)garlic.com... > > hmy1 <hmy1(a)aol.com> writes: >> IBM's System z (lastest mainframe brand name) I/O technology has >> alot >> of value and is an industry standard (T11.org, FC-SB-4). >> Just to mention a few differentiators from FCP: > > i've got lots of old email from the FCS mailing list about all the > churn > the pok channel engineers were causing ... trying to overlay > half-duplex, end-to-end serialized paradigm on top of the underlying > full-duplex asynchronous FCS. > > part of this was escon technology had been laying around pok, > unannounced for possibly a decade (but used for mainframe channel > paradigm was half-duplex, end-to-end serialization. one of the > rs/6000 > engineers took it, did some tweaking (which made it incompatible, > full-duplex, etc). then he wanted to do a 800mbit version ... and we > had > been involved in the FCS activity ... and managed to talk him into > getting involved with FCS instead. Then the pok channel engineers > got > involved in standardization activity (not so much on the basic > standard > ... but trying to overlay stuff on top of the underlying standard). > > alternative example was the serial copper, full-duplex asynchronous > stuff that Hursley did (Harrier/9333) ... with effectively > packetized > scsi commands. we spent some effort trying to get harrier morphed so > that interoperated with FCS ... but in turned into "SSA" instead. > > referenceed here ... in old post related to ha/cmp & ha/cmp scaleup > http://www.garlic.com/~lynn/95.html#13 > > -- > 40+yrs virtualization experience (since Jan68), online at home since > Mar1970 Lynn, you seem to have an allergy to ever mentioning Rochester, Rochester engineers, or Rochester products. Who was this "RS6000 Engineer". And Pok had to be dragged kicking and screaming away from their fixation on doing optics with LEDs instead of short wave lasers. Rochester had independent line of systems (S/3, S/32, S/34, S/36, S/38, AS/400 and follow ons). We also had independent line of CRT Terminals, the 525x series, connected to the system by our own twinaxe loop protocol that predated token ring. Rochester also had a line of Key to disk systems and intelligent workstations 5208. Yet your posts have an almost sovietesque aversion to mentioning them. del
From: Anne & Lynn Wheeler on 25 Dec 2009 16:38 "Del Cecchi" <delcecchi(a)gmail.com> writes: > Lynn, you seem to have an allergy to ever mentioning Rochester, > Rochester engineers, or Rochester products. Who was this "RS6000 > Engineer". And Pok had to be dragged kicking and screaming away from > their fixation on doing optics with LEDs instead of short wave lasers. > > Rochester had independent line of systems (S/3, S/32, S/34, S/36, > S/38, AS/400 and follow ons). We also had independent line of CRT > Terminals, the 525x series, connected to the system by our own twinaxe > loop protocol that predated token ring. Rochester also had a line of > Key to disk systems and intelligent workstations 5208. Yet your posts > have an almost sovietesque aversion to mentioning them. Most of the stuff is things that I did and/or at least had dealings with (or maybe my wife). for instance ... there was this 16-way 370 SMP thing ... which everybody thought was just great. we had even convinced some of the processor development 3033 engineers to work on it in their spare time ... which is where I some of the blow-by-blow about 303x stuff. somewhere along the way ... somebody informed the head of POK that it might be decades before the POK favorite son operating system had 16-way support ... at which point some number of people were invited to not visit pok again (and the 3033 engineers directed to get their noses back to the grindstone). i had little to do with rochester ... did do a lot with pok and san jose .... and was in austin for a time and did ha/cmp & some ha/cmp cluster scaleup (before it got transferred and we were told we couldn't work on anything with more than four processors). some related old email http://www.garlic.com/~lynn/lhwemail.html#medusa the referenced rs6000 engineer then shows up as "secretary" for FCS committee and managing the FCS standards documents. there was some number of people that left IBM austin and joined dell .... and some of the austin area computer meetings were hosted at dell. one of the rochester ibm fellows that did work on s/38 showed up at DELL. I believe I never even visited the rochester location. from the days when my wife was in POK and charge of (mainframe) loosely-coupled (cluster) architecture ... and responsible for peer-coupled shared data architecture http://www.garlic.com/~lynn/submain.html#shareddata she also was an inventor on IBM "ring" patent that I believe initially shows up as S/1 "chat ring". In any case, "peer-coupled shared data" saw very little uptake, except for IMS hot-standby ... until much later with sysplex ... big reason that she didn't stay long in the position. One of the guys in rochester that I had some dealings with worked on RCHVM (virtual machine) systems and VNET support ... and had some dealings when I was doing HSDT (high-speed data transport) activity http://www.garlic.com/~lynn/subnetwork.html#hsdt Most dealings that I had with rochester was that the made the chips for the rs/6000 serial link adapter (SLA ... aka the full-duplex tweaked escon ... 220mbits instead of 200mbits, etc). Since it was "proprietary" and didn't connect to anything else ... tried to figure out how to use it in "open system" environment. We talked NSC (HYPERChannel & later other stuff) into providing an SLA interface in their high-speed router .... however we had to make the chips available to them first. Turns out that we couldn't just send chips from Rochester to Minneapolis ... they had to be transferred from rochester to austin (at a 300% mark-up) and then austin had to transfer them from austin to minneapolis (at another 300% markup ... now 900% markup). This was for something that they thought we should be paying them for doing, as a favor for us. i was involved in some early 801 iliad & romp stuff http://www.garlic.com/~lynn/lhwemail.html#801 the precursor to rs/6000 was the pc/rt. the pc/rt originally started out as ROMP processor with pl8 and cpr for follow-on to displaywriter (aka Austin was office product division ... OPD). When that was canceled, they looked around and settled on selling it into the unix workstation market instead. They got the company that had done the AT&T unix port to the ibm/pc (for PC/IX) to do one for ROMP (aka pc/rt). misc. other posts mentioning 801, romp, rios, iliad, etc http://www.garlic.com/~lynn/subtopic.html#801 To: wheeler (as well as others) From: <corporate NETMAP> Date: 01/22/80 14:21:40 Greetings, There are 2 new nodes that should be added to the network: BCRCPS which is a 148 VM system located in Boca Raton connected to BCR68A via a 4800 line. RCHVM1 which is a 158AP VM system located in Rochester, Minn connected to RCH648 via a 9.6 line .... snip ... The internal network was larger than the arpanet/internet from just about the beginning until sometime late '85 or early '86 ... some past posts http://www.garlic.com/~lynn/subnetwork.html#internalnet I did an edit macro that would take "structured" network notifications and automatically do the correct thing ... post with some of the structured notifications in '83 (when arpanet moved to internetworking protocol and started to exceed 255 nodes ... and the internal network exceeded 1000 nodes) http://www.garlic.com/~lynn/2006k.html#8 as well as list of corporate locations that had new/additional nodes added during 1983. Date: 02/21/80 06:23:27 To: "world" From: <somebody in rochester> Greetings ! Its been a L-O-N-G time, but I finally made it ! With this VMSG I am announcing that I am again back on the NETWORK at a new node in Rochester, Mn (GSD) named 'RCHVM1'. My userid is 'xxxxxx' (as in Boulder). Please change all nickname files to reflect this change. Its good to be "home". .... snip ... -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970
From: Anne & Lynn Wheeler on 25 Dec 2009 17:08 .... addenda ... in 1980 ... i wrote a bunch of mainframe software to support (NSC) HYPERChannel use at corporate internal datacenters ... and then tried to have a joint release (with NSC) of the software to customers (NSC eventually had to recreate the stuff from scratch). it appeared that major objection preventing me from releasing that software ... was from the channel people in POK trying to get their fiber technology out as ESCON (viewing hyperchannel as competition) .... some possibly later involved in all the gorp of overlaying FICON on top of FCS. one of the disk engineers in san jose that I worked some with ... got '78 patent on raid technology (predates "RAID" by nearly a decade). However, I believe S/38 had the first ship of raid technology. S/38 treated all the available disks as one large pool ... simplifying a lot of things ... common failure mode was single disk failure ... which in common pool design, brought down the whole system. RAID was needed to mask such single disk failures ... (from taking down the whole infrastructure). However, s/38 then required full infrastructure backup .... and full infrastructure restore ... to handle other kinds of failure/recovery. s/38 configurations were somewhat notorious for taking a long time for getting something back up and running ... since complete restore could take a long time. misc. past posts in this thread: http://www.garlic.com/~lynn/2009s.html#18 Larrabee delayed: anyone know what's happening? http://www.garlic.com/~lynn/2009s.html#20 Larrabee delayed: anyone know what's happening? http://www.garlic.com/~lynn/2009s.html#22 Larrabee delayed: anyone know what's happening? http://www.garlic.com/~lynn/2009s.html#23 Larrabee delayed: anyone know what's happening? http://www.garlic.com/~lynn/2009s.html#29 channels, was Larrabee delayed: anyone know what's happening? http://www.garlic.com/~lynn/2009s.html#30 Larrabee delayed: anyone know what's happening? http://www.garlic.com/~lynn/2009s.html#31 Larrabee delayed: anyone know what's happening? http://www.garlic.com/~lynn/2009s.html#32 Larrabee delayed: anyone know what's happening? -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970
From: Stephen Fuld on 25 Dec 2009 17:36
Del Cecchi wrote: snip > Perhaps you could discuss what the contemporary systems were doing at > the time? GE 60x, Sperry Univac, SDS? What was DEC building? PDP8? > PC's were not even a gleam in anyone's eye. I can do some of that. But before I do, let me make clear that a lot of what has loosely be called channel functionality is really implemented not in the channel, but in the disk controller. Thus, search, for example, is not available on channel attached tape systems. So, let's start by saying that AFAIK no other vendor did CKD (the functionality that allowed a lot of the ingenious but baroque functionality) or things like it. It is generally regarded, even by IBM, as a mistake, for a large number of reasons. AFAIK, every other vendor, and even IBM with its Rochester designed systems, and even VM and DOS/VS on the S/360 follow ons, supported disks formatted into an "array" of fixed length blocks, though of course different systems used different block lengths. But other vendors did things like channels. Sperry/Univac, dating back even further than the S/360 had channels, though despite the same name, were different from what IBM called channels. For example, the 1108, which was roughly contemporaneous with the S/360 had up to 16 channels per CPU. Each had two cables, one for input, the other for output. Each cable had 36 data lines (to correspond with the 36 bit words of the 1108, and a few control lines. They were "activated" by CPU instructions; there were no "channel programs". But it took typically only two to three instructions to initiate an I/O so this wasn't a hardship. The channels supported scatter/gather as well as termination by either an external interrupt (from the device) or based on a word transferred count. I believe that Burroughs had an I/O backplane, into which different cards (called data link processors, or DLPs) could be placed. There were different types of DLPs for different peripheral types. CDC, had separate CPUs, called Peripheral Processors to do I/O. I don't know about any others. -- - Stephen Fuld (e-mail address disguised to prevent spam) |