other trivia
in the wake of FS and mad rush ... 303x was kicked off ... as mentioned
3033 was 168 logic remapped to 20% faster chips ... that happened to
have ten times more circuits per chip. Using original 168 logic, 3033
would have been only 20% faster than 168 (aka 3.6mips). However, some
specific logic rework to use the larger circuits per chip got it up to
50% faster than 168 (4.5mips).
158 manufacturing had been enormously automated ... somewhat like what
they quote for incremental cost of an automobile rolling off the
line. The 158 integrated channel microcode was used for the 303x channel
director (158 engine w/o 370 microcode and with the integrated channel
microcode). 3031 was two 158 engines, one with just the 370 microcode and
a 2nd (channel director) with just just the integrated channel
microcode. A 3032 is 168-3 reworked to use 303x channel director for
external channels.
some benchmark numbers for LLNL ... looking at getting 70 4341s for
computer farm (precursor to modern GRID, cloud, and supercomputers)
158 3031 4341
Rain 45.64 secs 37.03 secs 36.21 secs
Rain4 43.90 secs 36.61 secs 36.13 secs
also times approx;
145 168-3 91
145 secs. 9.1 secs 6.77 secs
also had run in 35.77 on CDC6600. 158 370 was slower than 3031 because
the (single) 158 engine was being shared between the 370 microcode and
the integrated channel microcode (which ran even when channels were
idle).
Part of the original morph from cp67 (and 360/67) to VM370 (multiple 370
models) was vm370 had table of supported 370 models ... with various
model characteristics. As part of my moving from cp67 to vm370 ... old
email reference:
http://www.garlic.com/~lynn/2006v.html#email731212
http://www.garlic.com/~lynn/2006w.html#email750102
http://www.garlic.com/~lynn/2006w.html#email750430
... I replaced the static table of supported 370 models with dynamic
code to determaine the characteristics ... it made it much simpler to
deploy a csc/vm production system to different machines (like
engineering models) not included in the shipped static table of
supported machines. some posts discussion work at the scientific center
(why it was called csc/vm). some past scientific center posts
http://www.garlic.com/~lynn/subtopic.html#545tech
Later I transfer to San Jose research ... on the san jose plant site
(accross the street from bldgs. 14&15) and csc/vm morphs into sjr/vm.
Old 4341 email about engineering model processor cycle time includes
reference to checking the DSPSL value ... which is one of my dynamically
determined values ... old reference
http://www.garlic.com/~lynn/2006y.html#email790220
from my dynamic adaptive resource manager ... which was guinea
pig for starting to charge for system/kernel software (customers
referred to as "fair share" since the default resource management
policy was "fair share") ... some past posts
http://www.garlic.com/~lynn/subtopic.html#fairshare
then somebody leaks the benchmark numbers to the press ... and
they initially try to blame me ... reference
http://www.garlic.com/~lynn/2006y.html#email790226
--
virtualization experience starting Jan1968, online at home since Mar1970
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
