⟦b171ee717⟧

TextFile

mode list.yes
vko2=set 200 disc3
scope user vko2
afs=set 200 disc3
afs=typeset check.no machine.diablo proof.vko2

*se $* $pl ,30,235,,10$
$pn 0,0$$lw 160$ $ld 18$
$pn 5,1$
$rh 1,INTRODUKTION TIL PRÆSTATIONSVURDERING$
$ps0$
$ns1,4,_«bs»2_«bs»._«bs»I_«bs»N_«bs»T_«bs»R_«bs»O_«bs»D_«bs»U_«bs»K_«bs»T_«bs»I_«bs»O_«bs»N__«bs»T_«bs»I_«bs»L__«bs»P_«bs»R_«bs»Æ_«bs»S_«bs»T_«bs»A_«bs»T_«bs»I_«bs»O_«bs»N_«bs»S_«bs»V_«bs»U_«bs»R_«bs»D_«bs»E_«bs»R_«bs»I_«bs»N_«bs»G_«bs».$
$np15$
Nedenstående afsnit giver en kort indføring i, hvad der forstås ved
præstationsvurdering. Det beskrives,
ud fra
hvilke aspekter en datamaskines ydeevne kan vurderes.
Et studie i præstationsvurdering betegnes i det følgende også
med termen evalueringsstudium.
$np$
En datamaskines ydeevne vurderes normalt ved at betragte nogle størrelser,
der betegnes præstationsindeks. Da en del af disse indeks relaterer direkte til
det betragtede system, vil der først i afsnit 4 efter system beskrivelsen (afsnit 3) blive redegjort for, hvilke indeks der anvendes i denne opgave.
$np$
Afsnit 2 afslutttes med kort at definere en flaskehals.
Hele afsnittet bygger på afsnit 1-3 i Ferr78, og derudover
benyttes Denn78, Ross78, Boys75 og Buze71.
$ns1,4,_«bs»2_«bs»._«bs»1_«bs»._«bs»F_«bs»o_«bs»r_«bs»m_«bs»å_«bs»l_«bs»e_«bs»t__«bs»m_«bs»e_«bs»d__«bs»p_«bs»r_«bs»æ_«bs»s_«bs»t_«bs»a_«bs»t_«bs»i_«bs»o_«bs»n_«bs»s_«bs»v_«bs»u_«bs»r_«bs»d_«bs»e_«bs»r_«bs»i_«bs»n_«bs»g_«bs».$
$np$
Når en datamaskine eller et datamatisk system skal vurderes, opstår
normalt 2 spørgsmål afhængig af, hvilket syn
på evalueringen den vurderende person har.
Disse 2 spørgsmål er:
$sj$

1.Fungere det datamatiske system korrekt ?

2.Hvor godt fungere det ?

$rj$
Dette speciale beskæftiger sig kun med spørgsmål 2, og det forudsættes,
at det betragtede system fungerer korrekt.
Aspektet om at se på, hvor godt et system fungere kan betragtes,
som en måling af værdien af systemet. For at kunne vurdere om
et datamatisk system fungerer godt, dvs. foretage en præstationsvurdering
er det nødvendigt at beskrive en del termer, der benyttes i
præstationsvurdering.
$np$
Et datamatisk system (her ofte forkortet system) er en sammensætning
af maskinelle dele (CPU, lager, pladelager o.l.) og programmeldele
(operativsystem, program o.l.). Disse komponenter betegnes fremover
systemets ressourcer eller enheder. Hver komponent har dets egne
attributter, som kaldes systemparametre. Nanc81 definerer
attributter til en model af et system, som størrelser, der beskriver en
komponent og de kan være af 2 typer:
$lm20$
$nl$
_«bs»a_«bs»._«bs»I_«bs»n_«bs»d_«bs»i_«bs»k_«bs»a_«bs»t_«bs»i_«bs»v_«bs»e_«bs».
$nl$
Beskriver aspekter om komponenten, dvs. giver oplysninger om komponenten.
$nl$
_«bs»b_«bs»._«bs»R_«bs»e_«bs»l_«bs»a_«bs»t_«bs»i_«bs»o_«bs»n_«bs»e_«bs»l_«bs»l_«bs»e_«bs».
$nl$
Beskriver hvordan komponenterne er forbundet med hinanden, dvs.
giver oplysninger om komponenternes forbindelse.
$lm0$
$np$
Udover at have en grundig definition af det datamatiske systems systemprarametre,
er det ved en præstationsvurdering nødvendigt at betragte, hvad der normalt
betegnes belastningsparametre (eng. Work-load).
$np$
Ved belastningsparametre forstås de parametre, der beskriver, hvilken
belastning det datamatiske system udsættes for. Belastningen
af et system afhænger af, hvor mange job, der befinder sig i systemet.
Derudover afhænger den af de i systemet eksisterende jobs
karakteristika er. Til et jobs karakterisktika hører bl.a. hvor lang
tid det skal bruge i systemet, og hvilke ydre enheder det ønsker
at kommunikere med. Betegnelsen job kan i den her anførte
betydning både stamme fra en terminal direkte koblet til systemet
(jobbet kommunikere online) eller et job der afvikles som satsvis afvikling.

$np$
Et systems
ydeevne afhænger af belastningen af det.
Derudover
afhænger ydeevnen ligeledes af de i systemet indgående enheders
karakteristika. Dvs. ydeevnen vil afhænge af både belastnings-
og systemparametre.
Belastningsparametre og systemparametre betegnes i det følgende
samlet for installationsparametre.
$np$
Ved en præstationsvurdering kan man skelne mellem tekniske aspekter
og økonomiske aspekter.
Ved de tekniske aspekter er præstationsvurderingen mest rettet mod,
hvordan det foreliggende system fungere. Man vil her være interesseret
i om f.eks. udnyttelsen af centralenheden er stor nok i forhold til
den belastning systemet er udsat for.
$np$
Ved et økonomisk aspekt samler interessen sig i første række om
det datamatiske system er godt nok i forhold til, hvad man
eksempelvis havde inden man havde et datamatisk system. Dvs.
man er interesseret i den rationaliseringsgevinst man har
opnået ved systemet, og om denne er så stor som forventet.
$np$
Spørgsmålet om
hvor godt et system er således et subjektivt spørgsmål.
Forskellige personer vil benytte forskellige
størrelser (betegnes også indeks) for at vurdere systemet.
Disse indeks kaldes i det følgende præstationsindeks. Et præstationsindeks
kan så defineres som en størrelse, der benyttes til at beskrive systemets opførsel
eller andre aspekter om systemet.
$np$
En del præstationsindeks er umulige at kvantificere eksempelvis
hvor let benyttes systemet, strukturen af et program og
rationaliseringsgevinsten ved et system.
Disse størrelser betegnes fremover
funktionelle aspekter, hvorimod de størrelser der er interessante
fremover er størrelser, som kan identificeres ved f.eks. hvor hurtigt svarer
systemet på en given opgave eller hvor lang tid går inden en ydre hændelse
besvares.
$np$
De fremover interessante størrelser kan opdeles i 3 kategorier: (Ferr78 s13)
$lm20$
$nl$
_«bs»1_«bs»._«bs»P_«bs»r_«bs»o_«bs»d_«bs»u_«bs»k_«bs»t_«bs»i_«bs»v_«bs»e__«bs»i_«bs»n_«bs»d_«bs»e_«bs»k_«bs»s_«bs».
$nl$
Eks. Gennemstrømning, Kapacitet ( maksimal gennemstrømning)
Gennemstrømningen defineres som antallet af job, der kan komme
gennem systemet i f.eks. en time.
Kapaciteten defineres som det maksimale antal job der kan passere i
timen. Man kan imidlertid også tale om kapacitet for de indgående
ressourcer og f.eks. et pladelagers kapacitet vil være antallet
af pladelageraksesser pladelageret kan klare i løbet af en tidsperiode.
$nl$
_«bs»2_«bs»._«bs»R_«bs»e_«bs»a_«bs»k_«bs»t_«bs»i_«bs»o_«bs»n_«bs»s__«bs»i_«bs»n_«bs»d_«bs»e_«bs»k_«bs»s_«bs».
$nl$
Eks. Svartid, gennemsnitlig svartid o.l.
Svartiden for et job defineres som afgangstiden minus ankomsttiden.
Dvs. den tid jobbet benytter i systemet.
$nl$
_«bs»3_«bs»._«bs»U_«bs»d_«bs»n_«bs»y_«bs»t_«bs»t_«bs»e_«bs»l_«bs»s_«bs»e_«bs»s__«bs»i_«bs»n_«bs»d_«bs»e_«bs»k_«bs»s_«bs».
$nl$
Eks. Maskinel udnyttelse ( CPU-udnyttelse ), Udnyttelsen af operativsystemet.
Udnyttelsen af en enhed defineres som tiden den er aktiv divideret med observationsperioden.
$lm0$
$np$
Disse 3 type af præstationsindeks interessere forskellige personer, og normalt
vil forskellige interessegrupper være interesseret i forskellige indeks.
F.eks. vil en bruger af et datamatisk system være interesseret i
at have en lav svartid.
En driftleder derimod er formentlig mest interesseret i at udnyttelsen
af systemet er så stor som muligt.
Hilket synspunkt som har interesse her vil nøjere blive beskrevet
i afsnit 4.2.
$np$
Udover at inddele præstationsindeks i de 3 ovenstående kategorier skelnes
mellem primære og sekundære præstationsindeks. Et primært præstationsindeks
er et indeks, som den vurderende person er interesseret i. Normalt
vil formålet med præstationsvurdering være at forbedre de primære indeks.
Et eksempel på et primært præstationsindeks er
svartiden. Den vurderende person kan være interesseret i, at
formindske svartiden under betingelse af,
at systemet herved udnyttes bedre.
$np$
Sekundære indeks bliver normalt bibragt af evalueringsstudiet. Deres
værdier er betydningsfulde til at opdage symptomer på at systemet er
ineffektivt. Eksempler på sekundære indeks er af kategori 3 om
udnyttelsesgrader.
$np$
Ved en præstationsvurdering skal værdierne af de primære og sekundære indeks
findes, ud fra et givent sæt af installationsparametre. Denne operation
kaldes præstationsanalyse eller præstationsvurdering.
$np$
Formålet med præstationsvurdering kan klassificeres i 3 grupper:
$lm20$
$nl$
1.Udvælgelsesstudier.
$nl$
2.Forbedringsstudier.
$nl$
3.Designstudier.
$nl$
$lm0$
$np$
Kategori 1 drejer sig om problemer i forbindelse med valg
af f.eks. afviklingsmåde ( online-batch ), eller
udvælgelse af et datamatisk system ved indkøb. Samlet
er udvælgelsesstudier spørgsmålet om hvilke af de tilstedeværende alternativer,
der er bedst egnet til en given installation.
$np$
Forbedringsstudier beskæftiger sig med modificationer, som
skal/kan foretages ved en eksisterende installation for enten
at forøge dets ydeevne eller forbedre dets driftsomkostninger.
F.eks. trimning af et system falder indenfor denne kategori.
Ved trimning af et system forstås, at nogle installationsparametre
ændres således at systemets udnyttelse bliver bedre.
$np$
Designstudier er dem, som anvendes til besvarelse af spørgsmål, der
opstår
i forbindelse med design af maskiner, operativsystemer o.l.
$np$
Disse 3 grupper af præstationsvurdering skal ikke ses som 3 adskilte
grupper. Normalt kan et evalueringsstudium godt være en sammenblanding
af en eller 2 kategorier fra disse grupper.
$np$
Man kan eksempelvis tænke sig et forbedringsstudium kombineret med et
designstudium. Her kunne man under forbedringsstudiet opdage forskellige
uhensigtmæssigheder, således at f.eks. dele af et operativsystem
skal designes om.
$np$
Dette speciale
drejer sig kun om forbedringsstudier.
Det vil dog ved hjælp af en simulator blive forsøgt at illustrere
hvilke konsekvenser en ændring af systemets design kan have.
$np$
Opsummerende kan siges, at et evalueringsstudiums formål er at
samle information om systemets primære præstationsindeks ud fra et
givent antal installationsparametre. Når et evalueringsstudium skal
foretages er det normalt man gennemløber følgende 5 faser.
$lm20$
$nl$
1.Problemidentificering.
$nl$
2.Formålet med vurderingen.
$nl$
3.Forberedelse af en plan.
$nl$
4.Implementering af planen.
$nl$
5.Præstation af resultaterne.
$nl$
$lm0$
$np$
I de forskellige faser skal man i fase 2 og 3 være specielt
interesseret i, hvad der ønskes opnået ved evaluerinsstudiet.
Hver beslutning om formålet med evalueringsstudiet
og om,
hvilke ressourcer der skal benyttes i forbindelse med et sådant
studium
skal tages i forhold til, hvad man ønsker
at opnå med det.
Spørgsmålet om forbedringer af systemet kan relativt let
besvares ved afslutning af et vurderingsstudium, men er ret vanskelige
at besvare ved begyndelsen. Faserne 3,4 og 5 kan ses som
en iterativ procedure. En hypotese formuleres og testes, og
hvis testen falder negativt ud så modificeres hypotesen.
$np$
Afsnit 4 giver en nøjere beskrivelse af, hvad der foretages i disse
5 faser. Derudover vil dette afsnit nøjere beskrive, hvad der
sker i de enkelte faser, og hvordan disse faser gennemløbes ved
dette evalueringsstudium.
$ns1,4,_«bs»2_«bs»._«bs»2_«bs»._«bs»M_«bs»å_«bs»l_«bs»e_«bs»m_«bs»e_«bs»t_«bs»o_«bs»d_«bs»e_«bs»r_«bs».$
$np$
I planeringsfasen dvs. fase 3 af et evalueringsstudium er det essentielt
at bestemme, hvad der skal måles på systemet. Det kan ses som bestående
af 3 trin:
$lm20$
$nl$
_«bs»T_«bs»r_«bs»i_«bs»n__«bs»1_«bs».
$nl$
Beslutning om, hvad der skal måles.
$nl$
_«bs»T_«bs»r_«bs»i_«bs»n__«bs»2_«bs».
$nl$
Udvælgelse og konstruktion af måleredskab.
$nl$
_«bs»T_«bs»r_«bs»i_«bs»n__«bs»3_«bs».
$nl$
Designe eksperimentet og estimere dets værdi.
At estimere eksperimentets værdi vil sige at beskrive, hvilke fejlkilder
der findes, og beskrive under hvilke forudsætninger de er foretaget.
Disse forudsætninger kan have indflydelse på forsøgets værdi, idet
nogle forudsætninger kan bevirke at eksperimentet ikke helt afspejler
det virkelige system,
men kun dele af det.
Derved begrænses
nøjagtigheden.
$nl$
$lm0$
$np$
Det vil i det nedenstående blive beskrevet, hvilke måleredskaber man i teorien
har, og hvordan man kan betragte deres nøjagtighed.
$np$
Når et måleredskab betragtes bør man først betragte dets karakteristika.
De vigtigste af disse karakteristika er følgende:
$lm0$
$nl2$
_«bs»I_«bs»n_«bs»d_«bs»b_«bs»l_«bs»a_«bs»n_«bs»d_«bs»i_«bs»n_«bs»g_«bs»s_«bs»f_«bs»a_«bs»k_«bs»t_«bs»o_«bs»r_«bs».
$nl$
Hermed menes har redskabet indflydelse på systemets præstation.
Eksempelvis hvis man betragter svartiden for et job, så kan dennes
værdi ændres, hvis man har indsat noget kode for at finde andre
eller netop dette
præstationsindeks.
$nl$
_«bs»N_«bs»ø_«bs»j_«bs»a_«bs»g_«bs»t_«bs»i_«bs»g_«bs»h_«bs»e_«bs»d_«bs».
$nl$
Hvor stor fejl er der på målingen af et givet præstationsindeks.
Bestemmelse af hvilke fejlkilder der er på et givet
præstationsindeks.
$nl$
_«bs»O_«bs»p_«bs»l_«bs»ø_«bs»s_«bs»e_«bs»l_«bs»i_«bs»g_«bs»h_«bs»e_«bs»d_«bs».
$nl$
Hvis f.eks. en hændelse skal tælles, er det så muligt at optælle
samtlige forekommende hændelser eller vil man miste
nogle fordi tælleren ikke kan følge med.
$nl$
_«bs»A_«bs»n_«bs»v_«bs»e_«bs»n_«bs»d_«bs»b_«bs»a_«bs»r_«bs»h_«bs»e_«bs»d_«bs».
$nl$
Relaterer til klassen af hændelser redskabet kan registrerer.
Mange måleredskaber kan kun anvendes til at måle en speciel
form for hændelser. Det ideelle ville være at konstruere et måleredskab
som kan benyttes på mange forskellige former for hændelser.
$nl$
$lm0$
$nl$
Ved målelinger på et system skelner man mellem 3 forskellige
typer af måleredskab.
$lm20$
$nl$
_«bs»"_«bs»h_«bs»a_«bs»r_«bs»d_«bs»-_«bs»w_«bs»a_«bs»r_«bs»e__«bs»t_«bs»o_«bs»o_«bs»l_«bs»s_«bs»"
Dette er maskinelle dele koblet til systemet f.eks. ved prober på
forskellige punkter, som ved hjælp af et måleinstrument
eksempelvis et ur, måler tidspunktet for hændelsen.
En probe er en klemme beregnet til at sætte på et elektrisk
kredsløb, som derved kan registrere om der løber strøm i en
ledning eller ej.
$nl$
_«bs»"_«bs»s_«bs»o_«bs»f_«bs»t_«bs»-_«bs»w_«bs»a_«bs»r_«bs»e__«bs»t_«bs»o_«bs»o_«bs»l_«bs»s_«bs»"
$nl$
Er målerutiner indsat i systemets programmel, som måler eksempelvis
om systemet kommer i en specifik status.
Kan også være et program der simpelthen måler, f.eks. hvor mange
pladelagertilgange et job benytter.
$nl2$
_«bs»"_«bs»h_«bs»y_«bs»b_«bs»r_«bs»i_«bs»d__«bs»t_«bs»o_«bs»o_«bs»l_«bs»s_«bs»"
$nl$
En kombination af de to typer.
$lm0$
$ns1,4,_«bs»2_«bs»._«bs»3_«bs»._«bs»D_«bs»e_«bs»f_«bs»i_«bs»n_«bs»i_«bs»t_«bs»i_«bs»o_«bs»n__«bs»a_«bs»f__«bs»e_«bs»n__«bs»f_«bs»l_«bs»a_«bs»s_«bs»k_«bs»e_«bs»h_«bs»a_«bs»l_«bs»s_«bs».$
$np$
Begrebet en flaskehals defineres normalt, som den enhed i et datamatisk
system, der alvorligt formindsker hele systemets ydeevne. En enhed kan formindske et
systems ydeevne, hvis den eksempelvis benyttes meget og er særdeles langsom.
Da de i systemet indgående enheder er meget forskelligartet, er det vanskeligt at anvende denne definition. En anden vanskelighed
i at anvende definitionen er, at det er svært at definere, hvad der forstås ved systemets
ydeevne. Et systems ydeevne kan defineres som antal af job der kan udføres pr. tidsenhed, men kan også defineres som udnyttelsesgraden af systemet.
$np$
Når en flaskehals skal findes er det derfor nødvendigt at specificere præcist,
hvilken definition af en flaskehals man vil benytte.
$np$
En anden definition på en flaskehals findes i Denn78. Her defineres en flaskehals til
at være den enhed, som har den største værdi af Vi*Si, hvor Vi er antal af job
der behandles og Si er den gennemsnitlige behandlingshastighed ved enhed i. Denne definition
er imidlertid heller ikke altid generel nok, da man kunne tænke sig at eksempelvis lagerstørrelsen ville have indflydelse på systemets ydeevne.
$np$
For at lægge sig fast på den definition af en flaskehals jeg mener er bedst
(buze71) er det nødvendigt at indføre en del begreber:
$nl2$
Systemet på nedenstående figur betragtes.
$nl20$
Figur 2.3.
Systemet består af en centralenhed og nogle ydre enheder, som eksempelvis
kan være plade- og tromlelagre.
$np$
Til figuren kan nu knyttes følgende kommentarer om de anførte betegnelser:
$nl$$lm20$
$nl$
N = antal job i systemet
$nl$
L = antal ydre enheder
$nl$
Pi = sandsynligheden for at et job fortsætter ved den i'te enhed
efter at have forladt centralenheden. Dvs i kan antage værdierne fra 0...L.
$nl$
Ui = Gennemsnitlig behandlingshastighed ved enhed i.
Dvs. 1/Ui er den gennemsnitlige tid enhed i skal bruge for at afslutte
en transaktion.
$lm0$
$nl$
Buze71 foreslår nu følgende
definition:
$nl$
Hvis en lille forøgelse i en enheds ydeevne bevirker en stor forøgelse af systemets
ydeevne så siges denne enhed at være en flaskehals.
$np$
Med de indførte betegnelser kan denne definition nu uddybes på følgende :
$np$
Det forudsættes at en enheds ydeevne svarer til denne enheds behandlingshastighed
og systemets ydeevne svarer til centralenhedens udnyttelse. Centralenhedens
kapacitet kan udtrykkes ved AoUoPo, hvor Ao er sandsynligheden for at
systemet er i tilstnaden CPU-aktiv. Dermed bliver udstrækningen af om
en enhed skaber en flaskehals
vil være propotional med
dAoUoPo/dui.
Dette skyldes, at Ao kan udtrykkes ved hjælp af U0,U1,...,Un,Po,...,Pl
og N.
Hvis det gælder at
$nl4$
så svarer dette til at systemet ikke har nogen flaksehals og er, hvad
der kaldes et balanceret system. Hvis derimod en af størrelserne
$nl4$
er større end en af de andre så vil den tilsvarende enhed i skabe en flaksehals
.
En lille forøgelse i denne enhed i's afviklingshastighed vil bevirke en stor forøægelse af systemets ydeevne. Det vil sige, at når en flaskehals skal
findes i et system skal man finde den største værdi af
$nl4$
$np$
De betragtninger, som er foretaget i dette afsnit, vil blive uddybet i a
afsnit ??.?. Heri vil det ligeledes blive beskrevet, hvordan AoUoPo kan
opfattes. Derudover vil afsnittet nøjagtigere beskrive,
hvilke forudsætninger det er nødvendigt at foretage ved denne definition af
en flaskehals.
$rh 1,SYSTEMBESKRIVELSE$
$ps 0$
_«bs»3_«bs»._«bs»S_«bs»Y_«bs»S_«bs»T_«bs»E_«bs»M_«bs»B_«bs»E_«bs»S_«bs»K_«bs»R_«bs»I_«bs»V_«bs»E_«bs»L_«bs»S_«bs»E_«bs».
$nl$
$np 15$
Nedenstående afsnit indeholder en beskrivelse af et oplysningssystem
(fremover forkortet OP-system) hos KTAS. OP-systemet er grundlaget
for besvarelser af spørgsmål,
som stilles til telefonnummeroplysningen.
$nl$
Spørgsmålene kan opdeles i 2 kategorier:
$nl$$lm15$
1.Hvilket tlfnr. har en given abonnent ?
(Betegnes fremover søgeforespørgsel)
$nl$
2.Hvilken abonnent har et givet tlfnr. ?
(Betegnes tlfnr.forespørgsel)
$nl$$lm 0$
$np15$
Disse spørgsmål (forespørgsler) kan bevirke, at der skal stilles
supplerende spørgsmål for at fremskaffe den ønskede information.
De vigtigste typer af supplerende spørgsmål er en bladning og afdækning
af hemmeligt tlfnr.
Hvis en forespørgsel resulterer i mere end 21 forslag, og dermed
fylder mere end et skærmbillede, er det muligt at bladre i skærmbillederne, og
dette betegnes en bladning.
Hvis der spørges på en abonnent med hemmeligt tlfnr. vil
dette på skærmen blive
skrevet som "HEMM.NR". Denne tekst kan afdækkes
( dvs. tlfnr. kommer frem på skærmen ) ved en speciel ordre.
$np 15$
Systemet er implementeret på maskinel fra Regnecentralen. Hovedbestandendelen er en
RC8000. Derudover benyttes en del (mindst 3) RC3500
til kommunikationsled mellem terminaler og RC8000.
$np 15$
Hele OP-systemet har følgende udseende:
$ps0$
$sj$
Figur 3.1.
$rj$
$ps0$
$np 15$
Konfigurationen vist på figur 3.1., benyttes til at
forklare, hvordan den overordnede funktionsmåde af systemet er.
OP-systemet pr. 1.5.1981 er mere kompliceret, men hovedprincipperne
i systemets virkemåde er bevaret.
$np 15$
I de følgende afsnit vil del1 og del2 blive betegnet RC8000-delen og del3 og del 4 for
RC3500 delen.
$np$
Del 4 er på figuren simplificeret en hel del. Ved denne del findes der
en RC3500 for hver ca. 20 terminaler. Da der normalt er koblet ca. 160 terminaler
til hele OP-systemet består del 4 af mindst 8 RC3500. Imidlertid er princippet om, hvordan
terminalerne er koblet til OP-systemet den samme som den på figuren angivne
del 4.
$np 15$
Når der ringes ind til tlfnr.oplysningen bliver en forespørgsel indtastet
på en skærm. Denne skærm er koblet til en RC3500. Denne RC3500 omsætter forespørgslen
til en repræsentation, som kan forstås af resten af systemet. RC3500 sender derefter
forespørgslen videre ved hjælp af en kommunikationslinie på figuren markeret 1 eller 2.
$np 15$
Forespørgslen sendes ad linie 1, hvis dette er muligt ellers
sendes den ad linie 2. Kommunikationslinien mellem denne RC3500 og de
RC3500'er der på figuren er betegnet NP er en 48 K bps (bit pr. sekund)
datatransmissionslinie. Forespørgslen modtages af en af de 2 RC3500
betegnet NP (Network-Processor) afhængig af, hvilken linie den er sendt
af. NP modtager og videresender forespørgslen
ud fra en speciel strategi til en af de to RC3500 betegnet FP. (Front-end
Processor). Strategien for, hvordan forespørgslerne fordeles mellem
de to RC3500 betegnet FP afhænger dels af om begge RC8000'er er i
funktion og dels af deres belastning.
$np 15$
Transmissionslinien mellem NP og FP er en hurtig datatransmissionslinie. Skillelinien
mellem NP og FP udgør endvidere et skel mellem hvilke former for
transmissionssystem, der benyttes. Systemet der anvendes her til dette
skel er CATS35( Communication And Terminal System implementet on
RC3500. Findes beskrevet i RCSL.52-A188). Fra RC3500 på figuren betegnet FP benyttes
et specielt udviklet system,
der kun anvendes ved OP-systemet.
FP'ens opgave er, at transformere
forespørgslen så den kan modtages af RC8000. Derefter videresendes
forespørgslen og modtages i RC8000 af en terminaldriver.
$np 15$
Hvordan hele OP-systemet er implementeret i de 3 typer RC3500 findes
beskrevet i appendix 1, og begrundelsen for at en
beskrivelse ikke er medtaget i dette speciale findes i afsnit 8.1.
Derimod findes i nedenstående en beskrivelse af, hvordan OP-systemet
er implementeret i RC8000.
$np 15$
OP-systemet
er i RC8000 implementeret i form af 5 interne processer, der kører parallelt.
$np 15$
En intern proces (betegnes fremover kort proces) defineres ifølge
Brin73 s239-240, som udførelsen af et eller flere afbrydelige
programmer, der befinder sig et givent sted i lageret. En proces
er entydigt identificeret ved et navn. Scheduleringsstrategien for
tildelingen af tid til de enkelt processer beskrives udførligt
i afsnit 3.4.
$ns1,4,_«bs»3_«bs»._«bs»2_«bs»._«bs»R_«bs»C_«bs»8_«bs»0_«bs»0_«bs»0_«bs»'_«bs»d_«bs»e_«bs»l_«bs»e_«bs»n__«bs»a_«bs»f__«bs»O_«bs»P_«bs»-_«bs»s_«bs»y_«bs»s_«bs»t_«bs»e_«bs»m_«bs»e_«bs»t_«bs».$
$np 15$
Nedenstående figur viser, hvordan OP-systemet ser ud i RC8000.
Derefter følger en beskrivelse af de enkelte processer,
efterfulgt af en redegørelse for, hvordan de 5 processer kommunikerer
indbyrdes.
$ps0$

