CDC CYBER 74: Performanceperikelen

Systeemperformance : "Poolse slimheid"

Tijdens een van de ECODU-conferenties werd door een systeemprogrammeur van de Universiteit van Krakau een lezing gegeven die al na vijftien minuten geëindigd was. De normale sessietijd was een uur. Achter het toenmalige "ijzeren gordijn" moest men minimaal een "presentatie" geven om uitgezonden te kunnen worden. Dit keer echter, zette de gepresenteerde ideeën de systeemprogrammeurs van het Physisch Laboratorium aan het denken (en het werk).

In het systeemgeheugen stond een tabel voor de PP-loader met "pointers" naar de juiste locatie van PP-programma’s op schijf of naar de locatie in het centrale geheugen. In de tabel waren een aantal "bytes" gereserveerd voor verwijzing naar PP code die vooraf geladen waren in het extended geheugen. Extended geheugen is iets dat noch de Pool, noch wij in ons systeem hadden. Van dat ongebruikte veld maakte hij slim gebruik om daarin de hoeveelheid aanroepen van het PP-programma bij te houden.
Door de tabel met een Fortran programma regelmatig uit te lezen en te vergelijken met de opgeslagen tellers van een vorige run kon je nagaan welke PP-programma’s vaak en welke in "bursts" aangeroepen werden. Binnen het zeer beperkte computergeheugen werd een deel gebruikt om de essentiële (bijv. foutafhandeling schijven) en de vele malen per seconde aangeroepen PP-programma’s op te slaan. Het laden wss dan een rechtstreeks lezen van een aantal geheugenwoorden en vergde dan geen schijf I/O. Uit de tellingen bleek de standaardselectie van welke PP’s in het dure geheugen stonden voor ons verre van optimaal te zijn. Een handmatige aanpassing van het systeem leverde een 10% snelheidsverbetering op.

Toch waren de systeemprogrammeurs nog niet tevreden. Met een load van een tiental PP-programma’s per seconde van de (trage) schijf, werden er enkele extra systeemaanpassingen bedacht. Na de initiële installatie van het systeem op schijf konden wij aan de hand van de eerder genoemde PP-load tabel en andere systeemtabellen uitvinden op welke plaats de circa 3.5 cylinders (14 schijfplaten boven elkaar) aan PP-programmabibliotheek op schijf startte. De bibliotheek werd nu zodanig heringedeeld dat eerst de minst gebruikte PP-programma’s op schijf geschreven werden. Dit totdat de reeds gedeeltelijk gevulde cylinder vol was. Dan werden de meest aangeroepen - niet in het computergeheugen staande - PP-programma’s zoveel mogelijk in de volgende gehele cylinder gepropt. Daarna werden de overige programma’s in de bibliotheek geplaatst. Hierdoor werd het aantal kopbewegingen van de schijfeenheden aanzienlijk gereduceerd en was de kans groot dat de te laden PP-code gemiddeld binnen een halve schijfomwenteling gelezen kon worden zonder enige beweging en positionering van de leeskop. Afhankelijk van het type werk, werd hiermee nog een 5-10% performancewinst geboekt.

Naast de primaire systeembibliotheek, werden "tijdelijke" systeemwijzigingen (EDITLIB(SYSTEM)) in een tweede bibliotheek bijgehouden. Deze bibliotheek werd - middels een aantal wijzigingen in het standaard operating systeem - op een andere schijf geplaatst (technisch gezien werd het SYS-bit verschoven). Door nogmaals dezelfde truuk uit te halen en veelgebruikte PP-programma’s "te vervangen" door een kopie van "zichzelf", werd de tweede volle cylinder van de originale systeembibliotheek op de tweede schijf geplaatst.

Het performancevoordeel was onmiddellijk merkbaar voor de gebruiker. In meer dan 95% van de gevallen kon een PP-programma direct van een van de twee systeemschijven geladen worden zonder dat dit een enkele tientallen milliseconden vergende herpositionering van de schijfkoppen noodzaakte. Dit leverde een veel gelijkmatiger interactieve responsetijd op, betekende een versnelling in de doorvoersnelheid en zorgde voor een hogere CPU-bezetting per job (het systeem hoefde minder lang op I/O te wachten).

