marty zimelis wrote:
Phil,
Unless there was something else out there (a poster or whatever), that
would have been me doing a riff in my VM Performance classes, first for
Amdahl, then for Velocity. Your buddy's time frame is about right (15 years
ago). I was attempting to emphasize the impact of an RPS miss (show of
hands: who remembers what that was?) on response time.
The riff started by me "complaining" that I didn't have a good intuitive
grasp of how fast CPUs were (tens of nanosecond cycle times at that point),
so "let's slow down our timeframe and say a CPU cycle is one second. Then a
page fault from Xstore is satisfied in [nn minutes], a DASD I/O satisfied
from cache takes [mm hours] and one that has to go to the real disk takes
[kk days]. An RPS miss adds [I think it was 16 hours] to that."
i had started making statements that disk relative system thruput had degraded
by
an order of magnitude over a period of yr (processors had gotten much faster
than
disks had gotten faster)
at some pt, somebody in gpd (disk division) took exception and assigned the gpd
performance group to refute the statements. after several weeks, they effectively
came back and said that i had understated the degradation because taking into
account (the introduction of) RPS-miss actually made it worse.
they then put a different spin on the investigation and turned it into
share presentation on recommendations to improve thruput ... past post
with reference to SHARE 63 Presentation B874
http://www.garlic.com/~lynn/2002i.html#18 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2006f.html#3 using 3390 mod-9s
http://www.garlic.com/~lynn/2006o.html#68 DASD Response Time (on antique 3390?)
part of this was when i had started doing dynamic adaptive resource management,
i attempted to include (dynamic adaptive) scheduling to the bottleneck (as
undergraduate
in the 60s). in the 70s, bottlenecks started shifting from real storage to disk
...
and you started seeing real storage being used more and more as "caching"
... either outboard in devices ... or by the system directly in processor
storage (as means of attempting to compensate for disks growing system
thruput bottleneck). misc. past posts mentioning resource manager
http://www.garlic.com/~lynn/subtopic.html#fairshare
somewhat a side investigation was that we had implemented disk record
access trace and cache model in the late 70s. the cache model looked
at all sorts of trade-offs based on actual disk record access traces
(from a large number of different kinds of production environments)
one of the findings ... was given all other things being equal,
one large common system cache was always better than partitioning
the same amount of electronic storage out into channel-level,
controller-level, and/or device-level caches (from cache efficiency
standpoint). The counter forces have been that their have been
limitations on total system memory, cost differential between
different kinds of electronic storage, and/or processor overhead
in managing system-level cache.
of course this somewhat supported the work that i had (also
as undergraduate in the 60s) done on "global LRU" replacement
algorithms vis-a-vis "local LRU" replacement algorithms (some
work that was going on in the 60s about the same time i was
working on global LRU replacement). misc. past posts mentioning
replacement algorithms and cache management
http://www.garlic.com/~lynn/subtopic.html#wsclock
this even dragged me into a festish that brewed in the
80s over a stanford phd thesis on global lru replacement
vis-a-vis local lru replacement.
i had done the global lru replacement stuff that shipped
in cp67 (and later vm370 when the resource manager reintroduced
some cp67 technology back into vm370). the grenoble
science center had done work on implementing local lru
replacement for cp67 and published the results in
cacm in the early 70s. The cp67 global lru running
on cambridge science center machine and the cp67 local
lru running on grenoble science center machine were
the only live, production comparisons.
and for lots more topic drift regarding replacement
algorithms ... a couple recent posts
http://www.garlic.com/2007r.html#65 CSA 'above the bar'
http://www.garlic.com/2007r.html#75 Real storage usage - a quick question
