The Pankian Metaphor 3092

it turns out that the bias of doing a terminal i-o was suppose to be for helping trivial interactive response. the dynamic adaptive stuff was monitoring recent resource utilization ... as per

so a terminal i-o kicked off a new scheduling advisory deadline for a very short amount of resource consumption. the deadline was calculated 1) proportional quanta of resource consumption for the period (smaller quanta for doing terminal i-o resulted in sooner deadline) as well as 2) proportional to recent resource consumption against some policy (the default policy being fairshare).

if the default resource policy was fairshare ... users consuming more than their fairshare had all their deadlines prorated further into the future (slowing them down), if users were really trivial interactive, then their recent resource consumption would be less than their fairshare, as a result the prorated calculations made their deadlines sooner ... speeding them up. a user was ahead of their targeted resource consumption (and therefor got advisory scheduling deadline priorities that slowed them down) or behind their targeted resource consumption (somewhat implicit if they were actually trivially interactive ... and got advisory scheduling dealine priorities that speeded them up.

for users that were way behind in their targeted resource consumption, they would start to speed up their measured resource consumption (because of the advisory deadline priorities) ... as their measured resource consumption approached their targeted resource consumption, they would slow down until their measured resource consumption and their targeted resource consumption was in equilibrium.

so i did a joke for the resource manager (vm370 re-issue of the dynamic adaptive stuff i did as undergraduate for cp67 ... 30th anv of the product announce of resource manager coming up on may 11th).

i had done all this elaborate dynamic adaptive stuff to measure what was going on and dynamically adapt everything. parameters were available for changing specified policies ... at system level and individual user level. however, all the performance tuning stuff had been subsumed by the elaborate dynamic adaptive capability.

furthermore, there had been extensive benchmarking, calibrating and validating the dynamic adaptive capability across a wide range of workloads, configurations, and policies. recent posts mentioning that benchmarking, calibrating and validating effort (one series of 2000 tests took 3 months elapsed time to complete)

so as to the joke? well, somebody from corporate hdqtrs observed that all the existing state-of-the-art resource managers had elaborate parameters that could be set by installations (primarily for system tuning) and the resource manager would require equivalent capability before it could be released as a product. it wasn't possible to get across to the person that the elaborate dynamic adaptive capability subsumed all such features.

so i added some such parameters, published the calculations ... and of course all source was available (product was shipped in source maintenance form ... as well as applying the source changes for the resource manager to the base product). i even though clbuttes on how the calculations and parameters all worked.

in the early 90s, we were making a number of marketing trips to the far east for our ha-cmp product

i related an anecdoate from one such trip in this recent post

on one of the trips to HK, we were doing customer call on major bank ... and going up the elevator in the bank building with the external skeleton (there were some references to tinker toy building because of the external structure). from a younger person in the back of the elevator came a question ... are you the "wheeler" of the "wheeler scheduler"?, we studied you at the university.

so nobody had figured out the joke. as i've periodically referred to in the past, most system programmers tend to deal with states ... things are either in one state or another ... or in case of parameters, a specific value from a range.

the dynamic adaptive resource manager ... was much more of a dynamic feedback and feedfoward nature ... much more of a operations research methodology than a kernel programmer state methodology. In OR methodology calculations you tend to have parameters with characteristics like degrees of freedom. Now for the dynamic adaptive resource manager ... the parameters provided for people to set (other than the policy selection parameters) all fed into the same dynamic adaptive calculations as the base dynamic adaptive stuff. The dynamic adaptive stuff would iterate its values in the calculations ... changing the dynamic adaptive parameters to adapt to workload, configuration and how well things were going. The magnitude and range of the dynamic adaptive parameters recalculated at every interval had much larger degrees of freedom than the static set parameters (that corporate hdqtrs required to be added) for people to set.

So the dynamic adaptive resource calculations had great labreastude in dynamiclly adjusting its parameters to constantly and dynamically compensate for changes in configuration and workload ... as well as compensating for any staticly set parameters that people might be fiddling with (somewhat referred to as performance tuning witch doctors).

misc. past posts mentioning the elaborte joke in the resource manager:

--