REAL memory column in SDSF 4605
say 6bits of storage key per 4k bytes is lost in the noise? (2k storage keys as well as 2k virtual pages having been dropped around 3081 xa time-frame) ... if you wanted to worry about something ... there was 16bit ecc for every 64bit double word (or 2bits per 8bit byte ... as opposed to parity bit per 8bit byte) ... optimizations were trying to get failure coverage (better than simple 1bit-byte parity) with less than 80bits (for 64bit of data) ... like 78bits, 72bits, etc ...
REAL memory column in SDSF 4604
processing latency ... this was if you would to do multiple consecutive full track transfers ... with head-switch to...
press release on ecc from 1998
another discussion of memory ecc
in response to off-list comment about 360 model storage sizes ... see this reference:
note that 1mbyte and 2mbyte, IBM "LCS" 2361 was offered ... but I remember a number of installations having 8mbyte "Ampex" LCS.
the claim was that 3090 extended store memory chips was effectively the same as regular memory chips ... because ibm had really good memory yield. however, there was a vendor around 1980 that had some problems with its memory chip yield involving various kinds of failures that made the chips unuseable for normal processor fetch-store (memory).
so a bunch of these "failed" memory chips were used to build 2305 (fixed head disk) clone ... and a fairly large number of them (maybe all that the vendor could produce) were obtained for internal use ... using a "model" number of 1655 for use as dedicated paging devices on internal VM timesharing systems. The claim was that they were able to engineer compensation (for various chip problems) at 4k block transfer boundary that wouldn't be practical if you were doing standard processor fetch-store. some recent posts mentioning the 1655 2305-clone paging devices:
for other drift ... there was a lot of modeling for 3090 balanced speeds&feeds ... part of it was having sufficient electronic memory to keep the processor busy (which then led to the extended store stuff)
A Day For Surprises Astounding Itanium Tricks 4598
there have been various looks at doing 360-370 simulation on itanium (porting existing i86 simualtors...
part of the issue was using electronic memory to compensate for disk thruput. starting in the late 70s, i was making statements about disk relative system thruput had declined by an order of magnitude over a period of years. the disk division buttigned the performance and modeling group to refute the statement. after a period of several weeks, they came back and mentioned that i had actually slightly understated the problem ... the analysis was then turned around into a SHARE presentation on optimizing disk thruput (i.e. leveraging strengths and compensating for weaknesses). misc. posting referencing that share presentation
one of the issues that cropped up (somewhat unexpectantly) was the significant increase in 3880 (disk controller) channel busy. the 3090 channel configuration had somewhat been modeled buttuming 3830 control unit channel busy. the 3830 had a high performance horizontal microcode engine. for the 3880, they went to a separate processing for the data path (enabling supporting 3mbyte-sec and then 4.5mbyte transfers), but a much slower vertical microprogrammed engine for control commands. this slower processor significantly increased channel busy when processing channel controls-commands (compared to 3830).
a recent post discussion some of the problems that cropped up during 3880 development (these showed up before first customer ship and allowed some work on improvement)
however, there was still a fundamental issue that 3880 controller increased channel busy time per operation ... greater than had been anticipated. in order to get back to balanced speeds&feeds for 3090 ... the number of 3090 channels would have to be increased (to compensate for the increased 3880 channel busy overhead).
now, it was possible to build a 3090 with relatively few TCMs. the requirement (because of increased 3880 channel busy) to increase the number of channels resulted in requiring an additional TCM for 3090 build (for the additional channels) ... which wasn't an insignificant increase in manufacturing cost. at one point there was a suggestion (from pok) that the cost of the one additional TCM for every 3090 sold ... should be taken from sanjose's bottom line (as opposed to showing up against POK's bottom line).
the overall situation might be attributed to the after effects from the failure of FS
a big driving factor in FS was countermeasure from clone-plug compatible controllers ... some collected postings having been involved in greating plug compatible controller as an undergraduate
however, from this article on FS (by one of the ibm executives involved)
IBM tried to react by launching a major project called the 'Future System' (FS) in the early 1970's. The idea was to get so far ahead that the compebreastion would never be able to keep up, and to have such a high level of integration that it would be impossible for compebreastors to follow a compatible niche strategy. However, the project failed because the objectives were too ambitious for the available technology. Many of the ideas that were developed were nevertheless adapted for later generations. Once IBM had acknowledged this failure, it launched its 'box strategy', which called for compebreastiveness with all the different types of compatible sub-systems. But this proved to be difficult because of IBM's cost structure and its R&D spending, and the strategy only resulted in a partial narrowing of the price gap between IBM and its rivals.
... snip ...
i.e. the 3880 "box strategy" might be construed as sub-optimal from an overall system perspective.
for other drift ... recent postings about san jose disk