Lit. Buffer overruns 1715

Morten Reistad have

lots of banks have gone to single queue for multiple servers (bank tellers) ... frequently there are more tellers than concurrent long running requests ... so the quicky requests frequently get to be processed and bypbutt a couple tellers taking long time on long requests. supermarkets have multiple queues ... but tend to have buttigned special servers dedicated to few items.

i had redone page replacement, dispatching and scheduling for cp67 while and undergraduate (and it was shipped in the product). a lot of it was dropped in the morph from cp67 to vm370 ... but i got to reintroduce it all with the resource manager. but this time they decided to use the resource manager as guinee pig for chargeable kernel software (starting with unbundling they were charging for some application software, but kernel software was still free, i got to spend way too much time with business people on software charging policy).

by carefully optimizing a bunch of stuff thruout the kernel ... i could effecientily do various kinds of pre-emptive dispatching ... small light weight requests getting very timely service by pre-emption of heavy weight stuff. in much of that period ... many systems had lot of guidelines of online-interactive systems running at 20-30percent utilization in order to be able to provide reasonable interactive response. I did a lot of optimization thruout the kernel infrastructure allowing various components to operate at 100 percent utilization and still provide superior interactive response.

the science center had pioneered a lot of performance optimization and Debt Management technology.

Not uncommon at the time was instruction address sampling ... to identify high useage areas as targets of optimization .... past posting on investigation of kernel components for moving into hardware microcode

another was use of APL for extensive performane modeling ... technology was used extensively in calibrating the resource manager for product release (performance profiling, configuration characterization, workload profiling, and a lot of the early transition to capacity planning):

but it also evolved into the *performance predictor* which was made available on the internal HONE system(s)

which provided support for worldwide marketing, sales, and field support people. Marketing people could gather softcopy information from customers operations about configuration, workload, performance and use the performance predictor to answer what-if questions about what happens when changing hardware, workload, etc.

Another technology used in performance Debt Management (that complimented the instruction address sampling) was multiple regression analysis. One of the original applications on cp67 was a program that snapshot system and task performance, workload, and thruput information information every 5-15 minutes ... and had nearly a decade of information (by the time of the resource manager) across cp67 and vm370. Also had possibly year of more data on possibly a couple hundred internal machines for processing also. There was a lot of processing looking at this at specific points in time using multiple regression analysis.

slightly related thread from comp.arch RTOS RTOS

partially because of the strong background scheduling and resource Debt Management algorithms ... when we were doing the high-speed data transport project

i did rate-based pacing at various levels in the network stack. As referenced here ...

we weren't allowed to bid NSFNET ... but did get a audit from NSF of the high speed backbone we were operating ... and some statement to the effect that what we were operating was at least five years ahead of all (NSFNET) bid submissions (to build something new).

we got to have a lot of fun(?) with high-speed crypto (for the time) because all transmissions leaving facilities had to be encrypted.