Toch weer performanceproblemen

In 1979 was de CPU-bezetting overdag 50%. In 1980 was die opgelopen tot 60%. De bezettingsgraad over 24 uur per dag was in 1979 23%. Via 32% in 1980 liep die op naar 43% in 1981.

In de loop van 1981 bleken er dan ook, ondanks de "Poolse en eigen slimheden", problemen op te treden met de interactieve responsetijden van de CYBER 74. Met behulp van een programma van SARA geschreven door Edo Roos Lindgreen en een Apple IIe microcomputer werden iedere 5 minuten een aantal eenvoudige interactieve commando’s afgevuurd op de CYBER. De PC mat daarbij de responsetijd en voegde deze toe aan een "file" op de CYBER. Gelijktijdig werden de responsetijden op de PC-monitor zichtbaar gemaakt voor de operators. Zodra er trage responsetijden optraden kon ingegrepen worden in de hoeveelheid batchwerk dat draaide.

Op basis van uitgebreide metingen aan de "uitgebouwde" CYBER met 14 PP’s en met een extra schijfbesturingseenheid kon aangetoond worden dat uitbreiding of vervanging van de CYBER absoluut noodzakelijk was. Naast de Apple IIe werden ook in het systeem zelf metingen verricht door een PP-programma dat om de tien seconden een "snap-shot" maakte van het systeem. Dit programma dat verkregen was van het European Center for Mid-Range Weather Forecasting (ECMWF) heette User Performance Measurement (UPM).
Vier extra PP’s en een extra schijfbesturingseenheid bleken de gemiddelde interactieve responsetijd (reactie op volgende invoer in een en dezelfde toepassing) terug te brengen van 1.5 naar 0.4 seconde. De gemiddelde afhandeling van 95% van de commando’s daalde van tien seconden naar 0.5 seconden. Het systeem had hiermee dus weer volop "lucht" gekregen.

Ook de verwerking van batchjobs was nogal eens "prioriteitsgevoelig". Jobs van gebruikers die twintig jobs gelijk aanboden werden nogal eens door de operator op prioriteit 0 - niet draaibaar - gezet en werden later niet snel weer opgestart. Hierdoor ging veel CPU tijd verloren, hetzij door onnodige idle-tijd, hetzij door rerun-tijd. De gebruikers zaten onnodig lang te wachten tot de jobs uitgevoerd waren. Daarnaast werd een "langere" job nogal eens door de operators naar achteren in de queue gezet, een en ander vaak op basis van persoonlijke voorkeur en inzichten (volgens de meeste gebruikers willekeur). Veel klachten waren het gevolg. In mei 1982 werd een nieuw prioriteitsalgoritme voor het in bewerking nemen van batchjobs in gebruik genomen. De volgende intrigerende prioriteitsformule werd gebruikt bij het bepalen van de startprioriteit in de queue:

2200B - ²log(CM*(T+ß*IO) + ²log(seconden_wachttijd) .

De parameter ß was 2 voor gewone jobs en 0.5 voor tape-jobs. De queue werd vervolgens op een slimme manier ge"aged". Ieder zijn batchjob kwam nu eerlijk "een keer" aan de beurt zonder dat daar veel operatorshandelingen voor nodig waren.

Nieuwe operators: stress-test

Het operatorconsole van het CYBER-systeem bestond uit twee ronde 15" kathodestraalbuizen. De tekens werden door middel van R-C-netwerkjes gegenereerd, waarbij de cirkels een nogal afgeplat uiterlijk hadden.
Nieuwe operators die na een aantal weken voor het eerst "even alleen" achter het console gelaten werden, werden onderworpen aan een stress-bestendigheidsproef. Vanaf een terminal werd het PP-programma EYE gestart, een eerste vorm van "trojan horse". Het PP-programma nam beide operator-consolebeelden over, maakte het scherm leeg, toonde vervolgens twee ovalen met daarin een "pupil", "keek" naar links, dan naar rechts, gaf een knipoog en verdween vervolgens weer als een spook in de nacht.... Collega’'s hadden zoiets natuurlijk nooit gezien... totdat de spel PP-programma’s en zogenaamde L-display programma’s aan de nieuwe operator getoond werden, zoals Chess, Life, Worm en Blob.

Noodkoeling

De CYBER 74 had zoals eerder gezegd waterkoeling welke de warmte van het freon-koelsysteem in de bays af moest voeren. Regelmatig moest het koelwater aangevuld worden vanwege lekkage. Op een gegeven moment gaf een bay van de CYBER 74 aan dat er koelingsproblemen waren. Gek genoeg schommelde de koelwatertemperatuur volgens de ingebouwde meter nogal hard. Het omschakelen van de koelwaterpompen hielp niet. Besloten werd om tijdens het volgende preventief onderhoud de driewegklep in de koelwatertoevoer te vervangen. Bij het losmaken van de leidingen bleek de oorzaak van het probleem. Uit kostenoverwegingen was jaren eerder besloten ijzeren buis te gebruiken voor de koelwaterleidingen. Inmiddels was er zoveel inwendige roest in de pijpen ontstaan, dat de veel dunnere koelleidingen van de CYBER 74 CPU dichtgeslibd waren: het Laboratorium was daarmee de eerste in de wereld met een computer met "dichtgeslibde aders". Besloten werd na om na schoonmaak van het koelsysteem van de CYBER tijdelijk een externe "bloedcirculatie" aan te leggen. De "noodkoeling" bestond uit het middels een brandslang koppelen van de waterleiding aan de koelwater invoerzijde. Aan de afvoerzijde werd het warme water via een tweede brandslang uit het raam op de binnenplaats geloost. Dat gedurende de drie weken dat het kostte om het pijpenwerk van de koelwatervoorziening volledig te vervangen. Kort daarna viel het Laboratoriumterrein onder het waterwingebied van de Haagse Duinwaterleiding.

Foto van een CDC 6600 met een voor de CYBER 74 vergelijkbare koeling.
Goed zichtbaar is ook de bedrading die de CPU-delen met elkaar verbindt
(klik foto aan voor grotere afbeelding -
foto courtesy van http://ed-thelen.org/comp-hist/).

Nog meer koelperikelen

Het koelsysteem van de airconditioning was ook niet altijd even betrouwbaar. Er was een periode dat de warmtewisselaar op het dak "bevroor". Indien niet tijdig handmatig ingegrepen werd, dus meestal ‘s-nachts als er niemand was, dan liep de temperatuur in de computerruimte snel op tot boven de 27 C. Dan ging er gedurende dertig seconden een alarm en volgde het automatisch uitschakelen van alle spanning. Resultaat was meestal (de bekende "Murphy" was ‘s-nachts meestal wel aanwezig) een onderbroken schrijfactie op de schijven. Het resultaat was een moeizaam herstellen van de schijven, een karwei van zo’n vier tot zes uur. Na de zoveelste "restore" werd een slimme oplossing bedacht, welke ineens tijdens een slapeloze nacht opkwam. Als het systeem toch automatisch "plat ging" was er geen reden om het systeem niet vijf seconden eerder te "deadstarten" ("boot"). Dan kon er alleen maar een niet-destructieve leesactie aan de gang zijn. Een timer van enkele tientjes en anderhalf uur installatiewerk hielp de gevolgen van koelingsproblemen voorgoed uit de wereld.

Om het "restore"-proces na calamiteiten te optimaliseren werd er Fortran programmatuur geschreven die een optimale hoeveelheid magneetbandjobs voor terugladen opleverde. Beide magneetbandeenheden konden daardoor gelijktijdig gebruikt worden voor het terugladen, hetgeen een aanzienlijke tijdbesparing betekende. Tevens werden de om allerlei redenen niet van de meest recente backups terug te laden bestanden automatisch geladen vanaf de meest recente (volledige) wekelijkse backup.

MuseumWaalsdorp@tno.nl