$ps0$
$np 15$
Figuren viser udover de 5 interne processer, nogle
drivere til ydre enheder såsom pladelagre og terminaler.
De sorte pile på figuren angiver, at der sker overførsel af data.
Da de 5 interne processer ligger fast i det indre lager, kopieres f.eks. svar
på en forespørgsel fra opslags- til outputprocessen. Dette kaldes overførsel af data.
En hvid pil svarer til, at der sker overførsel af meddelser.
En meddelse er eksempelvis at bede pladelageret om at læse et segment
på pladelageret.
$nl$
Til
dette kan følgende kort bemærkes:
$np 15$
Kommunikation af meddelser mellem processer foregår ved hjælp af
"message buffer".
En "message buffer"
benyttes til at sende data mellem to processer ved,
at der i bufferen er angivet eksempelvis, hvor afsendte data
findes. "Message buffer" sendes så ved monitorproceduren
"send message", hvor det er muligt at angive den
modtagende proces. Der findes i Brin73 s237-286 en særdeles
god beskrivelse af, hvad processer er, og hvordan kommunikationen
mellem dem foregår på RC4000. På RC8000 foregår det på næsten
ækvivalent vis, og forskellene har ingen betydning i forbindelse
med OP-systemet.
Driverne på figuren er implementeret, som eksterne processer, hvilket

vil sige, at de foretager input/output til enhederne de er bundet til.
$ns1,4,_«bs»3_«bs»._«bs»2_«bs»._«bs»1_«bs»._«bs»O_«bs»P_«bs»-_«bs»p_«bs»a_«bs»r_«bs»e_«bs»n_«bs»t__«bs»p_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs».$
$np 15$
Processens formål er at oprette og
nedlægge de øvrige RC8000 processer i forespørgselssystemet,
samt at styre disse.
$np 15$
OP-parent processen anvendes, når en operatør ønsker at starte de andre
i systemet indgående processer. Opstart af systemet foregår ved at operatøren
sender en meddelse til parent-processen,
og denne proces starter så processerne op.
Denne operation kaldes at opgradere systemet.
$np 15$
Udover at starte de øvrige processer benyttes parent-processen til at
degradere OP-systemet.
Ved en degradering af OP-systemet vil kun bladningsforespørgsler blive sendt
til inputprocessen.
Dette benyttes, når systemet skal lukkes ned. Her
er det nødvendigt at degrade systemet, for derefter at vente
et vist stykke tid, så alle forespørgsler i systemet
er færdigbehandlet.
Først når alle forespørgsler er færdigbehandlet kan systemet stoppes.
$ns1,4,_«bs»3_«bs»._«bs»2_«bs»._«bs»2_«bs»._«bs»I_«bs»n_«bs»p_«bs»u_«bs»t_«bs»-_«bs»p_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs»s_«bs»e_«bs»n_«bs».$
$np 15$
Inputprocessen modtager inputlinier fra terminaldriveren i RC8000
kaldet "terminput". Hver inputlinie, som modtages, er forsynet med en vis
kontrolinformation fra RC3500.
Dene kontrolinformation kan eksempelvis angive, at forespørgslen er en bladning.
Inputlinien (indeholdende en forespørgsel) analyseres. Dette
resulterer i, at forespørgslen videresendes til enten søgeprocessen,
opslagsprocessen eller outputprocessen.
$nl$
$nl$
_«bs»P_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs»s_«bs»e_«bs»n_«bs»s__«bs»f_«bs»o_«bs»r_«bs»l_«bs»ø_«bs»b__«bs»k_«bs»a_«bs»n__«bs»d_«bs»e_«bs»t_«bs»a_«bs»i_«bs»l_«bs»j_«bs»e_«bs»r_«bs»e_«bs»t__«bs»b_«bs»e_«bs»s_«bs»k_«bs»r_«bs»i_«bs»v_«bs»e_«bs»s__«bs»p_«bs»å__«bs»f_«bs»ø_«bs»l_«bs»g_«bs»e_«bs»n_«bs»d_«bs»e__«bs»m_«bs»å_«bs»d_«bs»e_«bs»:
$nl$$nl$
Efter en analyse af en del kontrolinformation, gennemlæses linien tegn for
tegn. Derefter ændres inputlinien til en intern repræsentation, der
benyttes af de andre processer.
En forespørgsel
kan enten være en søgeforespørgsel eller
en tlfnr.forespørgsel. En søgeforespørgsel indeholder
et eller flere felter efterfulgt af et feltindhold. De vigtigste felter er følgende:
$ps0$
$sj$
_«bs»F_«bs»E_«bs»L_«bs»T________«bs»I_«bs»N_«bs»D_«bs»H_«bs»O_«bs»L_«bs»D_________«bs»B_«bs»E_«bs»T_«bs»Y_«bs»D_«bs»N_«bs»I_«bs»N_«bs»G

*b Hellerup by

*n Petersen efternavn

*f Peter fornavn

*g Stolpevej gade

*s Arkitekt stilling

*h 14 husnr
$rj$
$np15$
En søgeforespørgsel skal indeholde feltet *b. Dette er eneste
felt, der skal forefindes, derudover kan de andre
felter forekomme, og de kan stå i vilkårlig orden.
Dog skal mindst et andet felt findes i søgeforespørgslen. Hvad der
her er betegnet felter sammenholdt med feltindholdet,
vil i det følgende også betegnes et søgekriterie.
$np 15$
Den anden type tlfnr.forespørgsler
indeholder følgende felt:
$nl$
$sj$
*t1753029 (et tlfnr)

$rj$
$np$
Udover disse to forespørgselstyper kan det forekomme, at inputlinien
henføres til en kategori, der betegnes ukendt linietype eller fejllinie.
$np 15$
Til disse forespørgselstyper bemærkes, at inputprocessen foretager følgende
afhængig af linietypen:
$nl$$nl$
_«bs»1_«bs»._«bs»S_«bs»ø_«bs»g_«bs»e_«bs»f_«bs»o_«bs»r_«bs»e_«bs»s_«bs»p_«bs»ø_«bs»r_«bs»g_«bs»s_«bs»e_«bs»l_«bs»s_«bs»l_«bs»i_«bs»n_«bs»i_«bs»e_«bs».
$nl$$nl$
I en sådan _«bs»s_«bs»k_«bs»a_«bs»l altid forekomme feltet *b(by).
Søgelinien kontrolleres , herunder registreres eventuelle
fejl f.eks. fornavn uden efternavn, husnr. uden gade.
Hvis linien er korrekt, sættes et låsefelt i linien. Findes et låsefelt
allerede i inputlinien ( dette indikere f.eks. en bladning),
så sendes forespørgslen direkte til outputprocessen, ellers sendes den til
søgeprocessen.
Et låsefelt fremkommer i en inputlinie inden inputprocessen behandler forespørgslen
ved, at der trykkes
på en speciel knap på terminalen.
$nl$$nl$
_«bs»2_«bs»._«bs»T_«bs»e_«bs»l_«bs»e_«bs»f_«bs»o_«bs»n_«bs»n_«bs»u_«bs»m_«bs»m_«bs»e_«bs»r_«bs»f_«bs»o_«bs»r_«bs»e_«bs»s_«bs»p_«bs»r_«bs»ø_«bs»g_«bs»s_«bs»e_«bs»l_«bs»s_«bs»l_«bs»i_«bs»n_«bs»i_«bs»e_«bs».
$nl$$nl$
I en sådan linie skal *t (tlfnr.)
forekomme.
Linien kontroleres, herunder kan fejl registreres,
f.eks. antal cifre i et tlfnr.. Hvis linien er korrekt
sendes inputlinien til opslagsprocessen.
$nl$$nl$
_«bs»3_«bs»._«bs»U_«bs»k_«bs»e_«bs»n_«bs»d_«bs»t__«bs»l_«bs»i_«bs»n_«bs»i_«bs»e_«bs»t_«bs»y_«bs»p_«bs»e__«bs»e_«bs»l_«bs»l_«bs»e_«bs»r__«bs»f_«bs»e_«bs»j_«bs»l_«bs»l_«bs»i_«bs»n_«bs»i_«bs»e_«bs».
$nl$$nl$
Der dannes en fejludskrift svarende til registrerede fejl og denne sendes
til outputprocessen.
$ns 1,4,3.2.2.Søgeprocessen.$
$np 15$
Denne proces modtager forespørgsler fra inputprocessen.
Ud fra en forespørgsel er dens opgave at levere de mulige "kandidater" til opslagsprocessen.
Til søgeprocessen er koblet et pladelager, hvorpå der findes en indekssekventiel
fil. En forespørgsel skal som omtalt under inputprocessen altid indeholde et stednavn,
hvilket er første indeks. Ud fra dette
findes et vist antal "kandidater". Hvis der er andre søgekriterier svarer dette til at søgeprocessen
ved hjælp af disse ( de kan opfattes som underindeks) indskrænker
antallet af mulige "kandidater". En "kandidat" til en forespørgsel er fra
søgeprocessens synspunkt en pointer til en fil, der kaldes "abonnent-filen".
Opslagsprocessen finder ud fra disse pointere abonnentinformationen.
$np15$
Ved denne beskrivelse er det vigtigt at bemærke, at da de indekssekventielle filer
findes på pladelageret, vil antallet af pladelagertilgange afhænge
af antallet af søgekriterier i en forespørgsel.
$np15$
Hvis søgeprocessen ikke finder kandidater, sendes en fejludskrift til outputprocessen.
Dette er også tilfældet, hvis der findes mere end 63 kandidater, hvilket
svarer til 3 skærmbilleder.
$np$
Da det ved vurderingen af OP-systemet viser sig, at
søgeprocessen er en meget vigtig proces, har det i afsnit 8.3 været
nødvendigt at beskrive denne nærmere.
$ns1,4,_«bs»3_«bs»._«bs»2_«bs»._«bs»4_«bs»._«bs»O_«bs»p_«bs»s_«bs»l_«bs»a_«bs»g_«bs»s_«bs»-_«bs»p_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs»s_«bs»e_«bs»n_«bs».$
$np 15$
Denne proces foretager opslaget i abonnentfilen.
Abonnentfilen indeholder data om samtlige abonnenter. Dvs.
filen indeholder eksempelvis navn, adresse tlfnr. o.l.
$np 15$
Programmet, der foretager opslaget er delt i to hovedafsnit, hvor
det ene foretager opslag til besvarelse af tlfnr. forespørgsler,
og det andet foretager opslag til besvarelse af søgningsforespørgsler.
Sagt på en anden måde behandler det første hovedafsnit meddelser fra
inputprocessen, og det andet behandler kandidaterne, som eventuelt
modtages fra søgeprocessen.
$nl$$nl$
_«bs»S_«bs»v_«bs»a_«bs»r_«bs»n_«bs»d_«bs»e__«bs»t_«bs»i_«bs»l__«bs»d_«bs»e__«bs»t_«bs»o__«bs»d_«bs»e_«bs»l_«bs»e__«bs»u_«bs»d_«bs»f_«bs»ø_«bs»r_«bs»e_«bs»r__«bs»p_«bs»r_«bs»o_«bs»g_«bs»r_«bs»a_«bs»m_«bs»m_«bs»e_«bs»t__«bs»f_«bs»ø_«bs»l_«bs»g_«bs»e_«bs»n_«bs»d_«bs»e_«bs»:
$nl$$nl$
_«bs»1_«bs»._«bs»T_«bs»l_«bs»f_«bs»n_«bs»r_«bs».__«bs»f_«bs»o_«bs»r_«bs»e_«bs»s_«bs»p_«bs»ø_«bs»r_«bs»g_«bs»s_«bs»l_«bs»e_«bs»r_«bs».
$nl$$nl$
En tlfnr.forespørgsel bevirker, at opslagsprocessen ud fra et tlfnr. finder
abonnenten i abonnentfilen. Det er en simpel operation, som normalt
kun benytter en pladelagertilgang.
$np 15$
Svaret på en tlfnr. forespørgsel fylder aldrig mere end et skærmbillede, og
det sendes til outputprocessen påsat betegnelsen "ABONNENT INFORMATION
SVARBILLEDE", hvis den forespurgte forespørgsel findes og
typen "SIMPELT OUTPUT", hvis forespørgslen afvises.
$nl$$nl$
_«bs»2_«bs»._«bs»S_«bs»ø_«bs»g_«bs»n_«bs»i_«bs»n_«bs»g_«bs»s_«bs»f_«bs»o_«bs»r_«bs»e_«bs»s_«bs»p_«bs»ø_«bs»r_«bs»g_«bs»s_«bs»e_«bs»l_«bs».
$nl$$nl$
Denne programdel aktiveres, når der modtages en meddelse fra søgeprocessen af
typen "KANDIDAT STAK".
$np 15$
Der opbygges en række tabeller til styring af opslagene i abonnentfilen og
opbygning af svarlinier. Derefter dannes
en svarlinie for hver kandidat modtaget fra søgeprocessen.
Når alle svarlinier er dannet, sorteres de
og indsættes enkeltvis i en outputbuffer.
I denne outputbuffer dannes der færdige skærmbilleder med den oprindelige
inputlinie, som første linie. Hvis antallet af svarlinier fylder
mere end et skærmbillede anføres dette i outputbufferen.
Derefter sendes denne til outputprocessen.
$ns1,4,_«bs»3_«bs»._«bs»2_«bs»._«bs»5_«bs»._«bs»O_«bs»u_«bs»t_«bs»p_«bs»u_«bs»t_«bs»-_«bs»p_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs»s_«bs»e_«bs»n_«bs».$
$np 15$
Output processen modtager meddelser fra de andre processer.
Den modtager fejludskrifter fra input- og søgeprocessen. Fra opslagsprocessen
ankommer kandidatstakke og fra inputprocessen kommer bladningsforespørgsler
og forespørgsler om afdækning af hemmeligt tlfnr.
Dens eneste formål er at videresende meddelserne til OP-skærmene.
$np 15$
Alle af outputprocessen modtagne meddelser udskrives i en fil kaldet
LOGFILEN (beskrevet i afsnit 3.4). Efter at forespørgslen er udskrevet i logfilen bestemmes ud fra
typen, hvilken aktion der herefter skal tages.
$ns1,4,_«bs»3_«bs»._«bs»3_«bs»._«bs»K_«bs»o_«bs»m_«bs»m_«bs»u_«bs»n_«bs»i_«bs»k_«bs»a_«bs»t_«bs»i_«bs»o_«bs»n__«bs»m_«bs»e_«bs»l_«bs»l_«bs»e_«bs»m__«bs»d_«bs»e__«bs»5__«bs»p_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs»s_«bs»e_«bs»r_«bs».$
$np 15$
Da det for forståelsen af OP-systemet er særdeles vigtigt at vide, hvordan forespørgsler
passerer gennem de 5 processer vil dette
blive opsummeret i nedenstående.
$np 15$
Processen OP-parant benyttes, som før omtalt kun ved opstart og lukning af systemet,
så den vil ikke nøjere blive medtaget her.
$np 15$
Nedenstående figur viser en simplificeret udgave af OP-systemets RC8000-del.
$sj$
Figur 3.3.
$rj$
$ps0$
$np 15$
Alle forespørgsler går gennem inputprocessen og outputprocessen. Det interessante
er, hvordan de derudover passerer gennem systemet. Nedenfor er angivet
de mulige veje.
$nl$$nl$
input -> output :
$nl$
Forespørgsler med fejl i inputlinien, bladningsforespørgsler og
afdækning af hemmeligt tlfnr.
$nl$$nl$
input -> søge -> opslags -> output :
$nl$
En søgeforespørgsel, hvor der er mellem 1 og 63 kandidater.
$nl$$nl$
input -> søge -> output :
$nl$
En søgeforespørgsel, hvor der enten ikke findes kandidater eller
der findes mere end 63.
$nl$$nl$
input -> opslags -> output :
$nl$
En tlfnr.forespørgsel.
$ns1,4,_«bs»3_«bs»._«bs»4_«bs»._«bs»S_«bs»c_«bs»h_«bs»e_«bs»d_«bs»u_«bs»l_«bs»e_«bs»r_«bs»i_«bs»n_«bs»g_«bs»s_«bs»s_«bs»t_«bs»r_«bs»a_«bs»t_«bs»e_«bs»g_«bs»i_«bs»e_«bs»n_«bs».$
$np 15$
Scheduleringsstrategien, som benyttes på en RC8000, er en modificeret
form for ROUND-ROBIN.(se brin73 s255). Den vil blive uddybet i følgende
afsnit.
$nl$
En proces kan være i 3 forskellige tilstande:
$lm20$
$nl$
1.Kørende
$nl$
2.Ventende (på at blive kørende)
$nl$
3.Passiv
$lm0$
$nl$
Processen der benytter CPU-en betegnes kørende. En ventende
proces skal benytte CPU-en, men da der er en anden proces, der
benytter CPU-en, må den vente på dens tur. En passiv
proces venter på en ydre hændelse som eksempelvis kan være at
pladelageret er færdigt med en overførsel.
$np$
Til disse 3 tilstande svarer kun een kø, hvori ventende processer og
den kørende proces findes. Køen er en dobbelthægtet liste og har for
de i OP-systemet indgående processer eksemplevis følgende udseende:
(Den betegnes fremover aktivkøen.)
$ps0$
$sj$
AKTIVKØEN:

