Re: Architectural implications of locate mode I/O

Liste des GroupesRevenir à c arch 
Sujet : Re: Architectural implications of locate mode I/O
De : lynn (at) *nospam* garlic.com (Lynn Wheeler)
Groupes : comp.arch
Date : 06. Jul 2024, 02:35:50
Autres entêtes
Organisation : Wheeler&Wheeler
Message-ID : <87frsnwbd5.fsf@localhost>
References : 1 2 3
User-Agent : Gnus/5.13 (Gnus v5.13)
John Levine <johnl@taugh.com> writes:
By putting most of the logic into the printer controller, the 1403 was
not just faster, but only took a small fraction of the CPU so the
whole system could do more work to keep the printer printing.

360 "CKD DASD" and multi-track search trade-off. 360s had relatively
little real storage (for caching information) and slow processor, so for
program libraries on disk ... they created "PDS" format and had (disk
resident, cylinder aligned) directory that contained records for name of
each program and its disk location in the library. To load a program, it
first did a "multi-track" search of of the PDS directory started at
track 0 of the 1st cylinder of the directory ... ran until it found name
match (or reached end of cylinder). If name wasn't found at end of
cylinder, it would restart if there were additional cylinders in the
directory. Trivia: the searched-for program name was in processor memory
and the multi-track search operation would refetch the name every time
it did a compare for matching name (with records in the PDS directory),
monopolizing channel, controller, & disk.

Roll forward to 1979, a large national grocery chain had large
loosely-coupled complex of multiple 370/168 systems sharing string of
DASD containing the PDS dataset of store controller applications ... and
was experiencing enormous throughput problems. All the usual corporate
performance specialists had been dragged through the datacenter with
hopes that they could address the problem ... until they eventually got
around to calling me. I was brought into large classroom with tables
covered with large stacks of activity/performance reports for each
system. After 30-40 mins examaning the reports ... I being to realize
the aggregate activity (summed across all systems) for specific shared
disk was peaking at 6-7 (total) I/O operations ... and corresponding
with severe performance problem. I asked what was on that disk and was
told it was the (shared) store controller program library for all the
stores in all regions and 168 systems; which I then strongly suspected
it was the PDS multi-track search perfoerformance that I had grappled
with as undergraduate in the 60s.

The store controller PDS dataset was quite large and had a three
cylinder directory, resident on 3330 disk drive ... implying that on the
avg, a search required 1.5 cylinders (and two I/Os), the first
multi-track search I/O for all 19 cylinders would be 19/60=.317sec
(during which time that processor's channel was busy, and the shared
controller was also busy ... blocking access to all disks on that
string, not just the speecific drive, for all systems in the complex)
and the 2nd would be 9.5/60=.158sec ... or .475sec for the two ... plus
a seek to move the disk arm to PDS directory, another seek to move the
disk arm to the cylinder where the program was located
... approx. .5+secs total for each store controller program library load
(involving 6-7 I/Os) or two program loads per second aggregate serving
all stores in the country.

The store controller PDS program library was then split across set of
three disks, one dedicated (non-shared) set for each system in the in
the complex.

I was also doing some work on System/R (original sql/releational RDBMS)
and taking some flak from the IMS DBMS group down the road. The IMS
group were complaining that RDBMS had twice the disk space (for RDBMS
index) and increased the number of disk I/Os by 4-5 times (for
processing RDBMS index). Counter was that the RDBMS index significantly
reduced the manual maintenance (compared to IMS). By early 80s, disk
price/bit was significantly plummeting and system real memory
significantly increased useable for RDBMS caching, reducing physical
I/Os (while manual maintenance skills costs were significantly
increasing).

other trivia: when I transfer to San Jose, I got to wander around
datacenters in silicon valley, including disk engineering & product test
(bldg14&15) across the street. They were doing prescheduled, 7x24,
stand-alone mainframe testing. They mentioned they had recently tried
MVS, but it had 15min mean-time-between-failure, requiring manual
re-ipl/reboot in that environment. I offered to rewrite I/O supervisor
to make it bullet-proof and never fail enabling any amount of on-demand,
concurrent testing (greatly improving productivity). Downside was they
would point their finger at me whenever they had problem and I was
spending increasing amount of time diagnosing their hardware problems.

1980 was real tipping point as hardware tradeoff switched from system
bottleneck to I/O bottleck (my claims that relative system disk
throughput had declined by order or magnitude, systems got 40-50 times
faster, disks got 3-5 fasters).

--
virtualization experience starting Jan1968, online at home since Mar1970

