Phil Payne wrote:
I've mentioned this before, but Fundamental Software has a huge collection of
manuals and old
equipment. When I was there once I wandered around their lab and saw just
about every device
I could remember. They have the old parallel channel cable assembly machine
and all sorts of
prehistoric stuff. I know they have the maintenance carts for most equipment
and there's just
a chance they have some duplicates.
I remember the 3880 rollout, since the damn thing plays fast and loose with the
channel
timings - it doesn't conform to the OEMI. I think the actual tag timing it
uses is in the
Functional Characteristics manual.
There also used to be a contraption called a "Holly Box" for checking a
controller's tag
timing.
bus&tag supposedly max'ed at aggregate channel cable distance of 200ft
and 1.5mbytes/sec ... although i seem to remember actual devices like
2305 had more like 80ft cable distance. there was end-to-end handshake
on every byte transferred.
datastreaming relaxed requirement for end-to-end handshake on every byte
... which allowed it to double the aggregate channel cable distance to
400ft and the data rate to 3mbyte/sec.
the 3880 controller supported datastreaming and 3mbyte/sec transfer (for
3380 drives). the 3880 disk controller went from the (fast) horizontal
microcode engine in the 3830 handling everything to a split operation
with vertical microcode engine jib-prime handling control functions and
a special hardware path for data transfer in the 3880.
the 3880 supposedly was required to pass a product performance
acceptance test of being within 10% of 3830. for the test they used as a
two-drive VS1 system doing identical job stream with 3830 controller and
then replaced with 3880 controller (using same 3330 drives).
there was a problem with the jib-prime having higher latency processing
commands and control operations than the 3830 ... and so they tried a
little slight-of-hand. They raised operation complete to the channel
before all the control unit functions had completed. For the VS1
acceptance benchmark, this allowed the completion of controller
operation cleanup to be overlapped with the VS1 interrupt process and
i/o handling (reflecting it back up to the application, and the
application scheduling the next operation).
I had done this rewrite of the input/output supervisor for engineering
lab (bldg. 14) and the product test lab (bldg.15)
http://www.garlic.com/~lynn/subtopic.html#disk
they had tried doing hardware development testing of single unit
(testcell) in an MVS environment ... and the i/o operation anomolies and
errors resulted in 15min. mean-time-between-failure for the MVS system.
My rewrite of input/output supervisor was so that the system wouldn't
ever fail (because of anomolies and/or errors for i/o activity) doing
concurrent testing of multiple devices and at the same time running
under the table computer services for the engineers (i.e. prior to that
all testing had been stand-alone bare machine ... on several dedicated
processors).
since i was responsible for the software ... when there was significate
anomolies with development hardware ... i would be the first to be
blaimed (i.e. software not hardware) and would have to diagnose the problem.
about 10am one monday, i got a call from the engineers in the product
test lab. they a 3033 (something like the second engineering machine
from the pok plant). we had gotten it configured with a bootlegged 3830
controller and 16 3330 drives for private timesharing computing service
... in addition to its function of concurrent product test of several
development devices (which previously had to be done one at a time with
scheduled, bare machine time). The product test stuff rarely accounted
for a couple percent of the machine ... so the rest of machine we could
use for our own purposes.
In any case, the monday mid-morning call was that the timesharing
thruput and response had gone all to pieces and "what had I changed over
the weekend". Since I hadn't changed anything, I had to discover what
changes they had made (which they initially denied doing any changes at
all).
So a lot more diagnosing and eventually found over the weekend that the
engineers had replaced the 3830 disk controller (for the 16 3330 drives)
with a new product test 3880 controller. Lots more diagnostic and
strobing regarding what the 3880 controller was doing turned up a real
performance problem with the 3880 controller. While the two-pack VS1
performance acceptance test had the gimick that the 3880 was presenting
completion early ... allowing some of the 3880 processing latency to be
overlapped with VS1 I/O processing .... the VS1 was essentially doing
sequential, serialilzed disk i/o.
The 16 3330 drives and any reasonable set of concurrent activity ... was
finding that when the 3880 completion was handled by the interrupt
processor ... I would frequently have queued I/O activity and
immediately redrive the 3880 with a new operation (while it was still
busy trying to cleanup from the previous request). The result was that
the controller had to reflect controller busy (cc=1, csw stored,
SM+BUSY) to the i/o initiation. That met that I had to requeue the
request that I had just attempted to start (on the pending queue).
Finally when the 3880 had completed whatever it was doing, since it had
reflected SM+BUSY, it now had to present a (new) control unit end (CUE)
interrupt indicating that it was now free. This caused a lot of extra
processing in both the 3880 controller and also in the software ... as
well as resulting in significant additional delays for I/O operations.
So it was back to the drawing board ... trying to make the 3880 control
function processing more efficient and closer to that of the previous
3830 disk controller. Fortunately, at the moment, we were still six
months away from 3880 first customer ship.
By first customer ship, processing had gotten better, but some things
weren't as good as 3830. Both 3880 and 3830 had provisions for multiple
channel interfaces. However, there was an enormous amount of 3880
processing and latency when switching from one channel interface to
another channel interface (on two consecutive i/o requests coming in on
different channel interface). I had done this really nifty and
super-efficient multiple channel thruput and load balancing support
(being able to maximize use of all possible channel interfaces from the
same processor). However, the channel switching overhead in the 3880
controller was so enormous that I had to fall back to much simpler
alternate path processing when dealing with 3880.
----------------------------------------------------------------------
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