---------- ---------- ----------
! ! ! ! ! !
! INPUT ! ! SØGE ! ! OUTPUT !
! PROCES !--->-! PROCES !-->-! PROCES !
! !---<-! !--<-! !
! KØRENDE! !VENTENDE! !VENTENDE!
! ! ! ! ! !
---------- ---------- ----------

PASSIVE PROCESSER:

----------- -----------
! ! ! !
! OPSLAGS ! ! OP-PA- !
! PROCES ! ! RENT !
! ! ! PROCES !
! PASSIV ! ! PASSIV !
! ! ! !
----------- -----------

$rj$
$np$
Processerne indplaceres i aktivkøen på grundlag af en størrelse,
der betegnes tidskvant. Hvis tidskvant er mindre end en tidsskive
( 25.6 ms ), bliver processen placeret forrest i aktivkøen ellers
placeres den bagest.
Det bør her bemærkes, at tidskvant og tidsskive er to forskellige
størrelser, og de må absolut ikke forveksles.
$np$
Størrelsen tidskvant indeholder den del af tidsskiven processen har brugt indtil
den enten er færdig eller den bliver afbrudt.
$np$
En proces tages ud af aktivkøen, hvis den er kørende og f.eks. har bedt
om overførsler af data fra pladelageret. Den tages ligeledes ud, hvis
processen bliver færdig.
$nl$
Scheduleringsstrategien kan
illustreres ved følgende eksempel:
$nl2$
_«bs»E_«bs»k_«bs»s_«bs»e_«bs»m_«bs»p_«bs»e_«bs»l__«bs»3_«bs»._«bs»4_«bs»._«bs»:
$nl$
Antag at der i RC8000 findes 3 processer fremover betegnet A,B og C.
Til tiden 0 bliver proces A,B og C oprettet og startet. Dette bevirker,
at processerne bliver indsat i aktivkøen i rækkefølgen A,B,C. Da
proces A er den første proces, bliver den kørende og
den får tildelt et tidskvant. Imidlertid skal proces A efter 15 ms benytte
et segment fra pladelageret. (En sådan pladelagertilgang tager normalt
ca. 38.3 ms. se afsnit 4) Dette bevirker, at proces A bliver passiv og B ( som er
ventende ) bliver kørende. Størrelsen tidskvant bliver for A
sat til 15 ms. B bliver nu kørende i 25.6-15 ( = 10.6 ) ms, og
B bliver derefter afbrudt af klokken. Tidskvant for B bliver sat til
10.6 ms. Idet dette er mindre end et tidsskive, kommer B atter forrest i
aktivkøen. Den får nu tildelt en hel tidsskive. Da den ikke under denne
tidsskive kan nå at blive færdig, er den kørende under hele tidsskiven.
Når den har kørt en hel tidsskive, bliver B igen afbrudt af klokken.
Tidskvant for B bliver nu sat til 10.6+25.6 = 36.2 ms. Da dette er
større end en tidsskive bliver B indsat bagest i aktivkøen, og tidskvant
bliver derefter sat til 0.
$np$
Proces C bliver nu kørende, og den får tildelt 25.6 ms. Når der er gået 2.1 ms
af denne tidsskive,
vil pladelagertilgangen for proces A være færdig. Proces
C bliver så afbrudt. Imidlertid sker nu følgende:
$nl$
Da A's tidskvant er mindre end 25.6 ms, vil denne (dette sker først) blive
indplaceret forrest i aktivkøen. Derefter vil proces C, idet dens tidskvant
er 2.1 ms og dermed mindre end et tidskvant, ligeledes blive indsat
forrest i aktivkøen. Da dette sker sidst vil den blive indsat foran A.
$np$
C får nu tildelt 25.6-2.1 ms, som er den tid der er tilbage af
en tidsskive.
$np$
Dette vil fortsætte på ækvivalent vis indtil processerne er færdige.
Nedenstående figur viser et tidsdiagram over, hvordan processerne
benytter CPU-en.
$nl5$
$sj$
Figur 3.4.
$rj$
$nl5$
$np$
Ovenstående eksempel forudsætter, at processerne alle har
samme prioritet. Dette er tilfældet ved OP-systemet. Hvis
ikke alle processer har samme prioritet, kan man betragte det som om,
at der findes en aktivkø for hvert prioritetsniveau. En proces vil
så blive indplaceret i køen svarende til den prioritetskø, der har samme
prioritet som processen.
$ns1,4,_«bs»3_«bs»._«bs»4_«bs»._«bs»B_«bs»e_«bs»s_«bs»k_«bs»r_«bs»i_«bs»v_«bs»e_«bs»l_«bs»s_«bs»e__«bs»a_«bs»f__«bs»l_«bs»o_«bs»g_«bs»f_«bs»i_«bs»l_«bs»e_«bs»n_«bs».$
$np 15$
Når en forespørgsel passerer gennem OP-systemet, foregår dette ved,
at en vis mængde data transporteres mellem de i systemet indgående processer.
Af disse data bliver en del information udskrevet på en fil på systemdiscen
kaldet logfilen. Dette foregår som tidligere beskrevet i outputprocessen.
$np 15$
Logfilen benyttes til at lave statistikker om forespørgslerne. Der er bl.a.
mulighed for at finde, hvor hyppigt, der spørges på de stednavne som
er hovedindeks i den indekssekventielle fil på søgediscen koblet til
søgeprocessen. Af den information, der findes på logfilen er specielt følgende
interessant, idet de siger noget om, hvor meget tid der benyttes i de enkelte
processer. Det er i afsnit 5.2 beskrevet, hvordan disse data benyttes
men følgende størrelser forefindes:
$nl$
$sj$
abs. ankomsttid input proces
rel. afgangstid input proces
cpu tid input proces
rel. ankomsttid søge proces
rel. afgangstid søge proces
cpu tid søge proces
rel. ankomsttid opslags proces
rel. afgangstid opslags proces
cpu tid opslags proces
rel. ankomstid output proces
rel. afgangstid output proces
cpu tid output proces
$rj$
$np 15$
Alle rel. tider er relative i forhold til den absolute ankomsttid til
inputprocessen, og alle tider er udtrykt i millisekunder.
$ns 1,4,3.5.Pladelagerkanal.$
$np$
De 3 processer søge-, opslag- og outputprocessen kommunikerer med de tilkoblede
pladelagre gennem en "discdriver" og en pladelagerkanal. Det vil ikke
her blive beskrevet, hvordan "discdriveren" fungerer. Dette skyldes, at
den er indbygget i, hvad der betegnes monitoren på RC8000. Hvordan monitoren
kan opfattes, er defineret i afsnit 4.4. Det er derimod særdeles vigtigt at
forstå, hvordan pladelagerkanalen fungerer og det vil derfor beskrives i nedenstående afsnit.
At det er vigtigt at forstå, hvordan pladelagerkanalen fungerer, skyldes at den skal indbygges i simulatoren. Derudover vil dens betydning skulle undersøgesforbindelse med vurderingen af systemet.
$np$
Pladelagerkanalen (eng. "disccontroler") er en selvstændig enhed. Dvs. at den indeholder en
logisk enhed, og den kan kører parallelt med CPU-en på RC8000. En RC8000
til OP-systemet indeholder en pladelagerkanal, der styrer overførslen af data fra de 3 tilknyttede pladelagre.
For at forstå hvordan pladelagerkanalen overfører data, er det nødvendigt at gøre sig klart
hvordan en pladelagertilgang helt nøjagtigt foregår.
$np$
Når en proces i RC8000 ønsker at benytte nogle data, der er lagret på pladelageret,
sendes en meddelse om dette til "discdriveren". Denne beregner diskaddressen
og beder derefter pladelagerkanalen om at finde denne diskaddresse på en af de 3 diske.
Pladelagerkanalen sørger derefter for at positionere selve diskhovedet
hen til det spor på pladelageret, hvor dataene findes. Når hovedet
befinder sig på sporet, bliver diskkanalen reserveret( dette umuliggør at
andre kan benytte den). Når hovedet befinder sig over det ønskede data,
overføres dataene.
$np$
Det vigtigste at gøre sig klart er, at når hovedet befinder sig på det ønskede
spor er diskkanalen reserveret, og den kan ikke foretage sig andet før overførslen af data er færdig.
Derimod kan diskkanalen under en positionering af et hoved godt starte
en positionering på en anden disk.
$rh 1,PLANLÆGNING AF ET EVALUERINGSSTUDIUM$
$ps0$
$ns1,4,_«bs»4_«bs»._«bs»P_«bs»l_«bs»a_«bs»n_«bs»l_«bs»æ_«bs»g_«bs»n_«bs»i_«bs»n_«bs»g__«bs»a_«bs»f__«bs»e_«bs»t__«bs»e_«bs»v_«bs»a_«bs»l_«bs»u_«bs»e_«bs»r_«bs»i_«bs»n_«bs»g_«bs»s_«bs»s_«bs»t_«bs»u_«bs»d_«bs»i_«bs»u_«bs»m_«bs».$
$np$
Det er i afsnit 2.1 beskrevet, hvilke faser et evalueringsstudium normalt gennemløber
inden det er færdigt.
Dette afsnit beskriver i
afsnit 4.1 til 4.3, hvilke overvejelser der er foretaget i de forskellige
faser.
$np$
Dette afsnit beskriver faserne 1-3 og
afsnit 5 beskriver, hvad
der er foretaget under fase 4 og fase 5 beskrives i afsnit 8.
Opsummerende kan
nævnes, at fase 1-5 går ud på følgende:
$lm20$
$nl$
$nl$
1.Problemidentifisering.
$nl$
2.At afklare formålet med vurderingen.
$nl$
3.Planlægge selve evalueringsstudiet.
$nl$
4.Implementering af planen.
$nl$
5.Præsentation af resultaterne.
$nl$
$lm0$
$nl$
I afsnit 4.4 beskrives, hvilke præstationsindeks der har været betragtet.
$ns1,4,_«bs»4_«bs»._«bs»1_«bs»._«bs»P_«bs»r_«bs»o_«bs»b_«bs»l_«bs»e_«bs»m_«bs»i_«bs»d_«bs»e_«bs»n_«bs»t_«bs»i_«bs»f_«bs»i_«bs»c_«bs»e_«bs»r_«bs»i_«bs»n_«bs»g_«bs».$
$np$
I forbindelse med at identificere evalueringsstudiets formål,
vil det være rimeligt først at beskrive, hvorfor evalueringsstudiet
overhovedet foretages.
$np$
Det hos KTAS kørende OP-system's belastning er afhængig af, hvormange
mennesker der ringer ind til telefonnummeroplysningen. Imidlertid
er dette ikke den eneste faktor, der har indflydelse på belastningen.
Det har vist sig at kapaciteten af de indgående telefonlinier til
telefonnummeroplysningen ligeledes er en væsentlig faktor.( En del ringer ind og der er optaget. Hvor stor denne del er vides
ikke helt præcist). I forbindelse
med dette aspekt er problemmet om et evalueringsstudium opstået
på følgende måde:
$np$
Da evalueringsstudiet blev påbegyndt fandtes en given belastning til
OP-systemet.
En forøgelse
af belastningen på systemet forventes af følgende 2 grunde:
$lm20$
$nl$
$sb@,6$
$lt1,@@@@@1)$
Systemet skal udvides således, at der fra de to andre
store telefonselskaber Jydsk Telefon og Fynsk Telefon indkommer
forespørgsler til KTAS. Dette har indtil den 1.5.81 ikke været
muligt.
$nl$
$lt1,@@@@@2)$
Kapaciteten af de til telefonnummeroplysningen indgående linier
forøges, og dermed vil færre personer få optaget, når de ringer
til 0034.

$lm0$
$nl$$np$
Disse to faktorer bevirker, at en forøgelse af belastning af OP-systemet
kan forventes. Derfor opstod behovet for et evalueringsstudium af OP-systemet
til besvarelsen af følgende spørgsmål:
$lm20$
$nl$
$lt1,@@@@@a)$
Kan OP-systemet med de nuværende ressourcer klare en forøget belastning?
$nl$
$lt1,@@@@@b)$
Hvor stor belastning kan det klare ?
$nl$
$lt1,@@@@@c)$
Hvordan kan OP-systemet forbedres så det kan klare en forøget belastning ?
$lm0$
$nl$$np$
Disse spørgsmål
er set ud fra et datamatisk synspunkt, centrale spørgsmål
i forbindelse med præstationsvurdering, og kan her omformuleres, så de benytter de i præstationsvurdering
benyttede termer til følgende spørgsmål:

$lm20$$nl$
$lt1,@@@@@1)$
Hvor godt fungere OP-systemet?
$nl$
Uddybende: Præstationsindeks som svartiden for en forespørgsel og udnyttelsen
af de indgående enheder betragtes. At besvare spørgsmål a) vil så være det
samme som at svare på, hvordan opfører disse præstationsindeks sig, når
belastningen øges ?
$nl2$
$lt1,@@@@@2)$
Kan og i givet fald hvordan forbedres systemet?
$nl$
Uddybende: Hvordan kan systemet ændres så f.eks. præstationsindekset
den gennemsnitlige svartid formindskes?
$nl2$
$lt1,@@@@@3)$
Hvor stor er spidsbelastningen ?
$nl2$$lt1,@@@@@4)$
Hvilke transaktioner er særligt tidskrævende og hvad er deres svartid ?
$lm0$$nl$
$ns1,4,_«bs»4_«bs»._«bs»2_«bs»._«bs»F_«bs»o_«bs»r_«bs»m_«bs»å_«bs»l_«bs»e_«bs»t__«bs»m_«bs»e_«bs»d__«bs»e_«bs»v_«bs»a_«bs»l_«bs»u_«bs»e_«bs»r_«bs»i_«bs»n_«bs»g_«bs»s_«bs»s_«bs»t_«bs»u_«bs»d_«bs»i_«bs»e_«bs»t_«bs».$
$np$
Det primære formål med dette evalueringsstudium er naturligvis at besvare
de ovenstående spørgsmål.
Imidlertid vil der ved besvarelsen af spørgsmålene kunne opstå forskellige aspekter
om, hvordan skal spørgsmålene betragtes.
$np$
Det følgende afsnit vil nøjagtigt
beskrive ud fra hvilke synspunkter spørgsmålene skal besvares.
$nl$
Spørgsmål 1 kan besvares ud fra 2 hovedaspekter:
$lm20$
$nl$
$nl$
En brugers.
$nl$
En driftleders.
$nl$$lm0$
$nl$
Disse 2 aspekter behøver nødvendigvis ikke at være modstridende, men
i mange tilfælde vil de være det. F.eks. vil en bruger
formentlig være interesseret i en så lille svartid som muligt. Derimod
vil en driftleder
være mere interesseret i at systemet kan klare så
mange forespørgsler som muligt indenfor en given tid.
$np$
$np$
Spørgsmål 2) skal besvares både ud fra den interesse KTAS har i evalueringsstudiet
og ud fra en generel betragtning af systemet.
Dette kan belyses på følgende måde:
$nl$
For KTAS vil en forbedring af systemet først og fremmest skulle
foretages ud fra de i systemet eksisterende ressourcer. En besvarelse
af spørgsmålet ud fra en generel interesse vil f.eks. også
være at angive, at med et hurtigere pladelager, vil den gennemsnitlige
svartid kunne formindskes.
$np$
Besvarelsen af spørgsmålet skal således foretages ud fra begge de
ovenfor anførte synspunkter.
$ns1,4,_«bs»4_«bs»._«bs»3_«bs»._«bs»P_«bs»l_«bs»a_«bs»n__«bs»f_«bs»o_«bs»r__«bs»e_«bs»v_«bs»a_«bs»l_«bs»u_«bs»e_«bs»r_«bs»i_«bs»n_«bs»g_«bs»s_«bs»s_«bs»t_«bs»u_«bs»d_«bs»i_«bs»e_«bs»t_«bs».$
$np$
Når et evalueringsstudium skal planlægges, er det vigtigt at vide,
hvilke måleredskaber der er mulighed for at anvende, og dermed hvad der er
mulighed for at måle. Afsnittet bliver indledt med en beskrivelse af
de måleredskaber, som kan anvendes på OP-systemet. Derefter bliver selve planen
for evalueringsstudiet forelagt.
$np$
I afsnit 3.2 findes en beskrivelse af, hvilken information logfilen indeholder.
Til læsning af indholdet i logfilen er konstrueret et program, der er beskrevet
i afsnit 5.2. Heri er ligeledes beskrevet, hvad der måles, og hvorfor
dette gøres.
Nedenstående afsnit indeholder derfor primært en redegørelse for, hvad
der kan måles andre steder i systemet.
$np$
Det kan fra afsnit 3 opsummeres, hvordan en forespørgsel passerer gennem
de i OP-systemet indgående enheder:
$nl10$
figur 4.3
$nl2$
På figuren kan ses, at en forespørgsel passerer 2 gange gennem 3 RC3500 og 1
gang gennem en RC8000.
$np$
Ved hjælp af logfilen er det muligt at måle, hvorstor den gennemsnitlige
svartid er i en RC8000, derimod findes denne mulighed ikke i de 3 RC3500.
Disse 3 maskiner er alle programmeret i et maskinsprog kaldet SLAM. Ved
påbegyndelsen af evalueringsstudiet undersøgtes forskellige muligheder
for at finde svartiden i en RC3500.
$np$
Her viste sig begrænsninger i at måle den gennemsnitlige svartid på
grund af at det foreliggende system er et kørende system. Da de to
RC3500 på figuren betegnet NP og FP er særdeles centrale i systemet,
er det under ingen omstændigheder muligt ved et
programmelredskab at undersøge svartiden
i disse enheder. Dette skyldes, at hvis en af de 2 maskiner
ikke fungere så vil hele kapaciteten af OP-systemet være reduceret meget,
og det vil formentlig ikke kunne klare en spidsbelastning.
Derimod er der ved den sidste RC3500 mulighed for at indsætte noget kode,
idet man ved KTAS råder over en ekstra af disse maskiner.
$np$
Muligheden for at indsætte nogle "soft-ware"-tællere blev derfor overvejet. Dette
var særdeles tidskrævende og desværre resultatløst.
Dette skyldes følgende omstændighed:
$np$
Den tidskrævende faktor skyldes at opgaveløseren ikke kendte programmeringssporget
SLAM. Efter at et vist kendskab til dette var opnået, undersøgtes den kode,
der normalt findes i en af denne type RC3500. Dette resulterede i et forsøg på at
indsætte to tællere.
$np$
Disse tælleres opgave skulle være at finde den gennemsnitlige svartid for
en forespørgsel i en RC3500. Dette kan gøres ved at registrere
tiden for ankomsten og afgangen af en forespørgsel. Ved at summere
differencen mellem afgangen og ankomsten, vil den samlede tid som forespørgslen
benyttede i maksinen kunne registeres. Den anden tællers formål
er så at optælle antallet af forespørgsler.
Ved denne metode vil det være muligt at finde den gennemsnitlige svartid for en forespørgsel i RC3500.
$np$
Imidlertid viste dette sig umuligt at gennemføre af følgende grund.
Tælleren der skulle sammentælle differencen mellem afgangs- og ankomsttiden
skulle indsættes i en rutine i RC3500 kaldet "clock-driveren".
Det forventedes, at tiden kontinuerligt blev optalt i denne driver. Dette er
imidlertid ikke tilfældet, idet tiden kun tælles op, hvis der sker en
"hændelse". Med en hændelse menes her, at RC3500 f.eks. modtager et
signal fra en anden enhed.
Da det var umuligt at overskue om tiden blev talt op for hver
hændelse, var det desværre nødvendigt at forkaste denne metode.
$np$
I stedet blev et "hard-ware tool" anvendt til at måle, den
gennemsnitlige svartid for en forespørgsel for hele systemet.
Dette blev gjort ved på den i selve skærmen
eksisterende elektronik at påsætte nogle prober. Disse kan
rregisterer, når en forespørgsel sendes og modtages. Ved at koble et
ur i forbindelse med disse prober, er det muligt at måle, hvor lang tid en
forespørgsel tager i hele OP-systemet.
$np$
Ud fra disse overvejelser blev følgende plan for evalueringsstudiet
lagt.
$np$
Planens formål er at forsøge at afdække så mange aspekter indenfor
præstationsvurdering som muligt. Den går
ud på at vurdere OP-systemet udfra følgende 3 aspekter:
$nl$
$lm20$
$nl$
1.Ved målinger på systemet.
$nl$
2.Ved simulering.
$nl$
3.Ved en analytisk model.
$nl$$lm0$
$nl$
Det er meningen ud fra målinger på systemet at afdække væsentlige dele
af systemet. Dvs de dele, hvor der foregår mest tid. Derefter skal en simulator konstrueres
til at simulere disse dele af systemet. Ved denne simulator skal
det være muligt at variere på så mange installationsparametre som muligt.
$np$
Simulatoren skal også benyttes til at måle de størrelser, der ikke er
direkte målelige på det kørende system.
Udfra simulatoren skal ligeledes findes størrelser, der kan bruges
i forbindelse med en analytiske model af systemet.
Da de eksisterende analytiske modeller af datamatiske systemer er ret
simple og ikke kan afdække samtlige interessante aspekter ved systemet,
vil hovedvægten i evalueringsstudiet blive lagt på punkt 1 og 2.
Hvordan studiet foretages og planen måske ændres undervejs
beskrives mere udførligt undervejs.
$ns 1,4,4.2.Betragtede præstationsindeks.$
$np15$
Det følgende afsnit beskriver, hvilke præstationsindeks som anses
for væsentlige i forbindelse med dette evalueringsstudium. Ved beskrivelsen
af de enkelte indeks anføres med begrundelse, hvorfor de betragtes, og
hvordan de kan måles. For de præstationsindeks, der ikke benyttes, angives
en begrundelse for, hvorfor de ikke benyttes.
$np$
Præstationsindeksene kan som beskrevet i afsnit 2 opdeles i 2 hovedgrupper:
$nl$$sj$
1.Belastningsindeks.

2.Systemindeks.
$rj$
$nl$
Den nedenstående beskriver indeksene efter denne inddeling. Ved den samlede vurdering
af systemet er det der primært har interesse er, hvordan systemindeksene
afhænger af belastningsindeksene.
$np$
Til begge grupper af indeks, er det vigtigt inden eksperimenter udføres
i forbindelse med de anvendte indeks at beslutte længden af observationsperioden,
hvorunder indeksene betragtes.
Da det betragtede system opfører sig nogenlunde ækvivalent fra dag til dag, er det
besluttet, at den største observationsperiode skal være et døgn.
Termen "nogenlunde" ækvivalent er anvendt, idet der kan være afvigelser i systemets opførsel fra dag til dag, hvis helligdage o.l. betragtes.
Målingerne som jeg foretager vil dog kun blive foretaget på almindelige hverdage.
$ns 1,4,4.2.1.Belastningsindeks.$
$np$
Nedenstående beskriver, hvilke belastningsindeks der har været overvejet
at benytte. Ved de benyttede indeks anføres, hvilken mulighed, der findes
for at måle dem.
$nl2$
Antal ankommende job i observationsperioden.
$nl$
Dette indeks betragtes, da det i forbindelse definerer en væsentlig del af
belastningen. Belastningen af et datamatisk anlæg kan defineres ud fra to
spørgsmål:
$nl$$sj$
1.Hvor mange benytter maskinen ?

2.Hvad ressource krav har de ?
$rj$$nl$
Dette indeks er et udtryk for svaret af spørgsmål 1 ved denne evaluering.
Et andet indeks, der normalt ved online-systemer benyttes til besvarelse af
spørgsmål 1 er, hvor mange terminaler er koblet til maskinen. Dette indeks
betragtes ikke, da kun en del af hele OP-systemet betragtes. Ved denne del
vil antallet af ankommende job være et bedre indeks end aktive terminaler.
I det nedenstående benyttes ofte betegnelsen forespørgsel for job.
$nl2$
Ankomsthastighed.
$nl$
Dette indeks har direkte forbindelse med ovenstående og defineres
som (antal ankommende job)#observationsperioden. Begge de anførte
indeks er direkte målelige på OP-systemet ved hjælp af logfilen.
De anvendes som inddata til simulatoren.
$nl2$
Overgangssandsynlighedsmatrix.
$nl$
Dette er en matrix, som beskriver en forespørgsels vej gennem systemet.
Hvordan den findes, og en nøjere beskrivelse af dens betydning findes
i afsnit 6.2.1. Det kan virke ejendommeligt at medtage denne matrix i
beskrivelsen af belastningsindeks. Dette skyldes imidlertid, at den sammen
med de enkelte forespørgslers CPU-tidskrav i de enkelte processer præcist
definerer svaret på ovenstående 2. spørgsmål.
$nl2$
Gennemsnitlig CPU-tid for en forespørgsel i en proces.
$nl$
Defineres som den tid en forespørgsel benytter CPU i en af de 4 processer.
Størrelsen kan måles i logfilen, og den benyttes som inddata til simulatoren
sammen med overgangssandsynlighedsmatricen.
$nl2$
Gennemsnitlig antal pladelagertilgange pr. forespørgsel.
$nl$
Angiver belastningen af de 3 pladelagre knyttet til OP-systemet.
Kan ikke måles ved logfilen. Forsøges fundet dels ud fra
dybere kendskab til OP-systemets konstruktion, og dels ud fra
kendskab til accestiden til pladelageret sammenholdt med
tiden en forespørgsel befinder sig i en proces.
$nl1$$np$
Opsummerende giver de anførte størrelser en model for
belastningen af systemet. Denne model består således i,
hvormage forespørgsler der ankommer, og en beskrivelse
relateret til OP-systemet om disse forespørgslers
gennemsnitlige ressourcekrav.
$np$
Et alternativ til denne belastningsmodel kan være istedet for at på
de gennemsnitlige ressourcekrav (CPU-tid og pladelagertilgange) beregnet
for samtlige forespørgsler, så at knytte ressourcekravene til
de enkelte forespørgsler i overgangssandsynlighedsmatricen.
Dette kan begrundes ved følgende argument:
$nl$
Det er for stor en simplificering at se på de gennemsnitlige ressourcekrav
for alle forespørgsler, idet der er meget stor forskel i de enkelte
forespørgslers ressourcekrav afhængig af, hvilken vej de passere gennem systemet.
$nl2$
Eksempel:
$nl$
En gennemført søgeforespørgsel passerer gennem OP-systemet ved følgende vej:
$nl$
input -> søge -> opslag -> output
$nl$
Forespørgslen vil benytte både mere CPU-tid og flere pladelagertilgange
end en forespørgsel, der afvises eksempelvis på at et kriterie ikke findes.
I opslagsprocessen vil denne forespørgsel ligeledes i gennemsnit skulle
finde 9.5 kandidater, i modsætning til en telefonnummerforespørgsel,
der kun skal finde en kandidat. Det kunne forventes, at CPU-tidens
fordeling i opslagsprocessen derved ville have følgende udseende:
$nl15$
Hvis CPU-tiden var fordelt som på ovenstående figur, ville den betragtede
belastningsmodel ikke være helt præcis. Imidlertid har målinger vist at
CPU-tiden er fordelt som på nedenstående figur.
$nl15$
Denne kurve tilnærmer sig eksponentialfordelingen, og ved at benytte denne
fordeling vil den betragtede belastningsmodel afgående CPU-tiden ikke
være en stor fejlkilde.
$np$
For antallet af pladelagertilgange vil forholdet muligvis være et andet,
men da der ikke er mulighed for at måle dette antal, er det besluttet
at fastholde den beskrevne belastningsmodel.
$ns 1,4,4.2.2.Systemindeks.$
$np$
Dette afsnit indeholder en beskrivelse af, hvilke system(præstations)indeks,
det har været overvejet at benytte. I afsnittet vil den i afsnit 2.1 foretagne opdeling
af præstationsindeks i produktive-,reaktions- og udnyttelsesindeks blive fulgt
ved beskrivelsen. Ved hvert indeks anføres, hvordan det måles, og eventuelt
hvorfor det ikke benyttes.
$nl2$
Produktive indeks.
$nl$
Gennemstrømningshastighed.
$nl$
Defineres som antal job der forlader systemet pr. tidsenhed. Denne
størrelse betragtes ikke specifikt, da den ved dette system meget
gerne skulle være det samme som ankomsthastigheden. Normalt vil dette
indeks dog sige noget om systemets evne til at klare en forøget belastning.
$nl2$
Maksimal gennemstrømning.
$nl$
Dette indeks forsøges fundet ved hjælp af simulatoren. I Ferr78 side 190
angives Kintchine-Pollaczek formel for svartidens afhængighed af
belastningen. På en figur kan svartiden's afhængighed af belastningen
aftegnes som på nedenstående figur.
$nl15$
Denne kurve vil have en lodret asymptote som svarer til datamaskinens
maksimale gennemstrømning. Ved denne opgave vil belastningen
være tegnet ud af X-aksen, og være antallet af forespørgsler pr time.
Asymtotens skæring med X-aksen vil så være det maksimale antal
forespørgsler OP-systemet kan klare.
$nl2$
Trafik intensiteten.
$nl$
Denne størrelse defineres i følge Ferr78 s.182 som ankomsthastigheden divideret
med afviklingshastigheden. Afviklingshastigheden er 1# gennemsnitlig behandlingstid.
Det kan bemærkes at størrelsen normalt vil være mindre end 1. Denne
størrelse siger noget om hvor mange job der bliver afviklet pr tidsenhed.
Den kan beregnes ved målinger på systemet, men den betragtes ikke i forbindelse med
denne opgave. Dete skyldes at andre størrelser efter min mening udtaler
sig bedre om jobbenes afvikling.
$nl2$
Udvidelsesfaktor.
$nl$
Denne størrelse defineres normalt som svartiden divideret med den ideele
svartid. Den ideele svartid for et job er tiden jobbet befinder sig
i systemet, hvis det var alene i systemet. Til en given belastning
vil svartiden være forøget, og udvidelsesfaktoren siger så noget om
hvor godt systemet er, når belastningen forøges. Denne faktor betragtes
ikke, da svartidens afhængighed af belastningen efter min mening udtaler
sig om det samme og på en bedre måde. Det vil også være vanskeligt at
beregne den ideele svartid for en forespørgsel ved OP-systemet.
$nl2$
Kølængder.
$nl$
Udover de 4 ovenfor beskrevne produktionsindeks, betragtes kølængde til
de i OP-systemet indgående processer. Disse kan dog ikke måles ved OP-systemet,
men kan kun findes dels ved hjælp af simulatoren og dels ved hjælp af
Little's lov se Denn78 s235. Little's lov siger at
$nl$$sj$
ni = XiRi
$rj$
$nl$
hvor ni er den gennemsnitlig kølængde ved enhed i, Xi er outputhastigheden ved
enhed i og Ri er svartiden ved enhed i. Udover kølængden ved de enkelte
processer måles ved hjælp af simulatoren kølængden af aktivkøen i RC8000 (se afsnit 3.4)
$nl2$
$np$
Det ville måske være rimeligt at betragte andre produktionsindeks end de ovenfor
anførte, men jeg har ikke fundet andre indeks der siger mere om systemets ydeevne.
$nl$
2.Reaktionsindeks.
$nl$
Den gennemsnitlige svartid.
$nl$
Dette indeks afhængighed af belastningen betragtes, derudover betragtes indeksets samlede værdi for et helt døgn. Når der foretages målinger
ved hjælp af logfilen ved OP-systemet, vil værdien af den gennemsnitlige svartid
ikke være helt nøjagtig. Svartiden defineres som afgangstiden - ankomsttiden, hbor begge størrelser betragtes i forhold til RC8000. Det er imidlertid ikke muligt
at måle ankomsttiden til RC8000, men derimod kun ankomsttiden til den første proces. Det vil sige køtiden for forespørgslen ved inputprocessen medregnes ikke
i svartiden.
$np$
Ved simulatoren er der mulighed for at danne sig et billede af, hvor stor denne
fejl er. (Det er her muligt at finde køtiden for inputprocessen)
$np$
Udover gennemsnitlige værdier for svartiden måles også minimal, maksimal og fordelingen
af svartiden. Under fordelingen af svartiden, er det muligt at finde f.eks. hvor mange
procent af forespørgslerne der har en svartid mindre end eksempelvis 2 sekunder.
$nl2$
Procestid og Køtid
$nl$
Disse størrelser som er specifikt defineret i relation til dette evalueringsstudie er defineret i afsnit 6.2 og måles
både ved simulatoren og ved logfilen. De måles for samtlige 4 processer og samlet.
$nl2$
Pladelagertilgangstid
$nl$
Et reaktionsindeks der interesserer er den gennemsnitlige pladelagertilgangstid.
Denne størrelse kan desværre ikke måles i logfilen. Imidlertid kan den findes i en
karakteristik om selve pladelageret. Fra RCSL no 30-m43 (Peter Koch Anderson)
er følegende størrelser hentet:
$nl$
Pladelageret roterer således, at der er 3600 omdrejninger pr. minut. Dvs. at 1
omdrejning tager 16.6 ms. Positioneringstiden for en hovedflytning er mellem 7
og 55 ms. Den gennemsnitlige positioneringstid er ifølge ovenstående manual
fundet til 30 ms. Når hovedet befinder sig på det ønskede spor, skal pladen
normalt dreje 1#2 omgang i gennemsnit for at finde den ønskede sektor. Dette
tager så 8.3 ms. Dvs. den gennemsnitlige pladelagertilgangstid er 38.3 ms.
Overførselstiden af data fra pladelageret sker med en hastighed af 2.4 ord#mikrosekund. Da et segment indeholder 256 ord svarer dette til 0.6 ms pr segment.
$np$
Imidlertid vil en pladelagertilgang ved OP-systemet normalt ikke tage så lang
tid, idet man ved dette system foretager en fremtidig positionering se afsnit 8.2.
$nl2$
Monitor skiftetid.
$nl$
Dette indeks defineres som den tid monitoren er om at skifte mellem to processer.
Brin73 definerer s.241 en monitor som en programudvidelse af maskinstrukturen,
som gør en datamaskine mere attraktiv for multiprogrammering. Monitoren kontrollere input#output, lager beskyttelse og svarer på interrupts.
Størrelsen kan ikke findes i logfilen, og den er ret vanskelig at bestemme.
$nl2$
3.Udnyttelsesindeks.
$nl$
De betragtede udnyttelsesindeks kan opdeles i 2 kategorier:
$nl$$sj$
1.Udnyttelsen af maskinelle ressourcer.

2.Udnyttelsen af programmelenheder.
$rj$$nl$
De i litteraturen benyttede undersøgelser af samme art som ved dette speciale,
drejer sig i første række om opstilling af modeller (eks. Queuing Network Models) til undersøgelse af maskinelressourcer. Mun78 skriver direkte at der i litteraturen savnes modellen til undersøgelse af programmelenheder.
I forbindelse med dette speciale, vil indgå en undersøgelse af udnyttelsen af de
indgående enheder. Det vil dog ikke blive forsøgt at opstille en teoretisk model, istedet forsøges de normale modeller om maskinelressourcer anvendt.
$np$
Til beregning af de indgående enheders udnyttelse
(både maskinelle og programmelle),
benyttes hvad Denn78 betegner udnyttelsesloven ("eng. Utilization law"). Denne
siger at
$nl$$sj$
Ui = Xi*Si
$rj$$nl$
hvor Ui er udnyttelsesgraden, Xi er behandligshastigheden og Si er den gennemsnitlige behandlingstid. (i angiver at alle størrelser relaterer til enhed i).
$np$
For at beskrive, hvordan den gennemsnitlige behandlingstid opfattes er det nødvendigt at se på de modeller, der er forudsætningen for den ovenfor angivne lov.
Normalt betragtes følgende model:
$nl20$
$nl1$
hvor en CPU og L ydre enheder betragtes. Ved de indgående enheders behandlingstid
forstås den tid et job befinder sig i enheden. Da der kun er et job under udførelse ved hver enhed ad gangen, og hver enhed kan udføre job samtidig, vil jeg opfatte
behandlingstiden, som det jeg under reaktionsindeks har betegnet CPU-tid. Imidlertid
kan ovenfor anførte model ikke direkte anvendes på OP-systemet. Ved OP-systemet vil modellen have følegnde udseende:
$nl20$
$nl$
Den væsentlige forskel er diskkanalen. Dette er en intekligent enhed, der styrer
overførslen af data fra pladelageret til det indre lager. Denne overførsel kan ske
samtidig med, at CPU-en behandler et job. Da det synes intuitivt klart at benytte
samme beregningsformel for udnyttelsen af diskkanalen som ved de andre enheder vil ovenfor anførte formel dog også blive benyttet her,.
Det ovenfor angivne illustrere således, hvilke problemer der er, når teori
om præstationsvurdering skal anvendes i praksis. Dette sidste vil blive uddybet i afsnit 8.4.
$nl$
Helt eksakt betragtes følgende udnyttelsesindeks:
$nl2$
CPU-udnyttelse.
$nl$
Defineres som samlet CPU-tid divideret med observationsperioden.
Den samlede CPU-tid er antalforespørgsler * gennemsnitlig CPU-tid pr. forespørgsel.
Kan måles på OP-systemet's logfil.
$nl2$
Diskkanaludnyttelse.
$nl$
Defineres som samlet diskkanaltid divideret med observationsperioden.
Der opstår her et problem. Når en overførsel fra pladelageret foretages, sker først en positionering af pladelagerhovedet, og først derefter overføres information fra pladelageret. Overførslen er særdeles hurtig. Imidlertid skal diskkanalen
reserveres, når hovedet befinder sig på det rigtige spor, og derved er pladelagerkanalen faktisk
optaget i 8.3 ms pr. pladelagertilgang. Kanalen vil dog kun være udnyttet en del
af denne tid helt eksakt 0.6 ms. Udnyttelsen af diskkanalen defineres dog
som den tid den er optaget og ikke kan benyttes af andre. Dvs.
$nl$$sj$
8.3 * anatalpladelagertolgange
______________________________
observationsperiode
$rj$$nl$
Kan ikke måles ved OP-systemet, men forsøges fundet ved simulatoren.
$nl2$
Pladelagerudnyttelse.
$nl$
Defineres som
$nl$$sj$
(positioneringstid + overførselstid)*antaldisktilgange
______________________________________________________
observationsperiode
$rj$$nl$
$nl2$
Procesudnyttelse
$nl$
For de 4 processer i OP-systemet defineres udnyttelsen som
$nl$$sj$
gennemsnitlig CPU-tid * antal forespørgsler
___________________________________________
observationsperiode
$rj$$nl$
Denne kan beregnes ud fra målinger på logfilen.
$nl2$
Monitorudnyttelse
$nl$
Defineres som
$nl$$sj$
monitorskiftetid * antal processkift
____________________________________
observationsperiode
$rj$$nl$
Kan ikke måles på OP-systemet.
$rh 1,ANDVENDTE MÅLEREDSKABER$
$ps0$
$ns 1,4,5.Beskrivelse af anvendte målemetoder.$
$np$
Nedenstående afsnit beskriver, hvilke måleredskeaber som anvendes ved
dette evalueringsstudium. Derudover anføres med begrundelse, hvilke eksperimenter, der på
denne baggrund er foretaget. Til målinger på systemet er både anvendt såkaldte maskinel-
og programmelredskaber.
$np$
De programmelredskaber vurderingen anvender bygger på den i afsnit 3.7
beskrevene logfil. Derudover blev foretaget et ret tidskrævende eksperiment
for at finde den gennemsnitlige svartid for en forespørgsel i en RC3500.
Dette mislykkedes, som beskrevet i afsnit 4.3.
$np$
Da selve vurderingen af OP-systemet begyndte fandtes hos KTAS, et
program til læsning af centrale dele af logfilen.
Dette program kaldes i det følegende OPSTAT, og det kan udskrive en ret
detailjeret statistik om, hvordan OP-systemet fungerer.
Imidlertid er der efter min mening visse mangler ved denne statistik, som
jeg synes er meget centrale, når en vurdering af OP-systemet skal
foretages. Nedenstående indeholder først en beskrivelse af OPSTAT, og derefter
følger en beskrivelse af mit udviklede program. Dette betegnes i det følgende
KTASSTAT. I afsnit om OPSTAT vil det endvidere blive begrundet, hvorfor
det var nødvendigt at udvikle et eget statistik program.
$ns 1,4,5.1.Beskrivelse af OPSTAT.$
$np$
Dette program, som er skrvet i ALGOL, benyttes normalt af KTAS til udskrivning
af statistik om OP-systemet. OPSTAT er derfor konstrueret så de spørgsmål
man har fra KTAS's side kan dækkes ved det. Det vil være for omfattende her at beskrive, hvordan hele statistikken ser ud. Dette kan ses i bilag ??.
Nedenstående afsnit vil således primært beskæftige sig med hovedideerne for
statistikken. Dette vil være nok til at forstå, hvorfor det var nødvendigt
at udforme et program til en egen statistik.
$np$
OPSTAT er opbygget således, at den giver information om følgende 3 områder:
$lm30$
$sb^,6$
$nl$
1.Antallet forespørgsler opdelt i et antal forespørgselstyper.
$nl$
2.Svartiderne for forskellige forespørgselstyper.
$nl$
3.Kriteriesammensætningen ved de mest belastende forespørgselstyper.
$nl$
$lm0$
$np$
For de to første områder gælder,
at statistikken her er opdelt efter områdenummeret i telefonnummeret, dvs
01,02 og 03. Udover denne opdeling findes en samlet statistik,
hvor resultaterne fra de 3 områder er summeret.
$np$
De vigtigste forespørgselstyper man opererer med i statistikken er søgeforespørgsler
og telefonnummer forespørgsler.
Disse adskiller sig væsentligt i svartiden, og det skyldes( se afsnit 3.2),
at de passere på forskellig måde gennem systemet.
$np$
OPSTAT indeholder for disse to forespørgselstyper tal om, hvormange der har været og svartiderne for dem.
Indenfor begge forespørgselstyper opdeles forespørgslerne derudover afhængig af
dels deres kriteriesammensætning og dels af deres antal svar.
$np$
Opsummerende kan siges, at hovedformålet med statestikken er at kunne svare på spørgsmål
om, hvor lang svartiden er for en speciel forespørgselstype.
$np$
De tabeller i OPSTAT der er af størst interesse, når en samlet vurdering af OP-systemet, skal foretages er følgende:
$nl1$$sj$

svartid ms afg - ank ms køtid ms cputid ms

input proces 25 25 14

søge - 566 375 191 145

opslag - 267 225 42 80

output - 24 11 13 8

IALT 884 636 247 248

Tabellen er fra en OPSTAT den.25.08.80

$rj$
Tabellen viser et billede af, hvordan svartiden for en søgeforespørgsel foregår
i de 4 processer. De i tabellen indgående størrelser defineres i afsnit 6.2
$np$
At denne statistik ikke er god nok kan nu illustreres ved, at ovenstående tabel
kun bygger på gennemførte søgeforespørgsler. Fra OPSTAT svarende til samme dag
kan ovenstående tabel således kun findes for følgende forespørgsler:
$sj$

19625 gennemførte søgeforespørgsler

13101 telefonnummer forespørgsler
_____________________________________

32726 Ialt antal gennemførte forspørgsler
==========================================
$rj$
$nl$
Det samlede antalforespørgsler, som findes i logfilen svarende til den 25.08.80
er 55128.
Dvs. det er kun muligt at finde en tilsvarende tabel for ca. 60 % af samtlige
forespørgsler. Da f.eks. en størrelse som udnyttelsen af de indgående processer
gerne skulle findes, vil det være nødvendigt at have en tabel som bliver baseret på samtlige af systemet behandlede forespørgsler indenfor et givent tidsrum.
$np$
Udover denne grund fandtes en anden særdeles væsentlig grund til at konstruere
en egen statistik. For at afklare systemets ydeevne er det vigtigt at kende de målte
størrelsers afhængighed af belastningen. Belastningen af OP-systemet er næsten kun afhængig af på hvilket tidspunkt af dagen målingerne foretages. Det fra min
side udviklede program gennemløber således logfilen, og udskriver resultater som i ovenstående tabel
svarende til tidspunktet i døgnet.
$ns 1,4,5.2.Beskrivelse af KTASSTAT.$
$np$
Dette program, som er skrevet i ALGOL, er delvist udviklet af undertegnede og
dels af Bent Bæk Jensen. Programmets overordnede funktion bliver beskrevet i nedenstående.
Imidlertid vil der ikke blive lagt vægt på selve den programtekniske udformelse.
Dette skyldes at det ligger udenfor denne opgave, og der findes i programmet
indbygget en masse test af afviklingstekniske årsager.
$np$
De problemer der har været i forbindelse med afviklingen er kort, at
programmet skal udføres hos KTAS. Derudover skal det udføres på en maskine
der normalt benyttes som OP-maskine. Dette bevirker sammen med det faktum
at den normale afviklingstid er ca. 1#2 time, at programmet helst skal
være korrekt første gang. Med korrekt menes her, at programmet ikke må gå
i stå program af afviklingsfejl såsom at dividere med 0 eller lignende.
$np$
Hovedformålet med programmet er at besteme nogle centrale præstationsindeks som svartiden o.l. og bestemme deres afhængighed
af belastningen af systemet.
$np$
Programmet læser logfilen igenem og finder alle poster hørende til
det døgn, som er specificeret i programkaldet.
Programmet kan opdeles i 5 dele.
$np$$nl$
1.Oversigtstal for OP-systemets behandling af en forespørgsel.
$np$
Fromålet med denne del er at kunne beregne, hvormeget de enkelte
processer er belastet, og hvor lang tid de gennemsnitlig er om at behandle
en forespørgsel. Derudover er formålet at finde en for simulatoren
central overgangssandsynlighedsmatrix. (se afsnit 6.2.1.)
$nl2$
Ved denne del af programmet udskrives følgende størrelse for hver proces:
$sj$

ANTAL FORESPØRGSLER

SAMLET TID

GENNEMSNITLIG PROCESTID

VARIANCEN PÅ PROCESTIDEN

GENNEMSNITLIG CPUTID

VARIANCEN PÅ CPUTIDEN

GENNEMSNITLIG KØTID

VARIANCEN PÅ KØTIDEN

Derudover udskrives samlet for de 4 processer:

TOTAL PROCES TID

ANTALFEJL OG BLADNINGER

$rj$
$nl$
De ovenfor indgående størrelser defineres nu på følgende måde:
$nl2$
SVARTIDEN
$np$
Defineres som afgangstiden - ankomsttiden til kø til pågældende proces.
For inputprocessen gælder specielt, at dette er første proces der behandler
en forespørgsel i RC8000. Dette bevirker, at det ikke er muligt at finde,
hvor lang tid en forespørgsel stå i kø til denne proces.
Svartiden for inputprocessen vil således være det samme som procestiden.
$nl2$
PROCESTID
$np$
Defineres som afgangstiden - ankomsttiden. Her indikere ankomstiden det
tidspunkt, hvor selve processen påbegynder behandlingen af forespørgslen.
Procestiden kan således opfattes som den tid en forespørgsel befinder sig
inde i selve processen. Dvs. det er en sum af den CPU-tid forespørgslen benytter, den tid
der normalt betegnes "over-head"- tid, og den tid der benyttes til pladelagertilgange.
Ved "over-head"-tiden forstås den tid som går dels med at skifte mellem processerne og dels med at behandle forespørgsler ved de andre processer.
$nl2$
KØTID
$np$
Defineres som den tid der går fra en forespørgsel forlader en proces til den
begynder ved en anden proces. Dvs. størrelsen er afhængig af, hvilken vej forespørgslen
passerer gennem systemet.
Ved inputprocessen vil denne af ovenfor angivne årsag altid være 0.
$nl2$
CPUTID
$np$
Defineres som den tid en forespørgsel benytter til egentlig CPU-behandling.
$nl$
Til beregning af gennemsnittet for de indgående størrelser er
følgende formel benyttet:
$nl3$
hvor n er antal observationer og ti er tiden for de enkelte observationer.
Til beregning af variancen benyttes følgende:
$nl3$
Når n er stor, som det er tilfældet her kan dette reduceres til
$nl20$
$nl$
Den samlede tid er procestiden, og den benyttes til at finde den gennemsnitlige svartid i processerne. Totalprocestid benyttes til at finde den gennemsnitlige ssvartid for en forespørgsel i hele RC8000. Antalfejl og bladninger benyttes til at
finde den ovenfor omtalte overgangssandsynlighedsmatrix.
$np$
De ovenfor angivne størrelser udskrives dels for hver time i døgnet og dels fDe ovenfor angivne størrelser udskrives dels for hver time i døgnet
og dels samlet for hele døgnet. Dette sidste bruges til at sammenligne tallene
med OPSTAT for at give et indtryk af om KTASSTAT finder de rigtige størrelser.
$np$
For bedre at kunne overskue disse 24 observationer hørende til hver time i døgnet
samles observationerne i 4 oversigtstabeller( en for hver proces).
I disse oversigtstabeller er observationerne samlet i grupper svarende til antaltusind forespørgsler. Eksempelvis udskrives, hvor mange
observationer, der havde mellem 0 og 1000 forespørgsler. Her udskrives
så antallet af observationer og gennemsnittet for disse.
$nl2$
2.CPU-tidsfordeling.
$np$
Ved simulatoren benyttes eksponentialfordelingen til at simulere variationen
i CPU-tiden for de enkelte forespørgselstyper. For at overskue hvor
nøjagtigt dette er udskrives for hver af de 4 processer, hvordan CPU-tiden
fordeler sig.
$nl2$
3.Svartidsfordeling og udnyttelsesfordeling.
$np$
Formålet med denne del er præcist at se CPU-ens udnyttelsesgrads afhængighed af
belastningen.
$nl2$
4.Svartidsfordeling.
$np$
Formålet med denne del af programmet er at dAnne sig et indtryk af, hvor
stor spredning, der er på svartiden. Ved mange vurderinger er man interesseret i
at en vis procentdel af samtlige forespørgsler har en svartid under et
fast antal ms.
$nl2$
5.Ydertilfælde.
$np$
Her udskrives de mindste og største værdier for den samlede svartid.
$ns 1,4,5.2.1.Beregning af overgangssandsynlighedsmatrix.$
$np$
Ved konstruktionen af simulatoren er det særdeles vigtigt at kende, hvorledes
en forespørgsels vej gennem systemet er. Dvs. at følgende overgangssandsynlighedsmatrix skal findes:
$sj$

input søge opslag output

input 0 a(2,1) a(3,1) a(4,1)

søge 0 0 a(3,2) a(4,2)

opslag 0 0 0 a(4,3)

output 0 0 0 0

$rj$
Denne skal opfattes således at rækkeindekset angiver fra hvilken
proces forespørgslen kommer og søjle indekset angiver den modtagende proces. Dvs. at eksempelvis a(2,1) er sandsynligheden for at en forespørgsel passerer fra
inputprocessen til sogeprocessen. De i matricen indgående 0'er kan hurtigt placeres,
idet de angiver, at det er umuligt at passerer således.
$np$
Derefter kan følegende størrelser findes direkte fra KTASSTAT.
$sj$

antal forespørgsler i søgeproces
a(2,1) = _________________________________
Total antal forespørgsler

Antalfejl og bladninger
a(4,1) = ___________________________________
Total antal forespørgsler
$rj$
$nl$
Derefter kan a(3,1) beregnes, idet summen af hver række skal være 1.
$sj$

a(3,1) = 1 - ( a(2,1)+a(4,1))
På ækvivalent vis findes

a(4,3) = 1
$rj$
Det er mere vanskeligt at finde a(3,2). Denne beregnes på følgende måde:
$nl$
Antallet af forespørgsler i opslagsprocessen er kendt(betegnes AO). En
forespørgsel kan kun være kommet i opslagsprocessen fra enten søgeprocessen eller input processen. Dette betyder (AS og AI betegner hhv. antal i søge og i input)
$sj$

AO = a(3,2)*AS + a(3,1)*AI

og dermed er

AO - a(3,1)*AI
a(3,2) = ____________________
AS
Når a(3,2) er kendt kan a(4,2) findes ved

a(4,2) = 1 - a(3,2).

$rj$
Eksempel:
$nl$
For tirdag den 24.03.81 gælder at
$sj$

AI = 58832

AS = 37716

AO = 35422

AOU= 58832

ANTALFEJL OG BLADNINGER = 7386
Dermed får overgangssandsynlighedsmatricen følgende udseende:

input søge opslag output

input 0 0.64 0.23 0.13

søge 0 0 0.58 0.42

opslag 0 0 0 1.0

output 0 0 0 0
$rj$
$sb ^,6$
$ps0$
$rh 1,VURDERING AF OP-SYSTEMET$
$ns 1,4,8.Vurdering af OP-systemet.$
$np15$
Dette afsnit indeholder vurderingen af OP-systemet. Afsnittet er disponeret så
afsnit 8.1 beskriver resultaterne opnået ved et elektronisk ur benyttet på
hele systemet. Ud fra dette begrundes, hvorfor den egentlige vurdering drejer
sig om RC8000-delen af OP-systemet. Afsnit 8.2 giver en vurdering af OP-systemet ud fra målinger i logfilen.
Afsnit 8.3 beskriver derefter, hvilke resultater der er opnået ved hjælp af den konstruerede
simulator. Afsnit 8.4 illustrerer de teoretiske modeller, der er betragtet.
$ns 1,4,8.1.Afgrænsning af evalueringsstudiet.$
$np$
Ved vurdering af OP-systemet er foretaget en del begrænsninger. Disse begrænsninger
foretages således, at evalueringen kan koncentreres om centrale enheder i systemet.
Begrænsningerne kommer dels fra at systemet indeholder mindre betydende enheder
og dels fra at de eksisterende måleredskaber kun kan anvendes på dele af systemet.
$np$
Ved OP-systemet eksisterer et måleredskab til RC8000-delen (logfilen), der er velegnet
til fremskaffelse af oplysninger om systemets opførsel. Ved RC3500-delen eksisterer
denne mulighed ikke. Da det endog viste sig umuligt at konstruere et anvendbart
program til at finde en forespørgsels svartid i RC3500, er mulighederne for
målinger på OP-systemets RC3500-del begrænset til maskinelredskaber.
$np$
Ved hjælp af et elektronisk ur kan en forespørgsels samlede svartid findes. Der
er derfor foretaget nogle målinger med dette ur. Ud fra disse målinger
kan beregnes, hvor meget tid de enkelte dele af OP-systemet anvender til
behandling af en forespørgsel.
$nl$
Nedenståedne tidslinie angiver, hvordan svartiden for en forespørgsel kan opdeles.
$sj$
Forespørgslen afsendes. Forespørgslen modtages.

!---!---!---!------------------------------!---!---!---!
TP NP FP RC8000 FP NP TP

Figur 8.1.1.
$rj$$nl$
De på figuren anførte forkortelser er betegnelser for de 3 RC3500, og betyder
følgende:
$sj$

TP = Terminal Processor
NP = Network Processor
FP = Front-end Processor
$rj$$np$
Målingerne ved uret finder netop længden af denne tidslinie. I logfilen kan
svartiden i RC8000 findes. Ved at subtrahere disse størrelser beregnes,
hvor lang tid en forespørgsel benytter i de 3 RC3500 tilsammen.
$np$
Fra en OPSTAT fra samme tidsperiode findes den gennemsnitlige svartid for
de 5 mest benyttede forespørgselstyper. Disse er angivet i tabel 8.1.2. Ud
over den gennemsnitlige svartid for en forespørgselstype er antallet og
hyppigheden for forespørgselstyperne angivet.
$sj$

Antalforsp. Hyppighed i % Gnst. svartid

Gennemført søgeforsp. 19625 35.6 % 884 ms
Afvist søgeforsp. 15155 27.5 % 589 ms
Bladn.+Hemmnr.+Fejl 7247 13.1 % 57 ms
Gennemført tlfnrforsp. 12228 22.2 % 183 ms

Afvist tlfnrforsp. 873 1.6 % 141 ms
____________________________________________________________

Ialt 55128 100.0 % 526 ms
=============================================================

Tabel 8.1.2.
$rj$$nl$
I tabellen er den gennemsnitlige svartid ved linien ialt vægtet efter
hyppighed af forespørgselstype.
$nl$
For hver af disse forespørgselstyper er nu foretaget 5 observationer. Hver
observation bygger på, at en forespørgsel er sendt 50 gange og svartiden er noteret.
$np$
Tabel 8.1.3 viser resultaterne, hvor den gennemsnitlige svartid for de 5 observationer er fundet.
Ligeledes her er den gennemsnitlige svartid ved linien ialt vægtet efter hyppighed
af forespørgselstypen. For hver linie i tabellen er angivet den procentvise fordeling
af svartiden i RC8000 og i RC3500.
$sj$
Samlet svartid Svartid i RC8000 Svartid i RC3500

Gennemført søgeforsp. 1027.4 ms 884 ms 143.4 ms
Procentlig fordeling 100 % 86.0 % 14.0 %

Afvist søgeforsp. 857.2 ms 589 ms 268.2 ms
Procentlig fordeling 100 % 68.7 % 32.3 %

Blad.+Hemmnr.+Fejl. 455.6 ms 57 ms 398.6 ms
Procentlig fordeling 100 % 12.5 % 87.5 %

Gennemført tlfnrforsp. 521.9 ms 183 ms 338.8 ms
Procentlig fordeling 100 % 35.0 % 65.0 %

Afvist tlfnrforsp. 435.5 ms 141 ms 291.5 ms
Procentlig fordeling 100 % 32.4 % 67.6 %
_______________________________________________________________

Ialt 783.8 ms 526 ms 256.9 ms
Procentlig fordeling 100 % 67.0 % 33.0 %
================================================================

Tabel 8.1.3.
$rj$$nl$
Resultaterne viser ved det samlede gennemsnit for alle forespørgselstyper, at
den meste tid for en forespørgsel foregår i RC8000. For de hyppigst
forekommende forespørgsel(søgeforspørgsler) er dette endnu mere udpræget.
Tabellen viser at samlet for de 5 forespørgselstyper benyttes over
dobbelt så meget tid i RC8000 end i RC3500 til behandling af en forespørgsel.
På denne baggrund bør en evaluering af OP-systemet koncentreres om en RC8000.
Under evalueringen af en RC8000 har det vist sig at ovenstående tabel endda er ret
unøjagtig.
Målingerne ved det elektroniske ur er foretaget en hverdag mellem 9.30-14.30.
Dette er det tidspunkt på dagen, hvor OP-systemet er mest belastet. Fra
senere undersøgelser se figur 8.2.1 kan anføres, at antallet af forespørgsler pr time
i det anførte tidsrum er mindst 10.000. Målingerne er udført i efteråret 1980,
hvor der til OP-systemet anvendtes 2 RC8000. Det vil sige, der er mindst
5000 forespørgsler pr time til en RC8000. Ved dette antal vil den gennemsnitlige
svartid for en forespørgsel ikke være 526 ms, men mindst 650 ms (se figur 8.2.5).
$np$
Udover dette faktum er der en anden fejlkilde til den gennemsnitlige
svartid i RC8000. Tiden en forespørgsel står i kø til den første proces i RC8000
(inputprocessen) medregnes ikke i den gennemsnitlige svartid som måles i logfilen.
Denne størrelse kan ved en belastning på 5000 forespørgselr pr time og en monitorskiftetid på 1.5 ms, mindst sættes til 5 ms. Den gennemsnitlige svartid for samtlige
forespørgselstyper, svarende til tidspunktet, hvor målingerne er foretaget, kan
således mere præcist angives til 655 ms.
Med denne svartid i RC8000 bliver den procentvise fordeling af
svartiden i RC8000 og RC3500 en anden og den er vist i tabel 8.1.4.
$sj$
Samlet svartid Svartid i RC8000 Svartid i RC3500

For samtlige forsptyper 738.8 ms 655 ms 128.8 ms
Procentlig fordeling 100 % 83.6 % 16.4 %

Tabel 8.1.4
$rj$$nl$
De i tabel 8.1.4 anførte svartider kan ikke findes for de enkelte forespørgselstyper. Begrundelsen for dette findes i afsnit 5.2. Med de i tabellen anførte svarider i RC3500 og RC8000
betragtes nu hele OP-systemet som vist på figur 8.1.5. Forkortelserne anført på
figuren står for det samme som angivet ved tabel 8.1.1.
$nl15$
$sj$
Figur 8.1.5.
$rj$
$np$
Hele systemet betragtes i en hårdt belastet time for at finde udnyttelsesgraden af de indgående enheder.
Da de 3 RC3500 til sammen benytter 128.8 ms, antages at hver benytter 42.9 ms. Fra
en KTASSTAT den 24.04.81 kan udnyttelsen af de 3 RC8000 i den hårdest belastede
time (mellem 10-11) findes til 66.9 %. Hvis det antages at forespørgselrne
fordeles ligeligt mellem de 3 RC8000 så fås at udnyttelsesgraden af hver til 22.3 %. Udnyttelses af de RC3500 betegnet FP og NP fås nu ved
$sj$

13107 * 42.9
____________ * 1/2 = 7.8 %
60*60*1000
$rj$
Der multipliceres med 1/2, idet der findes 2 af hver RC3500. For RC3500 betegnet
TP findes udnyttelsesgraden til 1.2 %, idet der mindst findes 13 af denne type.
$np$
Begrundelsen for kun at betragte OP-systemets RC8000-del ved resten af evalueringen, kan nu på baggrund af ovenstående uddybes ved følgende:
$lm20$$nl$
$lt 1,^^^1)$
En RC8000 er den enhed med maksimal udnyttelsesgrad ( 3 gange så stor som
andre enheder).
$nl$
$lt 1,^^^2)$
RC8000 benytter mest tid til at behandle en forespørgsel.
$nl$$lt 1,^^^3)$
I RC8000 findes i modsætning til RC3500 et udmærket måleredskab (logfilen) til
en evaluering.
$nl$$lt 1,^^^4)$
Det vil være særdeles kompliceret at implementere en simulator af hele systemet,
hvis også de indgående programmelenheder i de 3 RC3500 skal implementeres.
(Se appendix 1)
$lm0$$np$
Til det sidste punkt kan anføres, at det meget tidligt ved evalueringsstudiet
blev besluttet, at en simulator skulle konstrueres til systemet. Denne skal
anvendes til at måle størrelser på systemet, som ikke kan måles på OP-systemet.
$ns 1,4,8.2.Vurdering af OP-systemet ud fra målinger i logfilen.$
$np$
Dette afsnit indeholder vurderingen af en RC8000 koblet til OP-systemet.
Vurderingen i dette afsnit bygger på målinger foretaget i logfilen.
Afsnittet indledes med et beskrive, hvilke målinger der er foretaget. Derefter angives,
hvilken belastning en RC8000 udsættes for. Så følger en analyse af de betragtede præstationsindeks afhængighed af belastningen. Herefter undersøges, hvordan
de indgående programmel- og maskinelenheder udnyttes, Til sidst i afsnittet gives
en samlet vurdering af OP-systemet RC8000-del, hvori hovedvægten lægges på systemets opførsel i en hårdt belastet time.
$np$
Ud fra vurderingen i dette afsnit vil det fremgå, hvilke enheder, der bevirker en formindskelse i systemets ydeevne. På baggrund af disse betragtninger, vil en række forbedringsforslag til OP-systemet kunne opstilles. Disse forbedringsforslag
vil blive afprøvet ved hjælp af simulatoren, og det beskrives i afsnit 8.3,
hvad der herved opnås.
$ns 1,4,8.2.1.De foretagne målinger.$
$np$
Målingerne i logfilen er foretaget ved hjælp af to programmer OPSTAT
og KTASSTAT, de findes beskrevet i afsnit 5. Ved kørsler med programmet KTASSTAThar været en del problemer som skyldes følgende:
$nl$
Logfilen til RC8000 kan indeholde information for enten 3 eller en maskine. Når logfilen
gennemløbes er det ikke muligt at se på hvilken måde logfilen er dannet. Den
normale af logfilen er, at den indeholder transaktioner fra 3 maskiner. En sådan
logfil kan kun anvendes meget lidt ved denne vurdering. Dette
skyldes, at evalueringen bl.a. skal undersøge, hvordan RC8000 opfører sig, når
belastningen øges. I en logfil med transaktioner fra 3 maskiner kan det ses
på hvilken maskine transaktionen er udført. Da transaktionerne ikke fordeles ligeligt
mellem de 3 RC8000 vil belastningen for hver maskine således være forskellig.
Når en RC8000 undersøges, benyttes derfor kun oplysninger dannet fra transaktionerne
på en maskine.
$np$
Begrundelsen for, hvorfor fordelingen af transaktioner ikke sker, således at hver
RC8000 modtager lige mange forespørgsler er angivet i afsnit 3.
$np$
Den efterfølgende vurdering bygger på 6 kørsler med KTASSTAT foretaget på en logfil med en maskines transaktioner, 1 kæørsel med KTASSTAT og en OPSTAT på en logfil
med 3 maskiners transaktioner. De 6 første kørsler er fra mandag den 23.03.81-fredag den 27.03.81 og mandag den 30.03.81. De 2 sidste kørsler er fra fredag den 24.04.81.
$np$
Kørslerne fra logfilen med 3 maskiners transaktioner benyttes til at beskrive antallet af forespørgslers fordeling i timer af døgnet, og til at finde,
hvordan svartiden er for de forskellige forespørgselstyper.
$np$
De 6 kørsler anvendes til at beskrive en RC8000 opførsels afhængighed af belastningen.
Det bemærkes, at ikke alle disse kørsler er fuldstændige. Ved nogle kørsler
findes timer, hvor ingen forespørgsler er registeret. Dette skyldes, at den
RC8000 logfilen bygger på, har været ude af funktion i pågældende time.
$ns 1,4,8.2.2.Belastningen af en RC8000 til OP-systemet.$
$np$
I afsnit 5.2 er beskrevet, hvordan belastningen til en RC8000 betragtes. Opsummerende
kan her anføres, at belastningen består af et antal forespørgsler og disse
forespørgslers karakteristika. Forespørgslernes karakteristika beskrives
dels ved deres vej gennem systemet og dels ved deres CPU-forbrug. En forespørgsels
vej gennem systemet er en måde at angive forespørgselstype.
$np$
Nedenstående analyse af belastningen opdeles på ækvivalent måde, dvs. først
betragtes, hvormange forespørgsler systemet modtager i løbet af døgnet, og derefter
beskives forespørgslernes art og tidsforbrug.
$np$
Figur 8.2.1 viser et histogram over forespørgslernes antal fordelt på et døgn.
Ud af X-aksen er angivet klokkeslet i døgnet, og Y-aksen angiver antallet af forespørgsler.
Eksempelvis kan ses, at mellem kl. 10.00-11.00 er ankommet 13107 forespørgsler.
Figuren bygger på KTASSTAT fra den 24.04.81.
$np$
Figuren viser, at aktiviteterne til OP-systemet i nattetimerne (23.00-7.00) er særdeles begrænset. Her ankommer aldrig mere end 500 forespørgsler i timen. Aktiviteterne dag- og aftentimerne er derimod mere hyppig. Kurven viser, at
den hårdest belastede time (eng. Peak-time) er mellem kl.10.00-11.00, hvor
der til OP-systemet sendes 13107 forespørgsler. Dette svarer til, at hver tasteoperatør
i gennemsnit afsneder en forespørgsel for hver 35 sekund. Når en person ringer
til telefonnummeroplysningen giver dette i gennemsnit anledning til 2.5 forespørgsler. Dvs. telefonnummeroplysningen i den mest belastede time behandler 4369
spørgsmål.
$np$
Kurven figur 8.2.1 viser endvidere at belastningen af systemet er størst i
tidsrummet mellem 9-16. I denne periode sker et lille fald i aktiviteterne
omkring forkost (12-13). Dette er ikke så tydeligt på figuren, men det vides
fra KTAS's egne statistikker at det normalt er mere udpræget.
$np$
OP-systemets RC8000-dels reaktionsevne på dette antal forespørgsler afhænger nu udover antallet af forespørgslers art. Til betragtning af deres art beregnes en overgangssandsynlighedsmatrix se afsnit 5.2.1. Matricen, som er fundet ud fra samtlige
forespørgsler (129185) den.24.04.81. har følgende udseende:
$sj$

input søge opslag output

input 0 0.66 0.21 0.13

søge 0 0 0.52 0.48

opslag 0 0 0 1

output 0 0 0 0
$rj$$nl$
Matricen skal nu opfattes på følgende måde: Rækkeindeks angiver fra hvilken proces
forespørgslen afsendes, og søjleindekset angiver, hvilken proces forspørgslen
modtages af.
$np$
Dvs. der har været 66 % søgeforespørgsler, hvoraf 58 % er gennemførte og
42 % afviste. Matricens afhængighed af antallet af forespørgsler pr time,
kan findes. Det viser sig, at matricen er særdeles konstant, hvilket egentlig
også kunne forventes. Spredningen for tallene i matricen er meget lille. Hvis
matricen beregnes for hver time i døgnet findes at spedningen er følgende:
$sj$

input -> søge 0.04
input ->opslag 0.04
input ->output 0.04
søge ->opslag 0.03
søge ->output 0.03
$rj$
At den maksimale spedning er 0.04 skyldes, at matricen for timer med mindre end
1000 forespørgsler variere en del. Hvis spedningen beregnes svarende til timer,
hvor antallet af forespørgsler er mere end 1000, så findes den maksimale spedning
til 0.016. Her bygger spedningen på 99.1 % af døgnets forespørgsler. Timerne
hvor antallet af forespørgsler er mindre end 1000 udgør således en meget lille
del af samtlige forespørgsler.
$np$
Konkluderende kan således siges, at forespørgselsmønsteret ikke afhænger af tidspunktet på dagen, og det er særdeles konstant.
$np$
Udover forespørgslernes art er den sidste faktor, der har indflydelse på belastningen
af en RC8000, forespørgslernes ressourcekrav. Nedenstående vil først belyse deres CPU-tidskrav i de enkelte processer, og derefter vil ressourcekrav
til ydre enheder blive belyst.
$np$
Det gennemsnitlige CPU-tidskrav for en forespørgsel kan findes direkte fra logfilen.
For de fire processer er den gennemsnitlige CPU-tid følgende:
$sj$

CPU-tid i inputproces = 16.3 spredning = 5.51
CPU-tid i søgeproces =179.74 spredning = 300.46
CPU-tid i opslagproces = 68.08 spredning = 103.38
CPU-tid i outputproces = 9.05 spredning = 6.23
$rj$$nl$
Det ses, at søgeprocessen benytter mest CPU-tid. CPU-tiden i input- og
outputprocessen udgør en lille procentdel af den samlede svartid ( hhv. 2.8 og
1.6 %).
$np$
Da der er særdeles stor spedning på CPU-tiden betragtes nøjere, hvordan CPU-tiden fordeler sig. Figur 8.2.2 viser, hvordan fordelingen af cpu-tiden er i input-
og outputprocessen.
$np$
Fordelingen er fundet ved at optælle antallet af forespørgsler, hvis
CPU-tid er i et interval eks. 10-11 ms. På figuren angives ud af
X-aksen CPU-tiden og ud af Y-aksen anføres snadsynligheden for at
forespørgslens CPU-tid befinder sig i intervallet. Kurven viser
således fordelingsfunktionen fo CPU-tiden.
$np$
Kurven for inputprocessen viser, at de fleste forespørgsler har et
ret konstant CPU-forbrug. Således har 84.9 % af samtlige forespørgsler
en CPU-tid mellem 12 og 19 ms. Dette kendetegnes også ved, at der for
CPU-tiden i inputprocessen er en lille spredning.
$np$
Kurven for CPU-tiden i outputprocessen viser næsten samme billede. Her har
79.1 % af samtlige forespørgsler en CPU-tid mellem 5-10 ms. Det
bemærkes, at punktet i cirklen på kurven for outputprocessen stammer fra forespørgsler, hvis CPU-tid er større end 14 ms.
$np$
For søge- og opslagprocesserne findes kurverne på figur 8.2.3. Kurven for
CPU-tiden i søgeprocessen ligger tæt på eksponentialfordelingen med samme
middelværdi(179.74). Denne er på figuren angivet som en stiblet linie.
Ud fra kurven kan ses, at 70.7 % af samtlige forespørgsler har en CPU-tid mellemUd fra kurven kan ses, at 70.7 % af samtlige forespørgsler har en CPU-tid mindre end 180 ms. Det mest iøjnefaldende for kurven er at den har et faldende
forløb, og ikke afspejler at søgeprocessen behandler forskellige forespørgselstyper.
$np$
Kurven svarende til CPU-tiden for opslagprocessen viser ligeledes, at den ligger tæt
op ad eksponentialfordelingen. Dette kan undre en del, da opslagprocessen
både behandler gennemførte søgeforespørgsler og tlfnrforspørgsler. Disse to
forespørgselstyper adskiller sig ved, at tlfnrforspørgsler maksimalt kun har en kandidat og
gennemførte søgeforespørgsler i gennemsnit har 7.5 kandidater. Man kunne
derfor forvente, at kurven for CPU-tiden ville have
to toppunkter svarende til de to forespørgselstyper.
$np$
En samlet vurdering af CPU-forbruget er, at fordelingen af CPU-tiden i de enkelte
processer ikke viser, at de forskellige forespørgselstyper adskiller sig i
et specielt CPU-forbrug.
I resten af vurderingen, hvor nogle præstationsindeks afhængighed af belastningen betragtes, vil belastningen blive angivet ved antallet af førespørgsler pr time. Dette gøres, fordi det er eneste størrelse i belastningen, der direkte ændres.
Figur 8.2.4 viser en kurve over det gennemsnitlige CPU-forbrug for en forespørgsel. Ud af X-aksen er angivet antallet af forespørgsler pr time, og Y-aksen
angiver den samlede CPU-tid for en forespørgsel. (summen af CPU-tiden i de 4 processer.)
Kurven er fremkommet ved at samle antallet af timer, hvor antallet af
forespørgsler er mellem 0-500, 500-1000 ovs. Ud fra disse timer findes, så
først det gennemsnitlige antal forespørgsler og derefter findes den gennemsnitlige CPU-tid. Figuren er tegnet på grundlag af KTASSTAT fra den 23.03 og 24.03.
Grunden til at kruven ikke er tegnet for hver proces er, at de viser same billede som på figuren. Punktet svarende til et gennemsnit på 70.3 forespørgsler pr time
er noget misvisende, idet variationen på målingerne her er særdeles stor. De
ligger i intervallet 176.0 - 588.2 ms.
$np$
Figuren viser, at der er særdeles stor variation i CPU-tiden. Derudover ses,
at CPU-tiden ikke afhænger af antallet af forespørgsler. Dette er således en
yderligere begrundelse for,
at når præstationsindeks afhængighed af belastningen betragtes,
angiver antallet af forespørgsler pr time et præcist mål
for belastningen.
Udover en forespørgsels CPU-tid hører til deres ressourcekrav også, hvormange
pladelagertilgange de anvender. Denne størrelse er dog ikke målelig i logfilen.
I afsnit 3.7 er dog angivet en metode, hvor antallet af pladelagertilgang kan
findes. For søgeprocessen er dette fundet til 13.9 og for opslagprocessen er
det 5.2. Det er ikke muligt at angive, hvor stor spedning der er på disse
tal.
$np$
Konkluderende om belastningen kan nu på baggrund af ovenstående anføres. Forespørgslernes art
er uafhængig af, hvormange forespørgsler, der modtages. Input- og outputprocessen er
de forespørgsler der benytter mindst CPU-tid. Søgeprocessen benytter mest CPU-tid. Den procentvise fordeling af CPU-tiden er input = 6 %, søge = 65.8 %, opslag = 24.9 % og output = 3.3 %. Når belastningen af systemet betragtes i det følgende,
vil den blive kvantificeret som antallet af forespørgsler snkommende i en time.
$ns 1,4,8.2.2.Præstationsindices afhængighed af belastningen.$
$np$
Først betragtes den gennemsnitlige svartids afhængighed af belastningen.
Derefter bliver den gennemsnitlige svartid opdelt, således at tidsforbruget
i de enkelte processer anskueliggøres.
$np$
Figur 8.2.4 viser, hvordan svartiden afhænger af antallet af forespørgsler.
Kurven er konstrueret på grundlag at samtlige kørsler med KTASSTAT på en maskine.
For ikke at få et uoverskueligt antal punkter er observationerne samlet således
at alle timer med et antal forespørgsler på mellem 0-249,250-499,ovs er samlet til et punkt.
Svarende til punktet med mellem 0 og 249 forespørgsler pr time er der særdeles
stor variation, så den gennemsnitlige svartid er her noget misvisende.
$np$
Kurven viser, at den gennemsnitlige svartid stiger i forhold til antallet af
forespørgsler. Ved lave belastninger er variationen på svartiden stor.
Dette kommer ikke fra at forespørgselstyperne er forskellige ved denne belastning, men må komme fra at antallet af kandidater til forespørgslerne variere meget.
For yderligere at anskuelig gøre, at den svartiden stiger i timer, hvor
antallet af forespørgsler er stort er på figur 8.2.5 angivet, hvordan
svartiden fordeler sig ved to timer. Den ene time svarer til at der er modtaget
1210 forespørgsler. Ved denne belastning besvares 95 % af forespørgslerne
under 1250 ms. Den anden kurve svarer til en belastning på 5733 forespørgsler
i en time. Det ses at her besvares kun 82 % af forespørgslerne under 1250 ms.
$np$
Ved en belastning på over 5000 forespørgsler i en time vil 55 % af forespørgsler besvares indenfor 500 ms. Ved en belastning på under 1500 forespørgsler
besvares 75 % af forespørgslerne under 500 ms. Det er således klart, at
svartiden stiger, når antallet af forespørgsler i en time forøges. Dette
er naturligvis også, hvad der kunne forventes, og det interesante er,
hvilke størrelser i svartiden der stiger kraftigt når belastningen til
systemet øges.
Fra afsnittet om belastningen vides, at CPU-tiden forøges ikke væsentligt.
Der er således to andre størrelser som bør betragtes. Dette er procestiden,
dvs. den tid en forespørgsel befinder sig under behandling i en proces, og
køtiden, den tid en forespørgsel opholder sig i kø til en proces.
$np$
Kurven figur 8.2.6 viser, hvordan procestiden i input- og outputprocessen
forløber når antallet af forespørgsler forøges. På figuren er ud af X-aksen
angivet antallet af forespørgsler pr time og Y-aksen angiver procestiden i ms.
$np$
For begge processer viser kurven et stigende forløb. At procestiden stiger
når antallet af forespørgsler stiger virker ret rimeligt. Når der er
ringe belastning til systemet vil en proces kunne behandle en forespørgsel,
uden at andre processer har nogle forespørgsler at behandle. Når derimod
belastningen øges, vil en anden proces kunne behandle en forespørgsel,
hvis pågældende proces skal anvende ydre enheder. Forøgelsen i
procestiden ved input- og outputprocessen stammer fra at de to andre processer
vil være aktive under behandlingen af en forespørgsel.
$np$
For både input- og outputprocessen gælder at procestiden forøges, men
deres indflydelse på den samlede svartid er stadig ringe. Det bemærkes, at
der ikke til inputprocessen er koblet et pladelager så forøgelsen af procestiden
stammer her kun fra at systemet er multiprogrammeret.
$np$
Da procestiden i input- og outputprocestiden har særdeles ringe indflydelse på
den samlede svartid, er det mere interessant at betragte procestiden i søge- og
opslagsprocessen. Figur 8.2.7 viser således procestiden i hhv. søge- og
opslagprocessen.
$np$
For søgeprocessen viser kurven ikke nogen speciel stigning i forhold til antallet
af forespørgsler. Det første punkt, som ligger langt over de andre punkter
må anses for en statistisk tilfældighed. For opslagprocessen viser
kurven en noget mere udpræget stigende tendens.
$np$
Hele tendensen fra disse kurver er, at processer der benytter lidt CPU-tid
input og output og delvist opslag viser en stigende tendens for procestiden
når antallet af forespørgsler forøges. For søgeprocessen har multiprogrammeringsgraden
ikke samme indflydelse på procestiden. Konklusionen af disse kurver på figur
8.2.6 og 8.2.7 er, at den forholdvis store forøgelse i svartiden ikke
kan forklares ved at procestiden forøges.
$np$
Figur 8.2.7 viser, hvordan køtiden ved søge- og opslagprocessen afhænger af
belastningen. Kurven for køtiden ved søgeprocessen viser klart en stigende tendens. Køtiden bliver ved denne proces en betydende faktor i den gennemnsitlige svartid.
Ved en belastning på 6305 forespørgsler udgør køtiden 44.6 % af svartiden ved søgeprocessen.
Køtiden ved opslagprocessen stiger ligeledes, men tidmæssigt har denne størrelse
ikke så stor indflydelse på svartiden.
$np$
Ved en belastning på 6305 forespørgsler pr time er udnyttelsesgraden af CPU-en på 31.8 %, så det kan undre en hel del at det er nødvendigt at en forespørgse står
så lang tid i kø til en proces. Det burde være muligt at udnytte CPU-en bedre til behandling af forespørgsler. For at kunne komme med nogle forslag til forbedring
af systemet vil udnytelsen af en RC8000 i en hårdt belastet time blive betragtet
nøjere.

En time hvor antallet af forespørgsler er 5733 betragtes nu. Her er udnyttelses af
de 4 processer følgende:
$sj$
input = 2.6 %
søge = 19.0 %
opslag = 6.8 %
output = 1.5 %
$rj$$nl$
For at kunne beregne den totale udnyttelse af CPU-en er det nødvendigt at
finde, hvor stor en del monitoren benyttes. Det ikke vides, hvor lang
tid monitoren er om at skifte mellem 2 processer.
Ved at betragte timer, hvor belastningen en ringe dvs. der kommer under 1000
forespørgsler i en time, er det muligt at angive, hvor lang tid
en forespørgsel er om at skifte mellem to processer. Dette kan ses på køtiden.
Ved en lille belastning skulle forventes, at køtiden er 0, men her må køtiden
kunne opfattes som den tid en forespørgsel er om at skifte mellem to processer.
Der opnås da følgende:
$sj$

køtid ved søge = ca. 4.2 ms
køtid ved opslag= ca. 4.2 ms
køtid ved output= ca. 7.0 ms
$rj$$nl$
Ved at beregne ud fra antallet af forespørgsler ved hver proces, hvor tit
en forespørgsel skifter mellem de enkelte processer fås da at udnyttelsen
af monitoren ved en belastning på 5733 er 1.8 %. Den samlede CPU-udnyttelse
findes derved til 31.7 %. Dette må siges at være særdeles lille i betragtning
af at den gennemsnitlige svartid ved denne belastning er 686.8 ms. Ved en
gennemsnitlig belastning på 2000 forespørgsler pr time er svartiden ca. 430 ms.
$np$
Ved belastningen på 5733 forespørgsler er den minimale svartid 11 ms og den maksimale
er 9.7 s. Derudover besvares 97 % af forespørgslerne under 2.5 s.
$np$
Svarende til denne belastning vil det være interessant at finde udnyttelsen af
de ydre enheder koblet til RC8000. Ud fra at det gennemsnitlige antal
pladelagertilgange ved søgeprocessen i afsnit 3.7 er fundet til 13.9 er
udnyttelsesgraden af søgedisken på 24.1 %.

Dette tal er fundet ud fra at en pladelager tilgang i gennemsnit
benytter 8.3 ms til overførsel af data og 8 ms til positionering
af diskarm. (Hvordan disse størrelser er fundet er beskrevet i afsnit 3.7)
For opslagdisken findes en udnyttelse på 9.0 % og outputdisken udnyttes 0.2 %.
Udnyttelsen af datakanalen er fundet til 16.1 %, dette under forudsætning
af en overførsel tager gennemsnitlig 8.3 ms.
$ns 1,4,8.3.Vurdering af OP-systemet ved hjælp af en simulator.$
$np$
Dette afsnit beskriver de resultater der er opnået i fobindelse
med kørsel med den udviklede simulator. Simulatoren er beskrevet
i en selvstændig opgave, som er vedlagt denne opgave som bilag.
Det kan her opsumeres, at det er lykkedes at gøre simulatoren ret
nøjagtig. Således er der ved en belastning på 2000 forespørgler en
afvigelse på den gennemsnitlige svartid på 0.1 %. Ved 6000 forespørgsler
er afvigelsen på den gennemsnitlie svartid på 4.9 %. Hvis en kurve for
svartiden udvikling når belastningen øges, har det derudover vist sig
at simulatorens resultater for den gennemsnitlige svartid ligger tæt
op ad resultaterne der er opnået ved målinger i logfilen.
$np$
Ud fra målinger i logfilen har det vist sig, at den
maksimale udnyttelsesgrad af en RC8000 er 31.8 %. Dette svarer til en belastning
på 6493 forespørgsler. Svarende til denne belastning findes en gennemsnitlig svartid på 739.5 ms.
I betragtning af den lave udnyttelsesgrad af RC8000 er denne svartid ret stor.
Specielt i forhold til at den gennemsnitlige svartid over et helt døgn er
574.5 ms.(Den 24.04.81) Ved hjælp af simulatoren vil det blive forsøgt afklaret, hvad
baggrunden er for at CPU-en ikke udnyttes bedre. Der er således foretaget en serie kørsler med simulatoren for at afklare, hvordan den gennemsnitlige svartid
afhænger af antallet af forespørgsler pr time. Ved disse kørsler er en RC8000
udsat for væsentlig større belastninger end den vil være ved OP-systemet.
$np$
Svarende til at CPU-tidskravet og antallet af pladelagertilgange er det samme
som ved OP-systemet viser figur 8.3.1, hvordan den gennemsnitlige svartid forøges,
når antallet af forespørgsler i en time forøges. På figuren er antallet af forespørgsler amngivet ud af X-aksen, og den gennemsnitlige svartid er anført op ad Y-aksen.
Kurven viser, at den gennemsnitlige svartid stiger særdeles kraftigt,
når antallet af forespørgsler pr time er over 8000. Således er den gennemsnitlige
svartid svarende til 8000 forespørgsler = 868.9 ms. Når belastningen øges til
10.000 forespørgsler er svartiden 1528.7 ms. Fra dette punkt sker nærmest en eksposiv stigning, idet ved 11.605 forespørgsler pr time er svartiden 58.708.9 ms,
altså 58.7 s.
$np$
Kurvens forløb viser derfor tydeligt, at der findes en lodret asymptote, der
ligger lidt over 12.000 forespørgsler pr time. Det er ikke muligt at undersøge dette
nærmere ved simulatoren, idet ved en belastning på 13.000 forespørgsler upstår
så lange kølængder, at simulatoren ikke kan køre. Dette skyldes, den begrænsede
lagermængde man får tildelt ved kørsler på RECKU.
$np$
Ud fra kurven kan således påstås, at en RC8000 koblet til OP-systemet maksimalt
kan behandle op til 12.000 forespørgsler. Ved denne belastning vil
svartiden i RC8000 være så stor, at det vil være til særdeles stor
irritation for tasteoperatørene.
$np$
Svarende til denne kurve vil det være særdeles interessant, at betragte
belastningen af CPU-en.
Figur 8.3.2 viser, hvordan CPU-udnyttelsen afhænger af antallet af forespørgsler.
Udnyttelsesgraden af CPU-en er fundet ved at summere CPU-udnyttelsen fra de
4 processer, og udnyttelsen af monitoren. Det bør her bemærkes, at udnyttelses
af monitoren er fundet under den forudsætning, at det tager 1.5 ms at skifte mellem
to processer. Det viste sig at med denne skiftetid blev resultaterne fra simulatoren
mest nøjagtig. Det bør her anføres, at det ud fra målinger i logfilen ved meget
små belastninger kan ses at når en forespørgsler passerer mellem to processer, vil denne skiftetid være større. Antallet af gange en forespørgsel skifter
mellem to processer kan ved en belastning på 5733 findes ttil 12.931. Svarende til
en belastning på 6142 forespørgsler er antallet af processkift i simulatoren målt
til 131.893. Dvs. at antallet af processkift stammende fra, at monitoren skifter
den kørende proces på grund af enten processen ønsker pladelager eller processen
bliver afbrudt af et tidsinterrupt væsentligt større end processkift stammende fra
at en forespørgsel skifter mellem to processer. Det antages derfor at
udnyttelsesgraden ved simulatoren beregnes rigtigt.
$np$
Kurven figur 8.3.2 viser nu ud af X-aksen antallet af forespørgsler og op ad
Y-aksen angives udnyttelsesgraden af CPU-en. Kurven tilnærmer sig en lineær
funktion.
For at finde, hvilken linie der er tale om er den gennemsnitlige CPU-tid
for en forespørgsel samlet for de 4 processer beregnet. Dette er fra den
24.04.81 fundet til 209.8 ms. På figur 8.3.2
er den stiblede linie tegnet ud fra dette CPU-forbrug. Linien er
tegnet ud fra følgende formel:

$sj$
antalforsp * 209.8 ms
______________________
60 * 60 * 1000
$rj$
Svarende til denne linie vil en udnyttelse på 100 % af CPU-en opnås ved
17160 forespørgsler pr time. Det virker dog særdeles rimeligt at en RC8000
ikke kan behandle dette antal, da de indgående kølængder bliver for store.
Med den konstruktion som OP-systemet idag har på en RC8000 kan således påstås
at en udnyttelse på CPU-en på 100 % ikke kan forekomme.
$np$
For at komme med forbedringsforslag til OP-systemet er det nødvendigt at betagte
andre størrelsers afhængighed af belastningen.
Det viser sig, at køtiden ved søgeprocessen har den kraftigste stigning i forbindelse
med at belastningen øges. Figur 8.3.3 viser, hvorledes køtiden ved søgeprocessen
afhænger af belastningen. X-aksen angiver antallet af forespørgsler pr time og
Y-aksen angiver køtiden i ms. Køtiden er ved en belastning på 10048 forespørgsler
1791.2 ms. Dette er større end den gennemsnitlige svartid som ved samme belastning er 1653.4 ms.
Til dette kan anføres, at ikke alle forespørgsler er søgeforespørgsler (kun 66 %), og andre forespørgselstyper vil ikke stå i kø til søgeprocessen. En tlfnrforespørgsel vil ved en tilsvarende belastning kun stå i kø til opslagsprocesen
i 35.5 ms. Det bør dog her påpeges, at simulatoren her ikke så nøjagtig som den
burde. Målinger har vist køtiden ved opslagsprocessen skal være væsentlig
større.
$np$
Til kurven på figur 8.3.3 kan tilføjes, at kølængden ved søgeprocessen stiger tilsvarende. Ved en belastning på 500 forespørgsler er den gennemsnitlige kølængde på 1.8 og ved en belastning
på 11605 forespørgsler er kølængden 199.0. Et forbedringsforslag til systemet vil
på baggrund af de indtil nu anførte kurver skulle være at forbedre søgeproccessen.
$np$
Inden egentlige forbedringsforslag anføres vil det blive beskrevet, hvorledes systemet præcist opfører sig ved en
en belastning på hhv. 6000,8000 og 10.000 forespørgsler pr time.
Tabel 8.3.4 viser de mest betydende størrelser nå belastningen øges.
$sj$
6000 8000 10.000

procestid søge 452.2 ms 460.8 ms 466.9 ms
-"- opslag 176.1 ms 184.9 ms 193.2 ms
køtid søge 318.1 ms 607.3 ms 1791.2 ms
-"- opslag 20.7 ms 26.5 ms 35.5 ms
Udnytg. input 2.78 % 3.66 % 4.55 %
-"- søge 20.42 % 26.93 % 32.49 %
-"- opslag 6.92 % 9.17 % 11.26 %
-"- output 1.54 % 2.03 % 2.53 %
-"- monitor 5.50 % 7.19 % 8.75 %
-"- diskkanal 15.50 % 20.54 % 25.75 %
-"- søgedisk 22.53 % 29.65 % 36.21 %
-"- opslagdisk 7.16 % 9.12 % 11.04 %
-"- outputdisk 0.18 % 0.24 % 0.32 %
-"- CPU 37.16 % 48.99 % 59.75 %

kølængde input 0.043 0.063 0.086
-"- søge 0.862 1.59 4.15
-"- opslag 0.203 0.233 0.380
-"- output 0.025 0.035 0.047
-"- diskkanal 0.160 0.212 0.262

minimal svartid 28.31 ms 28.31 ms 28.31 ms
maksiaml svartid 5137.66 ms 5949.3 ms 12147.3 ms

97 % af forsp. 2249 ms 2999 ms 6750 ms

table 8.3.4
$rj$$nl$
Den sidste linie i tabellen angiver, hvornår 97 % af forespørgslerne er
besvaret.
Når denne tabel sammenlignes med resultater opnået ved målinger i logfilen viser
sig en god overenstemmelse mellem simulatoren og målingerne. Det kan bemærkes,
at udnyttelsen af søge- og opslagdisk er noget mindre end de målte. Dette skyldes
at antallet af diskaccesser ikke helt stemmer overens. Ved simulatoren er der således 12.5
diskaccesser ved søgedisken mod en beregnet størrelse på 13.9. Tabellen viser klart
at når nogle forbedringsforslag skal opstilles bør disse sigte mod at formindske
de størrelser, der har størst stigning når antallet af forespørgsler forøges.
Dvs. køtiden ved søgeprocessen.
Til en RC800 kan stilles nogle forslag som meget let kan implementeres ved en RC8000. Disse forslag går dels ud på at prioritere søgeprocessen højere end de
andre processer og dels ud på at dublere datakanalen.
$np$
Ved at opprioritere søgeprocessen bevirker dette, at hver gang en forespørgsel
findes ved søgeprocessen vil denne blive behandlet. Ved hjælp af simulatoren har det
vist sig, at der ikke opnås nogen væsentlig forbedring af udnyttelsen af en RC800 når søgeprocessen prioriteres højere. Det har endda vist sig at den gennemsnitlige
svartid stiger. At svartiden stiger kan forklares ved at de andre processer ikke
kan behandle forespørgslerne så hurtigt når søgeprocessen har højere prioritet.
Resultaterne fra kørslene er angivet i tabel 8.3.5. De viser at procestiden og køtiden
ved søge processen formindskes lidt, hvorimod køtiden og procestiden ved de andre processer forøges noget. Konkluderende må dog anføres at en prioritering
af søgeprocessen ikke bevirker at systemet opførsel bliver bedre.
$sj$
4000 4000 6000 60000
uden prio. med prio. uden prio. med prio.
procestid søge 432.8 ms 424.0 ms 452.2 ms 440.3 ms
-"- opslag 165.4 ms 171.0 ms 176.1 ms 184.9 ms
Køtid søge 130.8 ms 128.6 ms 318.1 ms 254.1 ms
-"- opslag 12.5 ms 14.4 ms 20.7 ms 24.4 ms
gnst. svartid 516.5 ms 519.7 ms 657.8 ms 620.2 ms
Udnytg. 24.0 % 24.5 % 37.2 % 36.7 %

tabel 8.3.5

$rj$$nl$

$np$
Et andet forbedringsforslag, som specielt har interesse hos KTAS er at
dublere datakanalen. Dette skyldes at man ved KTAS har en ekstra datakanal
til rådighed og meget let vil kunne installere denne. Ved en belastning på
4000 og 6000 forespørgsler pr time er resultaterne fra kørsler med en dubleret
datakan vis i tabel 8.3.6.

$sj$
4000 4000 6000 6000
uden dub. med dub. uden dub. med dub.

procestid søge 432.8 ms 427.1 ms 452.2 ms 448.5 ms
-"- opslag 165.4 ms 166.8 ms 176.1 ms 174.6 ms

køtid søge 130.8 ms 134.5 ms 318.1 ms 307.6 ms
-"- opslag 12.5 ms 11.2 ms 20.7 ms 18.8 ms

gnst svartid 516.5 ms 504.8 ms 657.8 ms 646.1 ms

Udnytg.diskkan1. 7.64 % 11.73 %
Udnytg.diskkan2. 2.59 % 3.86 %
Udnytg.diskkanal 10.21 % 15.59 %
Udnytg. CPU 23.93 % 24.06 % 37.16 % 37.39 %
$rj$
$nl$
Dubleringen af datakanalen er foretaget således at søgedisken er koblet
til den ene kanal og opslag- og outputdisken er koblet til den anden kanal.
Resultaterne viser, at gevinsten ved at have to datakanler er særdeles lille.
Den gennemsnitlige svartid formindskes lidt, ved at procestiden ved søgeprocessen formindskes lidt.
Det må dog siges at den forbedring der opnås er for lille til at det vil være umagen værd
at dublere datakanalen. Intuitivt er det også klart at en dublering af datakanalen ikke
vil give den helt store forbedring.
Dette skyldes, at datakanalen ikke er udnyttet i mere end ca
1/3 af tiden ved en stor belastning. Dermed vil der ikke ske en
forsinkelse af en forespørgsel ved at den står i kø til datanalen.
For at komme med et forslag,
der virkelig forbedre systemet,
er det nødvendigt at betragte,
hvordan tiden forløber i søgeprocessen.
På figur 8.3.7 er angivet et tidsdiagram
over, hvordan tiden forløber i en RC8000.
Til figuren er foretaget en del begrænsinger. Det
antages at den gennemsnitlige CPU-tid i søgeprocessen er 180 ms, og at der er
14 pladelagertilgange i søgeprocessen.
Mellem to pladelagertilgange er så 180:15 =12 ms.
En pladelagertilgang antages at tage 18 ms,
fordelt med 10 ms til positioneringstid og
8 ms til overførsel af data.
$np$
Hvis nu søgeprocessen var den eneste proces, der benyttede CPU-en ville
den maksimale udnyttelse være 41.6 %. (180 ms ud af 180+252=432 ms).
Med andre ord venter CPU-en i 58.4 % af tiden på en pladelagertilgang er
færdig.
Ved at programmere OP-systemet i form af 4 processor er det muligt at udnytte nogle
af disse 58.4 % til behandling af forespørgsler ved de andre processer. Hvis det
antages,
at en forespørgsel benytter 66 ms ved opslagprocessen, og systemet behandler en forespørgsel
ved opslagprocessen hver gang en forespørgsel behandles ved søgeprocessen så
når man op på en udnyttelse af CPU-en på 56.9 %. Hvis det derudover antages,
at input- og outputprocessen også behandler en forespørgsel indenfor tidsrummet
og de benytter hhv 16 og 9 ms, så opnås en CPU-udnyttelse på 62.7 %.
$np$
En forøgelse af udnyttelse af CPU-en kan nu kun foregå ved at opslagprocessen
behandler en tlfnrforespørgsel. Hvis det antages at den bruger 66 ms i opslagprocessen,
og hhv. 16 og 9 i input- og outputprocessen så opnås en maksimal udnyttelse
på 83.8 %. Dvs. den maksimale udnyttelse af CPU-en fra OP-systemet er omkring
83.8 %.
$np$
Det er ikke muligt at en så stor udnyttelse kan foregå over en længere periode,
idet dette kræver at der kommer lige så mange tlfnrforespørgsler som søgeforespørgsler.
$ns 1,4,8.3.2.Dublering af søgeproces.$
$np$
En drastisk forøgelse af udnyttelsen af CPU-en vil forekomme ved
at søgeprocessen behandler mere end en forespørgsel ad gangen. At
implementere at søgeprocessen skal kunne behandle mere end en forespørgsel
ad gangen vil formentlig være lettes ved at dublere søgeprocessen. Hver
søgeproces kan så behandle en forespørgsel på samme tid.
$np$
Ved en dublering af søgeprocessen er det naturligt, at der kun opnås
en fordel, når belastningen af systemet er over et vist punkt.
Svarende til en belastning på ca. 6000 forespørgsler pr time formindskes
den gennemsnitlige svartid fra 657.8 ms til 542.5 ms ved en dublering
af søgeprocessen.
$np$
Figur 8.3.8 viser, hvordan svartiden (angivet ud af Y-aksen) er en funktion
af antallet af forespørgsler(angivet ud af X-aksen). Kurven viser ikke en
så stejl stigning ved foreøgelse af belastningen som uden dublering af søgeprocessen.
Når OP-systemet betragtes ved en belastning på 6000 forespørgsler vides,
fra målinger i logfilen at 97 % af samlige forespørgsler besvares under 2 s.
Ved en dublering af søgeprocessen vil 97 % af forespørgslerne kunne besvares
under 2 s ved en belastning på 7959 forespørgsler.
Ved denne belastning vil den gennemsnitlige svartid være 663.2 ms.
$np$
Da der til OP-systemet i meget belastede timer anvendes 3 RC8000, svarende til
at de 3 maskiner behandler ca 13.000 forespørgsler. Forespørgslerne
fordeles således at en RC8000 modtager omkring 6000 forespørgsler, og dette
bevirker en svartid der lige kan accepteres. Ved at dublere søgeprocessen vil det være
muligt med 2 RC8000 at behandle samme antal forespørgsler under samme betingelser
som forespørgslerne idag behandles med 3 maskiner.
$np$
Ved dubleringen af søgeprocessen viste det sig at udnyttelsen af søgedisken
blev ret stor. Det blev derfor fundet interessant at foretage kørsler, hvor
både søgeprocessen og datakanalen blev dubleret. Dette viste dog ikke at
den gennemsnitlige svartid herved kunne forbedres væsentligt.
Resultaterne er angivet i tabel 8.3.9.
$sj$

gennemsnitl svartid
Dublering af søge. Dublering af søge og diskkanal.
Ved ca.8000 forsp 665.2 ms 615.9 ms

Ved ca.10.000 forsp 822.1 ms 800.5 ms

Ved ca.12.000 forsp 1136.5 ms 1082.7 ms

tabel 8.3.9

$rj$$nl$
En nærmere undersøgelse af denne konstellation er ikke foretaget, idet
tidsgevinsten ikke er fundet stor nok.
$np$
Da søgeprocessen er den proces, der optager mest plad i RC8000, vil det
formentlig være en ret kostbar affære at dublere søgeprocessen. Det kræver
udover en programændring en udvidelse af lageret koblet til en RC8000. Et
andet forslag til forbedring af OP-systemets RC8000- del kan så gives
ud fra et dybere kendskab til søgeprocessen.
$np$
Søgeprocessen fungerer således at den ud fra hvert kriterie i en søgeforespørgsel
danner en mængde af kandidater. Til sidst for at finde eventuelle kandidater til
forespørgslen dannes så fællesmængden af disse kandidater.
$np$
I stedet for at dublere søgeprocessen kunne en opdeling af søgeprocessen foretages.
Dette kunne gøres ved at lave en proces som fremfandt kandidaterne svarende til
stednavnet. Stednavnet skal altid være med i en søgeforespørgsel. Hvis
der findes kandidater svarende til dette stednavn, så videresendes disse
kandidater til en anden søgeproces som behandler resten af søgekriterierne.
Ved dette vil næsten samme effekt opnås som ved en dublering af søgeprocessen.
Det væsentlige ved dette forslag er, at det bliver muligt at behandle mere
end en forespørgsel ved søgeprocessen.
$np$
Man kunne tænke sig en endnu større gevinst, hvis en yderlige opdeling af
søgeprocessen blev foretaget. Det er dog ikke oplagt at gøre dette
idet der er særdeles stor variation i de restende søgekriterier.
$np$
Det bør her anføres, at de ovenfor anførte overvejelser ikke er afprøvet
ved simulatoren, idet dette desværre kræver ret store ændringer i simulatoren.
$ns 1,4,8.3.3.Indførelse af hurtigere RC8000.$
$np$
Af de nævnte forbedringsforslag kan et sidste anføres, og det vil formentlig
også være det billigste. Efter konstruktionen af OP-systemet har RC udviklet
en hurtigere RC800. Denne RC8000 betegnes model 55. Forskellen fra den ved
OP-systemet benyttede RC8000 er at der til denne findes et "cache" lager. Dette
bevirker, at maskinen bliver dobbelt så hurtig. Anskaffelsesprisen for en
sådan maskine er ikke savrende til en ny, fordi det kun er nødvendigt
at anskaffe et "cache" lager.
$np$
Det har vist sig at en model 55 er omkring dobbelt så hurtig som den nu anvendte
RC8000. Ved at halvere tidsforbruget ved de enkelte processer og monitorskiftetiden
er der nu foretaget en række simulationskørsler.
$np$
Figur 8.3.10 viser, hvordan svartiden udvikler sig når antallet
af forespørgsler forøges.
$ns 1,4,8.4.Teoretisk analyse af systemet.$
$np$
Nedenstående afsnit beskriver 2 normalt anvendte metoder til teoreisk analyse
af et datamatisk system. Den første tager udgangspunkt i at finde antallet
af terminaler, der kan kobles til systemet. Den anden angiver en metode, hvordan
en
flaskehals ved et system kan findes.
$nl2$
1.Vurdering af terminal system.
$nl$
En model svarende til nedenstående figur betragtes.
Systemet består af n terminaler og en CPU. Ved terminalerne sendes et job (forespørgsel).

Tiden mellem to forespørgsler er en variabel størrelse og betegnes tænketiden.
Dvs. en person ved en terminal tænker et vist
stykke tid, når svaret på en sendt forespørgsel er modtaget
inden næste transaktion sendes.
$nl15$
$sj$
figur 8.4.1
$rj$
Det forudsættes, at tænketiden er eksponetial fordelt med middelværdi
1/^^.
En anden størrelse som skal kendes ved denne model
er den gennemsnitlige behandlingstid for et
job under forudsætning af,
at dette job befinder sig alene ved CPU-en. Behandlingstiden forudsættes ligeledes eksponentialfordelt med middelværdi 1/^^.
Under disse forudsætninger kan det vises, at svartiden er en funktion af antallet
af terminaler, og dens forløb vil være som vist på nedenstående figur.
Ud af X-aksen er angivet antallet af terminaler og Y-aksen angiver den
gennemsnitlige svartid.
$nl15$
$sj$
figur 8.4.2
$rj$
$nl$
Kurven på figuren vil have to asymptoter en vandret og en skrå, og skæringspunktet
mellem disse asymptoter
betegnes systemets mætningspunkt. Dette mætningspunkt kan findes ud fra følgende
formel:
$nl3$
$nl$
Mætningspunktet skal ses som en angivelse af det største antal terminaler
der kan kobles til systemet. Hvis
et større antal kobles til, vil svartiden stige uforholdsmæssigt meget.
Ovenfor anførte betragtninger findes
i Brin 73 side 214-221 og Ferr78 side 210-212.
Her findes ligeledes beskrevet,
hvordan man kommer frem til formlen for mætningspunktet.
$np$
Denne model vil nu blive anvendt til at finde mætningspunktet for en RC8000 ved OP-systemet.
De to indgående størrelser findes efter følgende princip:
$nl2$
1.Gennemsnitlig behandlingstid.
$nl$
Denne størrelse skal findes under forudsætning af, at en forespørgsel befinder
sig alene i RC8000. Til dette findes fra KTASSTAT den time,
der har været mindst
belastning. Ved en belastning på 22 forespørgsler er den gennemsnitlige svartid
i RC8000 501.3 ms.
$nl2$
2.Gennemsnitlig tænketid.
$nl$
Antallet af terminaler koblet til systemet i en hårdt belastet time er 130, og den
hårdest belastede time svarer til,
at der afsendes 13107 forespørgsler. Ud fra dette
kan den gennemsnitlige tænketid pr sekund beregnes til:
$sj$
130*60*60
= _________ = 35.7
13107

$rj$
Ud fra dette beregnes mætningspunktet for en RC8000 til :
$sj$
* 35.70
N = 1 + ______ = 72 terminaler.
0.5013
$rj$
Ud fra disse betragtninger kan anføres, at de 3 RC8000 koblet til OP-systemet
kan klare 213 terminaler. Ved at koble 213 terminaler til systemet vil antallet
af forespørgsler pr time være 21479. Antallet af forespørgsler en RC8000 skal behandle
pr time vil så under forudsætning af, at forespørgslerne fordeles ligeligt være
7159.7 pr time. Med denne belastning vides fra simulatoren, at den gennensnitlige
svartid er 787.3 ms.
$nl2$
2.Kømodeller.
$np$
Det anføres her ud fra en teoretisk model, hvordan en flaskehals til systemet
kan findes. For at kunne gøre dette betragtes en kønetværksmodel af
systemet. Kømodellen er angivet på figur 8.4.3.
Den findes beskrevet i Buz71.
$nl15$
$sj$
figur 8.4.3
$rj$
Systemet har 1 CPU og L ydre enheder.
I forbindelse med anvendelsen her er L = 3, og de ydre enheder er hhv. søge- , opslag- og outputdisk. Til
modellen anføres nogle sandsynligheder p0,...,pL. pi angiver sandsynligheden
for at et job, når det er færdigt ved CPU-en skal behandles ved enhed i.
po angiver, at et job er færdigt ved CPU-en., og igen skal behandles ved CPU-en.
$np$
Et job består således af en række forløb bestående af
et CPU-tidsinterval efterfulgt af en behandling ved en ydre enhed.
Når jobbet efter en CPU-behandling igen ønsker et CPU-tidsinterval er
jobbet færdigt, og angivelsen for at jobbet igen ønsker CPU-en kan opfattes
som et nyt job, der ankommer til systemet.

Summen af pi'erne er 1.
$np$
Der er både til CPU-en og de ydre enheder knyttet en kø. Det antages, at antallet
af job, der befinder sig i systemet er konstant, og det betegnes N.
$np$
Behandlingstiden ved de indgående enheder antages at være eksponentialfordelt med
middelværdi ui. Den gennemsnitlige behandlingstid ved enhed i er så 1/ui.
$np$
Inden en flaskehals defineres vil en række
ting blive fremhævet.
$np$
Med Ai betegnes sandsynligheden for, at enhed i er aktiv.
Dvs. at Ai kan opfattes,
som den del af observationsperioden, hvor enheden er optaget.
Ao er sandsynligheden for, at CPU-en er optaget.
$np$
Man er interesseret i at beregne det forventede antal job, der færdiggøres
over en tidsperiode af længden T. CPU-en vil her være optaget i Ao*T.
$np$
Et job afvikles ved CPU-en i et antal tidsintervaller. Det gennemsnitlige
antal CPU-tidsintervaller pr job er 1/po, fordi sandsynligheden for at
et program vil afslutte efter et CPU-tidsinterval er po. Den gennemsnitlige
behandlingstid for et CPU-tidsinterval er 1/uo. Dvs. at et job i gennemsnit
benytter CPU-en i 1/uo*1/po= 1/uopo.
$np$
Dermed kan det gennemsnitlige antal afviklede job over tidsperioden T findes til
$sj$

Ao*T*uopo
$rj$$nl$
Dermed vil afviklingen pr tidsenhed være
$sj$
(1) Ao*uo*po
$rj$$nl$
Hvert jobs sandsynlighed for at modtage behandling
ved enhed i er pi. Da Ao angiver sandsynligheden for, at CPU-en er optaget, og
1/uo angiver den gennemsnitlige behandlingstid pr job ved CPU-en, vil
Ao*uo være et mål for, hvor tit et job er færdig med et CPU-tidsinterval.
Det forventede antal job, som skal behandles ved enhed i er derfor
$sj$
Ao*uo*pi
$rj$
$np$
Omvendt er Ai sandsynligheden for, at enhed i er aktiv og ui er behandlingsraten
ved enhed i.

Dvs. Ai*ui er antallet af job afviklet ved enhed i. Da antallet af job afviklet ved
enhed i er det samme som antallet af ankommende job til enhed i, så gælder
$sj$
Ao*uo*pi = Ai*ui
og dermed
Ao*uo = Aiui/pi.
$rj$$nl$
Systemets gennemstrømning defineres som det gennemsnitlige antal job,
der færdiggøres pr tidsenhed.
Et udtryk for gennemstrømningen kan nu opstilles ved brug af (1).
Derved fås
$sj$

Ao*uo*po = Ai*ui*po / pi
$rj$$nl$
En flaskehals defineres i Buz71 som den enhed i systemet, der bevirker en alvorlig
formindskelse i systemets ydeevne. Denne definition kan nu omformuleres til:
$nl$
Hvis en lille forøgelse i en enheds gennemstrømning bevirker en stor forøgelse
i systemets gennemstrømning, så er pågældende enhed en flaskehals.
$np$
Hele systemets gennemstrømning er Ao*uo*po og enhed i skaber en derfor en flaskehals,
hvis
^(Ao*uo*po)/^^ui er stor. Når en flaskehals skal findes skal den maksimale af
disse partielle afledede findes.
Ao er en funktion af uo,u1,...,uL,po,p1,...,pL, og N. Når de partielle
afledede skal findes ved denne model, vil Ao,...,A3 angives ud
fra resultater opnået ved simulatoren.
$nl2$
De indgående størrelser findes ved en belastning på
8000 forespørgsler pr time til:
$sj$

Ao = udnyttelsesgraden af CPU-en = 0.418

A1 = udnyttelsesgraden af søgedisk = 0.297

A2 = udnyttelsesgraden af opslagdisk = 0.0912

A3 = udnyttelsesgraden af outputdisk = 0.0024
$rj$$nl$
Derudover kendes det totale antal processkift og pladelagertilgange. Man
får da
$sj$
T*Ao*uo = antal processkift = 172622
og dermed er uo = 0.117

T*A1*u1 = antal søgediskaccesser = 67015
og dermed er u1 = 0.062

T*A2*u2 = antal opslagdiskaccesser = 21618
og dermed er u2 = 0.066

T*A3*u3 = antal outputdiskaccesser = 550
og dermed er u3 = 0.064
$rj$
Ud fra antallet af processkift kan de indgående sandsynligheder findes
og de bliver:
$sj$

po= 0.659

p1= 0.256

p2= 0.083

p3= 0.0021
$rj$
Ud fra disse størrelser kan de partielle afledede findes, og der opnås nu :
$sj$
Ao*po/ po = 0.418

A1*po/ p1 = 0.765

A2*po/ p2 = 0.724

A3*po/ p3 = 0.752
$rj$
Ud fra disse værdier af de parielle afledede er det ikke indlysende,
hvilken enhed,
der er flaskehalsen. Dette skyldes, at de indgående sandsynligheder
ikke er uafhængige.
Ved OP-systemet foregår behandlingen af forespørgsler ved en speciel rækkefølge
således at forespørgslen først behandles ved input så søge ovs.
Dette er grunden til,
at de partielle afledede ved de tre diske er næsten ens.
$np$ Imidlertid har målinger
vist, at en forøgelse i søgediskens hastighed bevirker en formindskelse i
den gennemsnitlige svartid jvf. tabel 8.4.4.
Tabellen er opnået ved at formindske behandlingshastigheden ved søgedisken
med 25 %.
$sj$
Normal søgedisk Hurtig søgedisk
4000 6000 8000 4000 6000 8000
Procestid søge 432.8 452.2 460.8 382.5 395.5 406.9
-"- opsl. 165.4 176.1 184.9 168.7 176.6 185.6
Køtid søge 130.8 318.1 607.3 94.9 218.2 386.2
-"- opsl. 12.5 20.7 26.5 11.3 18.6 26.0
Gnstl.svartid 516.5 657.8 868.9 451.7 552.3 684.5
CPU-udng. 24.0% 37.2% 49.0% 23.4% 36.4% 47.8%

tabel 8.4.4

$rj$
Tabellen viser,
at den gennemsnitlige svartid formindskes
ved en hurtigere søgedisk. Dette sker ved at proces- og køtiden
i søgeprocessen
formindskes. Det bemærkes, at udnyttelses af CPU-en ikke stiger.
$ef$
scope user vko2
finis
▶EOF◀

DataMuseum.dk

RC4000/8000/9000

⟦b171ee717⟧ TextFile

Derivation

TextFile