Date Sujet#  Auteur
2 Jul 24 * Architectural implications of locate mode I/O64John Levine
2 Jul 24 +* Re: Architectural implications of locate mode I/O38Thomas Koenig
3 Jul 24 i+- Re: Architectural implications of locate mode I/O1MitchAlsup1
3 Jul 24 i+* Re: Architectural implications of locate mode I/O17MitchAlsup1
3 Jul 24 ii+* Re: Architectural implications of locate mode I/O6Lynn Wheeler
3 Jul 24 iii+* Re: Architectural implications of locate mode I/O2Lawrence D'Oliveiro
5 Jul 24 iiii`- Re: Architectural implications of locate mode I/O1Terje Mathisen
3 Jul 24 iii+* Re: Architectural implications of locate mode I/O2MitchAlsup1
3 Jul 24 iiii`- Re: Architectural implications of locate mode I/O1Michael S
3 Jul 24 iii`- Re: Architectural implications of locate mode I/O1Lynn Wheeler
3 Jul 24 ii+* Re: Architectural implications of locate mode I/O9Bill Findlay
3 Jul 24 iii`* Re: Architectural implications of locate mode I/O8Michael S
3 Jul 24 iii +- Re: Architectural implications of locate mode I/O1Bill Findlay
3 Jul 24 iii `* Re: Architectural implications of locate mode I/O6Stephen Fuld
3 Jul 24 iii  `* Re: Architectural implications of locate mode I/O5MitchAlsup1
4 Jul 24 iii   `* Re: wisdom of the ancients, was Architectural implications of locate mode I/O4John Levine
4 Jul 24 iii    +* Re: wisdom of the ancients, was Architectural implications of locate mode I/O2John Savard
4 Jul 24 iii    i`- Re: wisdom of the ancients, was Architectural implications of locate mode I/O1John Savard
4 Jul 24 iii    `- Re: wisdom of the ancients, was Architectural implications of locate mode I/O1MitchAlsup1
3 Jul 24 ii`- Re: Architectural implications of locate mode I/O1Stephen Fuld
3 Jul 24 i`* Re: Architectural implications of locate mode I/O and channels19John Levine
3 Jul 24 i +* Re: Architectural implications of locate mode I/O and channels9Anton Ertl
3 Jul 24 i i+* Re: Architectural implications of locate mode I/O and channels6Michael S
3 Jul 24 i ii+* Re: Architectural implications of locate mode I/O and channels4MitchAlsup1
4 Jul 24 i iii`* Re: Architectural implications of locate mode I/O and channels3Michael S
4 Jul 24 i iii +- Re: Architectural implications of locate mode I/O and channels1MitchAlsup1
5 Jul 24 i iii `- Re: Architectural implications of locate mode I/O and channels1Joe Pfeiffer
3 Jul 24 i ii`- Re: Architectural implications of locate mode I/O and channels1Michael S
3 Jul 24 i i+- Re: Architectural implications of locate mode I/O and channels1Robert Swindells
3 Jul 24 i i`- Re: Architectural implications of locate mode I/O and channels1John Levine
4 Jul 24 i `* Re: Architectural implications of locate mode I/O and channels9Thomas Koenig
4 Jul 24 i  `* Re: Architectural implications of locate mode I/O and channels8MitchAlsup1
4 Jul 24 i   `* Re: Architectural implications of locate mode I/O and channels7Thomas Koenig
5 Jul 24 i    +* Re: Architectural implications of locate mode I/O and channels5John Levine
5 Jul 24 i    i`* Re: Architectural implications of locate mode I/O and channels4MitchAlsup1
7 Jul 24 i    i `* Re: Architectural implications of locate mode I/O and channels3Paul A. Clayton
7 Jul 24 i    i  +- Re: Architectural implications of locate mode I/O and channels1Lynn Wheeler
7 Jul 24 i    i  `- Re: patents, Architectural implications of locate mode I/O and channels1John Levine
5 Jul 24 i    `- Re: Architectural implications of locate mode I/O and channels1MitchAlsup1
3 Jul 24 +- Re: Architectural implications of people who don’t understand locate mode I/O1Lawrence D'Oliveiro
5 Jul 24 `* Re: Architectural implications of locate mode I/O24Joe Pfeiffer
5 Jul 24  +* Re: Architectural implications of locate mode I/O21John Levine
6 Jul 24  i+* Re: Architectural implications of locate mode I/O18Lynn Wheeler
6 Jul 24  ii+- Re: Architectural implications of locate mode I/O1MitchAlsup1
6 Jul 24  ii+* Re: Architectural implications of locate mode I/O14Stephen Fuld
6 Jul 24  iii+* Re: ancient disks, Architectural implications of locate mode I/O7John Levine
6 Jul 24  iiii`* Re: ancient disks, Architectural implications of locate mode I/O6Stephen Fuld
6 Jul 24  iiii `* Re: ancient disks, Architectural implications of locate mode I/O5John Levine
7 Jul 24  iiii  `* Re: ancient disks, Architectural implications of locate mode I/O4Stephen Fuld
7 Jul 24  iiii   `* Re: ancient disks, Architectural implications of locate mode I/O3Thomas Koenig
7 Jul 24  iiii    `* Re: ancient disks, Architectural implications of locate mode I/O2Thomas Koenig
7 Jul 24  iiii     `- Re: ancient disks, Architectural implications of locate mode I/O1Stephen Fuld
6 Jul 24  iii+- Re: Architectural implications of locate mode I/O1Lynn Wheeler
1 Aug 24  iii`* Re: Architectural implications of locate mode I/O5Lawrence D'Oliveiro
1 Aug 24  iii `* Re: Architectural implications of locate mode I/O4Stephen Fuld
1 Aug 24  iii  +* Re: Architectural implications of locate mode I/O2John Levine
2 Aug 24  iii  i`- Re: Architectural implications of locate mode I/O1Stephen Fuld
11 Aug 24  iii  `- Re: Architectural implications of locate mode I/O1Lawrence D'Oliveiro
8 Jul 24  ii`* Re: Architectural implications of locate mode I/O2Lawrence D'Oliveiro
8 Jul 24  ii `- Re: Architectural implications of locate mode I/O1Lynn Wheeler
6 Jul 24  i`* Re: Architectural implications of locate mode I/O2MitchAlsup1
6 Jul 24  i `- Re: Old printers, Architectural implications of locate mode I/O1John Levine
8 Jul 24  `* Re: Architectural implications of locate mode I/O2Lawrence D'Oliveiro
1 Aug 24   `- Re: Architectural implications of locate mode I/O1MitchAlsup1

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal