⟦2c4dd668d⟧

TextFile

mode list.yes
vko2=set 50 disc3
afs=set 50 disc3
scope user afs
scope user vko2
afs=typeset check.no proof.vko2 machine.diablo
*se $* $pl ,30,235,,10$
$lw 160$$ld18$
$ps0$
$nl$
$sb ^,6$
Datalogisk Institut
$nl$
Sigurdsgade 7
$nl$
2100 København Ø
$nl17$
$ct$
Vurdering af et
oplysningssystem.
$nl7$
$qr$
_«bs»A_«bs»f_«bs»l_«bs»e_«bs»v_«bs»e_«bs»r_«bs»e_«bs»t__«bs»a_«bs»f_«bs»:
$nl$
Viggo Nis Kørst
$nl$
$rj$
$pn 5,2$
$rh 1,INDLEDNING$
$ps0$
$ns 1,4,_«bs»1_«bs»._«bs»I_«bs»n_«bs»d_«bs»l_«bs»e_«bs»d_«bs»n_«bs»i_«bs»n_«bs»g_«bs».$
$np$
Dette speciale er indenfor emnet præstationsvurdering. Specialet
tager udgangspunkt i vurderingen af et kørende EDB-system. Systemet
findes ved KTAS, er grundlaget for telefonnummeroplysningen,
og betegnes i det følgende OP-systemet.
Vurderingen foretages ud fra målinger,
ud fra simulering og ud fra teoretiske betragtninger.
$np$
Da det undersøgte OP-system kontinuerligt benyttes, har der været en del begrænsninger
i mulighederne for at måle på systemet. For at
kunne foretage en dyberegående undersøgelse i forbindelse med en
evaluering,
har det været nødvendigt at konstruere en simulator
af systemet.
$np$
De fleste i litteraturen om præstationsvurdering opstillede
teoretiske modeller af datamatiske systemer er ret simple
og svære at anvende. Derfor
har anvendelsen af disse teoretiske modeller fået en mindre central rolle
i forbindelse med vurderingen. Hovedvægten i specialet har således
været at vurdere systemet ud fra målinger og ud fra simulering.
$np$
Dette speciale består af to opgaver. Denne opgave, som
er den vigtigste del indeholder vurderingen, og
en beskrivelse af, hvordan vurderingen er foretaget.
I den anden opgave findes beskrevet, hvorledes simulatoren af systemet
er udviklet, hvad den simulere, og hvor
nøjagtig den er.
Opdelingen af specialet i to opgaver er kun foretaget i forbindelse med afleveringen
på Datalogisk Institut. Denne opgave er udarbejdet af undertegnede, og
opgaven om simulatoren er udarbejdet i samarbejde med Sven Larsen. For at opnå en
fuld forståelse af vurderingen af OP-systemet, er det nødvendigt at have kendskab til
begge opgaver.
$np$
Denne opgave indeholder en introduktion til
præstatonsvurdering.(Afsnit 2) Heri beskrives de gængse termer og udtryk, der
anvendes i litteraturen om vurdering af datamatiske systemer.
Efter dette koncentreres opgaven udelukkende på det foreliggende
system. Afsnit 3 indeholder en systembeskrivelse. Afsnit 4 beskriver baggrunden og
formålet med vurderingen. Derefter beskrives i afsnit 5 de programmer som
udover simulatoren er anvendt til målinger. I afsnit 6
findes selve vurderingen af OP-systemet. Hele denne opgave afsluttes med at give
en kortfattet konklusion af vurderingen, og en beskrivelse af de erfaringer, der er
opnået under løsningen af opgaven.
$np$
På grund af opdelingen af hele analysen af systemet i to opgaver angives
det her, hvordan det største udbytte af opgaverne opnås. En naturlig måde at læse
opgaverne på, er at læse afsnit 1-5 i denne opgave, derefter simulatoropgaven
og til sidst afsnit 6 og 7 i denne opgave.
$np$
Der er anvendt en vekselvirkning mellem en del
termer, som kort skal forklares her. En forspørgsel, en transaktion
og til dels et job er anvendt som betegnelse for et spørgsmål afsendt på
en terminal til oplysningssystemet.
$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$
Afsnittet indeholder først en beskrivelse af, hvad formålet med en præstationsvurdering
er. Derefter beskrives, hvordan evalueringsstudier normalt opdeles, og
hvilke faser de gennemløber. Herefter anføres, hvilke målemetoder man kan anvende.
Afsnittet afsluttes af en beskrivelse af normalt anvendte præstationsindices,
og der gives kort en definition på en flaskehals.
$np$
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.
Nedenstående vil indføre en del termer, der anvendes ved præstationsvurdering.
$np$
Et datamatsik 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 defineres, som mængden af alle job det modtager, dvs. programmer,
data og kommandoer. Dermed afhænger belastningen dels af
hvilket tidspunkt belastningen betragtes og dels af jobs karakteristika.
Til et jobs karakterisktika hører bl.a. hvor lang
tid det skal bruge, 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$
Udover den belastning et system udsættes for
afhænger ydeevnen af de i systemet indgående enheders
karakteristika. Dvs. ydeevnen vil afhænge af både belastnings-
og systemparametre.
Belastnings- 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
belastningen den 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, er således et subjektivt spørgsmål.
Forskellige personer vil benytte forskellige
størrelser (betegnes også indeks) ved en vurdering.
Disse indeks kaldes i det følgende præstationsindeks. Et præstationsindeks
kan så defineres som en størrelse, der benyttes til at beskrive opførslen
eller andre aspekter om systemet.
$np$
En del præstationsindeks er umulige at kvantificere eksempelvis
hvor let benyttes systemet, anvendbarheden af et instruktionssæt 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 kvantificeres 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
behandles 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$
$nl$
$np$
Disse 3 type af præstationsindeks interesserer forskellige personer, og normalt
vil forskellige interessegrupper være interesseret i forskellige indeks.
F.eks. vil en bruger være interesseret i
lave reaktionstiden dvs.
kategori 2.
En driftleder derimod er formentlig mest interesseret i at udnyttelsen
af systemet er så stor som muligt dvs. kategori 1.
$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$
Et sekundært indeks er et præstationsindeks, der bliver
bibragt af evalueringsstudiet. Det anvendes til at finde symptomer på,
at et datamatisk system er ineffektivt. Et eksempel på et sekundært
præstationsindeks er udnyttelsesgraden af centralenheden. I de fleste
tilfælde kan denne ikke måles direkte, men beregnes ud fra antallet af job og
disse jobs CPU-forbrug. En dårlig udnyttelse af centralenheden kan være årsag
til at systemets gennemstrømning er lille.
$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.
$ns 1,4,_«bs»2_«bs»._«bs»2_«bs»._«bs»O_«bs»p_«bs»d_«bs»e_«bs»l_«bs»i_«bs»n_«bs»g_«bs»e_«bs»n__«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».$
$nl$
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 falder indenfor denne kategori.
Ved trimning af et system forstås, at nogle installationsparametre
ændres således at udnyttelsen 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 ved hjælp af en simulator blive illustreret,
hvilke konsekvenser en ændring af systemets design kan have.
$np$
Når et evalueringsstudium
foretages, er det normalt, at man gennemløber følgende 5 faser.
(Se Ferr78 side 10)
$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$
$ns1,4,_«bs»2_«bs»._«bs»3_«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 eksperimentet 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.
Ved et måleredskabs karakteristika forstås, hvilke hændelser kan det måle,
hvor nøjagtigt kan det måle en hændelse, hvilke fejlkilder
findes ved målingerne med redskabet o.s.v.
$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»"
$nl$
Dette er maskinelle dele koblet til systemet f.eks. ved sonder på
forskellige punkter, som ved hjælp af et måleinstrument
eksempelvis et ur, måler tidspunktet for hændelsen.
En sonde 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.
$nl2$
_«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$
$ns 1,4,_«bs»2_«bs»._«bs»4_«bs»._«bs»C_«bs»e_«bs»n_«bs»t_«bs»r_«bs»a_«bs»l_«bs»e__«bs»p_«bs»r_«bs»æ_«bs»s_«bs»t_«bs»a_«bs»t_«bs»i_«bs»o_«bs»n_«bs»s_«bs»i_«bs»n_«bs»d_«bs»e_«bs»k_«bs»s_«bs».$
$np$
Da formålet med et evalueringsstudium har stor indflydelse på, hvilke præstationsindeks
der anvendes,
er det svært at angive nogle
præstationsindeks, som generelt
kan anvendes ved alle evalueringsstudier. Nedenstående angiver hyppigt anvendte
indeks, og i afsnit 4 bliver nøjagtigt præciseret, hvilke indeks, der anvendes ved denne vurdering.
$np$
I afsnit 2.1 er beskrevet at præstationsindeks, der benyttes ved et evalueringsstudium
afhænger af, hvem der betragter systemet. En anden betydende faktor er systemts
art. Her referes til om det er et interaktivt eller et batchsystem.
De nedenstående eksempler på præstationsindeks følger opdelingen fra
afsnit 2.1, så først angives eksempler på belastningsindeks og
derefter systemindeks. Ved den endelige vurdering i denne opgave, vil
der blive lagt stor vægt på at afklare,
hvordan systemindeks afhænger af belastningen.
$nl2$
_«bs»1_«bs»._«bs»B_«bs»e_«bs»l_«bs»a_«bs»s_«bs»t_«bs»n_«bs»i_«bs»n_«bs»g_«bs»s_«bs»i_«bs»n_«bs»d_«bs»e_«bs»k_«bs»s_«bs».
$nl$
Belastningsindeks refererer som før nævnt dels til en beskrivelse
af hvormange og hvordan job ankommer og
dels til hvilke karakteristika disse job har. Eksempler på
belastningsindeks anføres nu i henhold til de to anførte
aspekter.
$nl2$
_«bs»A_«bs»n_«bs»t_«bs»a_«bs»l__«bs»a_«bs»n_«bs»k_«bs»o_«bs»m_«bs»m_«bs»e_«bs»n_«bs»d_«bs»e__«bs»j_«bs»o_«bs»b__«bs»p_«bs»r_«bs».__«bs»t_«bs»i_«bs»m_«bs»e__«bs»o_«bs»g__«bs»i__«bs»h_«bs»e_«bs»l_«bs»e__«bs»o_«bs»b_«bs»s_«bs»e_«bs»r_«bs»v_«bs»a_«bs»t_«bs»i_«bs»o_«bs»n_«bs»s_«bs»p_«bs»e_«bs»r_«bs»i_«bs»o_«bs»d_«bs»e_«bs»n_«bs».
$nl$
Et job er ved et interaktivt system er afsendelsen
af en transaktion. Ved et batchsystem er det en række hulkortbilleder,
dvs. fra et jobkort til et afslutningskort.
Dette indeks er afhængig af tidspunktet i døgnet.
$nl2$
_«bs»A_«bs»n_«bs»k_«bs»o_«bs»m_«bs»s_«bs»t_«bs»h_«bs»a_«bs»s_«bs»t_«bs»i_«bs»g_«bs»h_«bs»e_«bs»d
$nl$
Defineres som antal ankommende job pr. tidsenhed.
$nl$
Ud fra disse to indeks er det muligt at finde spidsbelastningen, og
gennemsnitlige tider mellem ankomsten af job.
$nl$
For et jobs karakteristika kan anføres følgende indeks:
$lm20$
$nl$
CPU-forbrug
$nl$
lagerforbrug
$nl$
ressourcekrav til ydre enheder f.eks. antal plade- og tromletilgange.
$lm0$$nl2$
Ved et interaktivt system betragtes udover de anførte normalt
også antallet af terminaler, og ankomsthastigheden
for transaktioner pr. terminal.
$nl$
Ved et batchsystem betragtes f.eks. et jobs prioritet og antal hulkortbilleder.
$nl$
Samlet kaldes alle de ved et evalueringsstudium anvendte belastningsindeks
for en belastningsmodel. Hvordan den præcise belastningsmodel ser ud
ved dette evalueringsstudium beskrives i afsnit 4.
$nl2$
_«bs»2_«bs»._«bs»S_«bs»y_«bs»s_«bs»t_«bs»e_«bs»m_«bs»i_«bs»n_«bs»d_«bs»e_«bs»k_«bs»s_«bs».
$nl$
Specielt anvendligheden af systemindeks er meget afhængig af om et system
er batch eller interaktivt. De normalt vigtigste systemindeks er
følgende:
$nl2$
_«bs»G_«bs»e_«bs»n_«bs»n_«bs»e_«bs»m_«bs»s_«bs»n_«bs»i_«bs»t_«bs»l_«bs»i_«bs»g__«bs»s_«bs»v_«bs»a_«bs»r_«bs»t_«bs»i_«bs»d__«bs»f_«bs»o_«bs»r__«bs»e_«bs»t__«bs»j_«bs»o_«bs»b
$nl$
Dennes afhængighed af belastningen er interessant. Spørgsmål som
hvormeget forøges svartiden, når belastningen øges siger noget
om systemets evne til at behandle job.
$nl$
$nl$
_«bs»U_«bs»d_«bs»v_«bs»i_«bs»d_«bs»e_«bs»l_«bs»s_«bs»e_«bs»s_«bs»f_«bs»a_«bs»k_«bs»t_«bs»o_«bs»r__«bs»f_«bs»o_«bs»r__«bs»e_«bs»t__«bs»j_«bs»o_«bs»b_«bs».
$nl$
Defineres som svartiden for jobbet divideret med den ideele svartid.
Den ideele svartid er den tid jobbet ville have brugt,
hvis det var alene i systemet.
Denne faktor siger noget om systemets evne til at behandle forskellige
job i forhold til jobbet karakteristika.
$nl$
$nl$
_«bs»G_«bs»e_«bs»n_«bs»n_«bs»e_«bs»m_«bs»s_«bs»t_«bs»ø_«bs»m_«bs»n_«bs»i_«bs»n_«bs»g_
$nl$
Definieres som antallet af job der kan færdigbehandle pr. tidsenhed.
$nl$
$nl$
_«bs»K_«bs»a_«bs»p_«bs»a_«bs»c_«bs»i_«bs»t_«bs»e_«bs»t_«bs».
$nl$
Defineres som maksimal gennemstrømning.
$nl$
I følge Kintchine-Pollaczek kan svartidens afhængighed af udnyttelsesgraden
findes ved følgende formler:
$nl4$
Her er ^^^ den gennemsnitlige svartid,^^^ er den gennemsnitlige
behandlingstid,^^^ er en konstant, der afhænger af det
betragtede systemet, og som
angiver en koefficient for variationen på behandlingstiden. ^^^ er
udnyttelsesgraden af hele systemet.
Ved behandlingstiden for et job forstås summen af tiden jobbet anvender ved de
indgående enheder. Behandlingstiden ved CPU-en er således den CPU-tid
jobbet bruger.
Nedenstående figur
viser, hvordan svartiden ud fra denne formel afhænger af udnyttelsesgraden.
$ps0$
$nl10$
$sj$
figur 2.4.1
$rj$
Det viser sig, at kurven har en lodret asymptote, og denne asymptote
svarer til kapaciteten. Udnyttelsesgraden som
indgår i formlen er defineret som den gennemsnitige behandlingstid
divideret med den gennemsnitlige ankomsthastighed. For nemmere
at kunne anvende formlen betragtes svartidens afhængighed af
ankomsthastigheden. Det viser sig her, at denne kurve også har
en lodret asymptote, og denne findes i opgaven.
$nl$
$nl$
_«bs»G_«bs»e_«bs»n_«bs»n_«bs»e_«bs»m_«bs»s_«bs»n_«bs»i_«bs»t_«bs»l_«bs»i_«bs»g__«bs»k_«bs»ø_«bs»l_«bs»æ_«bs»n_«bs»g_«bs»d_«bs»e_«bs».
$nl$
Ved de indgående enheder kan de tilhørende kølængder betragtes.
Disse
siger noget om, hvilke enheder som kan være skyld i store svartider.
Den gennemsnitlige kølængde kan findes ved Little's lov( se side 185 i Ferr78)
Den siger at
$nl4$
hvor N er den gennemsnitlige kølængde, ^^^ er ankomsthastigheden til enheden og
^^^ er den gennemsnitlige svartid ved enheden.
$nl2$
_«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»f_«bs»l_«bs»a_«bs»s_«bs»k_«bs»e_«bs»h_«bs»a_«bs»l_«bs»s_«bs».
$np$
Ferr78 anvender side 342 følgende definition på en flaskehals.
Lad S være et system, P et præstationsindeks og x1,...,xn være n
variable parametre. xi er både belastnings- og systemparametre. Det antages,
at en forøgelse i P angiver en forbedring i ydeevnen.
P(x1,...,xn) betragtes. Dette er normalt en ikke lineær funktion. Denne
ulinearitet angiver ofte flaskehalse.
En flaskehals
defineres nu til at være den enhed forbundet til de parametre, der ved
en lille ændring bevirker er stor forøgelse i P.
Eksempelvis hvis xi er en pladelagerhastighed. Ved en lille forøgelse
i xi bliver P(x1,...,xn) væsentligt større. Dette betyder, at
pladelageret er flaskehalsen, og en forøgelse i pladelagerhastigheden,
vil bevirke et væsentlig forøgelse i systemets ydeevne.
$np$
Denne noget upræcise definition af en flaskehals bliver
præciseret i afsnit 6.4.
$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.
Systemet er udviklet af Jydsk Telefon. Det 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$
OP-systemet er implementeret på maskinel fra Regnecentralen.
$np$
Konfigurationen for OP-systemet ændres efter tidspunktet i døgnet på
grund af en meget skiftende belastning. I en hårdt belastet
time findes der til systemet koblet 3 RC8000, 2 RC3500 af typen FP,
2 RC3500 af typen NP og omkring 15 RC3500 af typen TP. Det er antallet
af TP'er og RC8000 der formindskes, når belastningen af OP-systemet
er meget lille. Figur 3.1 viser, hvorledes principperne
i kommunikationen mellem disse maskiner foregår.
$ps0$
$sj$
figur 3.1
$rj$
$ps0$
Forkortelser står
for følgende:
$sj$

FP = Front-end Processor

NP = Network Processor

TP = Terminal Processor
$rj$$nl$
Terminalerne koblet til systemet er koblet til RC3500 betegnet TP.
Der til hver TP maksimalt er koblet 23 terminaler.
Til hele OP-systemet er maksimalt koblet ca. 130 terminaler.
Hver RC8000 har 3 associerede diske og en RC8000 behandler alene
et antal forespørgsler.
$np 15$
$np 15$
Når der ringes ind til tlfnr.oplysningen bliver en forespørgsel indtastet
på en skærm.
Når forespørgslen er afsendt fra skærmen modtages den af TP.
Denne RC3500 omsætter den
til en repræsentation, som kan forstås af resten af systemet. RC3500 sender derefter
transaktionen 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 TP'en og de
RC3500'er der på figuren er betegnet NP er en 48 K bps (bit pr. sekund)
datatransmissionslinie. Transaktionen modtages af en af de 2 RC3500
betegnet NP 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 hvormange RC8000 der 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 et skel mellem hvilke former for
transmissionssystem, der benyttes. Transmissionssystemet 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
transaktionen og modtages i RC8000 af en terminaldriver.
$np 15$
Hvordan hele OP-systemet er implementeret i de 3 typer RC3500 er
ikke beskrevet i denne opgave. Begrundelsen for dette findes i afsnit 6,
og er, at denne del af systemet anvender forholdsvis lidt tid til
at behandle en forespørgsel.
Derimod findes i nedenstående en beskrivelse af, hvordan OP-systemet
er implementeret i RC8000.
Normalt vil der i hårdt belastede timer være 3 RC8000 koblet til OP-systemet.
Som angivet sker fordelingen af forespørgsler mellem disse 3 maskiner
ved hjælp af de 2 RC3500 på figuren betegnet FP. Det er tilstræbt at foretage
denne fordeling så hver RC8000 modtager ligemange transaktioner.
Da fordelingen sker ved hjælp af 2 RC3500 er det imidlertid ikke helt simpelt
at foretage en ligelig fordeling.
$np$
Dette kan yderligere anskueliggøres ved følgende argument. Når en forespørgsel
afsendes fra en skærm modtages den af en RC3500. Denne sender transaktionen
videre af linie 1 i langt de fleste tilfælde.
Dvs. at antallet af transaktioner den ene NP modtager afhænger af,
hvormange terminaler, der er koblet til de RC3500 der kommunikere med denne.
Det er derfor ikke sikkert, at de to NP'er modtager lige mange forespørgsler.
I de to FP'er er det derfor ret vanskeligt at fordele transaktionerne
ligeligt mellem 3 RC8000. Fra KTAS's side menes, at fordelingen
sker i forholdet 40,30 og 30 % af transaktioner til hver RC8000.
På baggrund af denne uligefordeling er det ved vurderingen nødvendigt
at betragte hver RC8000 for sig.

$np 15$
I nedenstående anvendes en del termer knyttet til en RC8000. Disse skal
kort forklares her. En dyberegående forklaring kan findes i Brin72.
$nl2$
Intern proces
$nl$
Defineres som udførelsen af et eller flere afbrydelige programmer i et
givent lagerområde. Den er identificeret ved et entydigt navn.
$nl2$
Ekstern proces
$nl$
Refererer til input/output til en given enhed.
Dette betyder, at når en enhed er navngivet kan en intern proces kommunikere
med enheden gennem en ekstern proces uden at vide specielle karakteristika
om enheden.
$nl2$
Monitor
$nl$
Et program der aktiveres ved interrupts. Monitoren befinder sig permanent i lageret.
Monitoren kan opfattes som en programudvidelse af maskinelstrukturen. Derved
gøres maskinen mere attraktiv til multiprogrammering.
Monitorens funktion er:
$lm20$$nl$
1.at have en beskrivelse af alle processer.
$nl2$
2.at dele maskinen mellem interne og eksterne processer.
$nl$
3.at kunne oprette og nedlægge andre processer,

samt at kunne kommunikerer mellem processer. Dette er implementeret ved,
at nogle procedure i monitoren kaldes.
$lm0$
$nl2$
Message buffer
$nl$
En message buffer anvendes til at sende meddelser fra en proces til en anden.
Det angives eksempelvis i bufferen, at et segment på pladelageret ønskes
overført. Bufferen er 8 ord, der bruges til en meddelse.
$nl$
$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
eksterne processer, der fungere som
drivere til ydre enheder såsom pladelagre og terminaler.
De sorte pile på figuren angiver, at der sker overførsel af data.
Data er information om abonnenter i en intern repræsentation i form af kommunikationsblokke.
Disse kommunikationsblokke udskrives, når forspørgslen er færdigbehandlet i en fil
kaldet logfilen på systemdisken.
De 5 processer ligger fast i lageret. Overførslen af data foregår ved,
at en kommunikationsblok kopieres fra en proces til en anden proces.
$np$
En hvid pil svarer til, at der sker overførsel af meddelser.
En meddelse er eksempelvis at bede monitoren om at kopiere data.
$np$
De 5 interne processer beskrives nu mere udførligt. Det skal her anføres,
at de vigtigste og mest lagerforbrugende er søge- og opslagprocessen. Det er
i disse fremskaffelsen af information om telefonabonnenter sker.
De 5 processer er alle programmeret i ALGOL.
$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
processer. Opstart af systemet i RC8000 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
kontrolinformation fra RC3500.
Dene kontrolinformation kan eksempelvis angive, at forespørgslen er en bladning.
Inputlinien (indeholdende en forespørgsel) analyseres. Dette
resulterer i, at transaktionen videresendes til enten søge-,
opslag- eller outputprocessen.
$nl$
$nl$
Processens forløb kan detaljeret beskrives på følgende måde:
$np$
Efter en analyse af kontrolinformationen, 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øge- eller
en tlfnr.forespørgsel. En søgeforespørgsel indeholder
et eller flere felter efterfulgt af et feltindhold.
De vigtigste felter (til hvert felt er angivet et eksempel på indholdet) er følgende:
$ps0$
$sj$
FELT INDHOLD BETYDNING

*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 svarende
til et bynavn.
Dette er eneste
felt, der altid skal forefindes,
derudover
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$
1.Søgeforespørgselslinie.
$np$
Søgelinien kontrolleres , herunder registreres eventuelle
alvorlige
fejl f.eks. fornavn uden efternavn, husnr. uden gade.
En nøjere undersøgelse af en søgeforspørgsel sker først i søgeprocessen.
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$
2.Telefonnummerforespørgsel.
$np$
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 opslagprocessen.
$nl$$nl$
3.Ukendt linietype eller fejllinie.
$np$
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.
En "kandidat" til en forespørgsel er et muligt svar.
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 kan opfattes som 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".
Abonnentfilen indeholder information om de enkelte telefonabonnenter.
I opslagprocessen fremfindes ud fra disse pointere den ønskede information om abonnenterne.
$np15$
Antallet af pladelagertilgange pr. søgeforespørgsel i søgeprocessen afhænger af
antallet af søgekriterier.
$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.
Da det ikke er muligt at måle, hvormange pladelagertilgange
der anvendes i søgeprocessen, angives her ud fra en artikel i Data (se bilag 1),
hvorledes antallet af pladelagertilgange i søgeprocessen findes.
$np$
I en tilføjelse til artiklen er en formel angivet. Formlen angiver, hvilke
størrelser i en søgeforespørgsel der anvendes til at finde antallet
af pladelagertilgange. Formlen har følgende udseende:
$sj$
A = antal pladelagertilgange pr. gennemført
søgeforespørgsel
B = antal opslag i stednavnsfilen pr. kriterie
C = antal opslag pr. kriterie
D = antal kriterier pr. forespørgsel
E = antal AB-områder pr. forespørgsel
Med disse betegnelse gælder:

A = B + ( C * D * E )
$rj$
$nl$
De angivne størrelser betyder følgende:
$nl$
Stednavnsfilen er opdelt således, at hyppigt anvendte stednavne er placeret
i lageret. Derfor afhænger antallet af pladelagertilgange af,
hvor stor sandsynligheden er for at stednavnet findes i området
for hyppigt anvendte stednavne. Denne sandsynlighed kan findes
fra en statistik som er beskrevet i afsnit 5.1 og betegnes OPSTAT.
Fra en OPSTAT findes B til 0.18.
$nl$
Et opslag til et andet kriterie end stednavnet er en acces til
en fil, der findes på søgedisken. Dette vil altid være 2. (dvs. C = 2)
At det altid er 2 hænger sammen med den måde søgeprocessen er implementeret.
Antallet af kriterier pr. forespørgsel kan ligeledes findes fra en
OPSTAT. Den findes til 2.03 (= D).
$nl$
Den sidste størrelse i formlen en antal AB-områder pr. forespørgsel.
Denne kan findes til 3.5 (= E). Et AB-område er en indikering
af de to første cifre i et tlfnr. Er eksempelvis stednavnet Østerbro,
så starter de to første cifre i tlfnr. i de fleste tilfælde
med enten 26,29,32 eller 42.
38 er et AB-område.
$nl$
Fra den angivne formel findes så, at
$sj$
A = 0.18+(2*2.03*3.5) = 14.39
$rj$
$nl$
Dette er pr. gennemført søgeforespørgsel. De eneste afviste søgeforespørgsel
som præcist kan angives at anvende et andet antal er en,
der afvises på grund af at stednavnet ikke findes. Disse vil kun anvende
1 pladelagertilgang.
$np$
Det angives nu, hvormange pladelagertilgange der er for samtlige
søgeforespørgsler. Tallene er hentet fra en OPSTAT ( fra d.25.04.81).
$sj$
2753 afviste søgeforespørgsler, hvor stednavnet
ikke findes a 1 pladelagertilgang = 2753
79968 gennemførte søgeforespørgsler + afviste
af anden grund a 14.39 pladelagertilgange =1150739.5
--------------------------------------------------------------
82721 søgeforespørgsler med ialt antal plade.tilg. = 1153492.5

Dermed 13.9 pr. søgeforespørgsel.

$rj$
$nl$
$np$
Da det ved vurderingen af OP-systemet viser sig, at
søgeprocessen er en meget vigtig proces, har det i afsnit 6.3 været
nødvendigt at beskrive denne nærmere.
$ns 1,4,3.2.4.Opslagprocessen.$
$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$
Svarende til de to dele udfører processen følgende:
$nl2$
1.Tlfnr.forespørgsel.
$np$
En tlfnr.forespørgsel bevirker, at opslagprocessen 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$
2.Søgeforespørgsel.
$np$
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.
$np$
Antalpladelagertilgange i opslagprocessen afhænger af
forespørgselstypen. For en tlfnr.forespørgsel anvendes 2. For en
søgeforespørgsel anvendes 1 for hver kandidat. Dermed fås
$sj$

48140 søgeforespørgsler a 7.5 kandidater 361050

27070 tlfnr.forespørgsler a 2 54140
-----------------------------------------------------
75210 forespørgsler med ialt antal plade.tilg.415190

Dermed pr. forespørgsel i opslagsprocessen 5.5 plade.tilg.

$rj$$nl$
$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 en outputbuffer 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 og
at udskive de modtagne meddelser i en fil kaldet LOGFILEN.(beskevet i afsnit 3.4)

$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.
$nl20$
$sj$
Figur 3.3.
$rj$
$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 Brin72 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$
At forklare, hvordan scheduleringsstrategien på en RC8000 virker,
er det samme som at forklare, hvordan en proces indsættes i aktivkøen. Dette
skyldes, at det altid er første proces i aktivkøen, der er kørende.
En proces indsættes i aktivkøen på baggrund af en variabel
i procesbeskrivelsen, der betegnes TIMEQUANTUM. Denne størrelse må
absolut ikke forveksler med en tidsskive, der altid er 25.6 ms.
$nl$
Nedenstående er de 3 tilfælde, som opstår, når en proces afbrydes, og
der derved skal ændres i rækkefølgen i aktivkøen.
$nl2$
1.Processen afbrydes af klokken.
$nl$
Dette sker for hver 25.6 ms. Når processen
afbrydes bliver TIMEQUANTUM = den kørte tid + TIMEQUANTUM. Den
kørte tid angiver, den tid processen har været kørende uden afbrydelse.
Hvis TIMEQUANTUM derved bliver større eller lig 25.6 ms bliver
processen taget ud af aktivkøen og placeres bagest i køen.
TIMEQUANTUM bliver derefter sat til 0.
$nl2$
2.Processen afbrydes af et interrupt fra en ydre enhed.
$np$
Interruptet vil her altid være beregnet til en proces, der er ventende.
Denne ventende proces indsættes i aktivkøen foran den kørende
proces, hvis TIMEQUANTUM er større eller lig 25.6 ms ellers
indsættes den bagest i aktivkøen.
$nl2$
3.Processen ønsker eksempelvis en pladelagertilgang.
$nl$
TIMEQUANTUM sættes til tiden processen har været kørende uden
afbrydelser + TIMEQUANTUM. Processen tages derefter ud af køen og bliver ventende.
$nl2$
Formålet med denne ret komplicerede scheduleringsstrategi er, at hindre
at en proces monipolisere en ydre enhed, og at sikre en hurtig
kommunikation med ydre enheder.

$nl2$
Eksempel 3.4:
$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 25.6 ms (betegnes i det følgende også med en tidsskive)
Imidlertid skal proces A efter 15 ms benytte
et segment fra pladelageret.
(Det antages, at denne pladelagertilgang tager 38.3 ms.)
Dette bevirker, at proces A bliver passiv og B ( som er
ventende ) bliver kørende.
(Aktivkø: B,C) Størrelsen TIMEQUANTUM 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. TIMEQUANTUM for B bliver sat til
10.6 ms. Idet dette er mindre end en 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.
TIMEQUANTUM 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 TIMEQUANTUM
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.
Da A's tidskvant er mindre end 25.6 ms, vil denne blive
indplaceret forrest i aktivkøen.
(Aktivkø: A,C,B)
$np$
A får nu tildelt 25.6-2.1 ms, som er den tid der er tilbage af
en tidsskive.
Efter at proces A har kørt 25.6-2.1 = 23.5 ms bliver A afbrudt af klokken.
A's TIMEQUANTUM bliver sat til 15.0+23.5= 38.5 ms. Dette er større end
en tidsskive og A bliver derfor sat bagest i køen. TIMEQUANTUM for A bliver
sat til 0.(Aktivkø: C,B,A) C kører så 25.6 ms og TIMEQUANTUM for C
bliver 25.6+2.1 = 27.7. Den tages derfor ud af aktivkøen og indsættes
bagest. (Aktivkø: B,A,C) TIMEQUANTUM for C bliver igen sat til 0.
Dette fortsættes på ækvivalent vis.
$nl$
På nedenstående tidslinier er angivet, hvordan de 3 processer kører.
En skravering af tidslinien angiver at processen er kørende.
$nl10$
$sj$
Figur 3.4.
$rj$
$nl$
$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.
$ns 1,4,3.4.Beskrivelse af LOGFILEN.$
$np 15$
Når en forespørgsel passerer gennem OP-systemet, foregår dette ved,
at en vis mængde data i form af kommunikationsblokke
transporteres mellem de i systemet indgående processer.
Disse kommunikationsblokke udskives i en fil på systemdisken kaldet logfilen.
Dette foregår som tidligere beskrevet i outputprocessen.
$np 15$
Hver kommunikationsblok indeholder et blokhoved. Dette blokhoved
indeholder følgende information:
$sj$
bloklængde
bloktype
løbenr.
terminal identifikation
fra A-omr. til A-omr.
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.
$np$
Det er indholdet af dette blokhoved, der ved denne opgave læses i logfilen
og derved anvendes til at finde de i afsnit 4 beskrevne præstationsindeks.
Den udover blokhovedet eksisterende information i logfilen vil ikke blive beskrevet
her, men vedlægges som bilag 2. Grunden til at beskrivelsen ikke er
medtaget her, er for det første, at den indeholder en del intern
information, som det vil være for uoverskueligt at beskrive. For
det andet anvendes anvendes kun ovenfor nævnte information. Det
kan dog nævnes, at den ekstra information i logfilen eksempelvis
normalt
anvendes til at undersøge kriteriesammensætningen og f.eks. hvor
hyppigt et stednavn anvendes.
$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.
Det er derimod særdeles vigtigt at
forstå, hvordan pladelagerkanalen fungerer.
Dette skyldes, at
der er tre processer om at kommunikere gennem samme datakanal,
og det kan derfor tænkes,
at den begrænser systemetsydeevne.
$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.
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 pladerlagerkanalen.
Pladelagerkanalen sørger derefter for at pladelageret
positionere selve diskhovedet
hen til det spor, 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.
En nøjere beskrivelse af pladelagerkanalen findes i afsnit 3 i simulatoropgaven.
$rh 1,PROBLEMIDENTIFISERING$
$ps0$
$ns 1,4,4.Problemidentifisering.$
$np$
Dette afsnit indeholder en præcisering af formålet med vurderingen
af OP-systemet. Det angives, hvilke præstationsindeks, der betragtes,
og hvad baggrunden for evalueringen er. Det kan virke
ejendommeligt først at medtage en problemidentifisering af
opgaven i afsnit 4. Dette er gjort, fordi mange problemstillinger
kræver et kendskab til det foreliggende system.
$ns 1,4,4.1.Baggrunden og formålet for vurderingen af OP-systemet.$
$np$
Det hos KTAS kørende OP-systems belastning er
afhængig af, hvormange mennesker, der ringer ind til
tlfnr.oplysningen. Imidlertid er dette ikke den eneste
faktor, der har indflydelse på belastningen. Det har vist sig, at kapaciteten
af de indgående telefonlinier ligeledes er en væsentlig faktor. Målinger
har vist, at omkring 30 % enten får optaget eller overhovedet ikke kommer
igennem.
Fra udvidelsen af disse linier kan forventes en forøgelse i belastningen.
Da evalueringsstudiet startede kunne en forøgelse
af belastningen også forventes, idet de andre telefonselskaber
skulle kobles til systemet. Dette bevirker en forøges belastning på
ca. 4 %.
$np$
Baggrunden for vurderingen er således, at der ønskes en undersøgelse
af dels om
hvor stor en forøget belastning kan OP-systemet klare med
de nuværende ressourcer,
og dels
hvordan vil det klare denne forøgelse i belastningen.
$np$
Ud fra denne baggrund kan formålet med vurderingen identifiseres
ved følgende spørgsmål.
$nl2$
Hvordan er belastningen af OP-systemet ?
$nl$
Til dette skal belastningen beskrives, så det fremgår
hvormange forespørgsler der modtages dels i et helt
døgn og dels for hver time i døgnet. Ved denne beskrivelse
kan det så anføres, hvornår spidsbelastningen er. I forbindelse
med belastningen kræves også en analyse af, hvilke forespørgselstyper
OP-systemet modtager, og om mønsteret i disse forespørgselstyper
ændres i løbet af døgnet. Derudover skal det beskrives,
hvor store de enkelte forespørgselstyper ressourcekrav er.
$nl2$
Hvordan klarer OP-systemet den nuværende belastning ?
$nl$
Til belysning af dette spørgsmål, skal følgende
synspunkter analyseres. Hvor stor er udnyttelsesgraden af systemet,
og hvordan udnyttes de indgående enheder. Derudover skal
svartiderne undersøges dels for de enkelte forespørgselstyper
og dels i forhold til den belastning OP-systemet udsættes for.
Det anførte spørgsmål om hvordan OP-systemet
klarer den nuværende belastning, skal ses som en vurdering af,
hvor godt systemet fungere dvs. beskrive dets evne til at behandle
forespørgsler.
$nl2$
Hvor stor en forøgelse i belastningen kan OP-systemet klare ?
$nl$
Dette spørgsmål skal ses i forbindelse med de komponenter systemet
består af. At angive om systemet kan klare en forøgelse
i belastningen skal ses i forhold til at der ikke må
komme en stor stigning i svartiden pr. forespørgsel.
$nl2$
Hvorledes forbedres OP-systemet ?
$nl$
Dette spørgsmål anses for det vigtigste. Ved hjælp
af målinger identifiseres de enheder, der anvender mest tid.
Ud fra dette skal det angives, hvordan disse forbedres. Besvarelsen
af dette spørgsmål bygger særdeles meget på den konstruerede
simulators pålidelighed.
$ns 1,4,4.1.Betragtede præstationsindeks.$
$np$
Ud fra de ovenfor anførte spørgsmål vil det blive beskrevet,
hvilke præstationsindeks, der betragtes ved vurderingen. Ved hvert
indeks angives, hvorfor det betragtes. Det vil således fremgå,
hvad der tænkes opnået ved den efterfølgende vurdering.
$nl2$
1.Belastningsindeks.
$nl2$
antal ankommende forespørgsler
$nl$
Dette indeks betragtes pr. time og i et døgn for at beskrive, hvordan forespørgslerne
fordeler sig. Herved kan spidsbelastningen og gennemsnitlige
ankomsttider findes.
$nl2$
Antal forespørgsler i hver proces.
$nl$
Antal bladninger, afdækninger af hemmelig tlfnr. og fejllinier.
$nl$
Ud fra disse indeks kan antallet af forespørgselstyper beregnes.
En beskrivelse, hvordan dette gøres findes i afsnit 5.2.
Disse indeks benyttes derfor til at beskrive forespørgselsmønsteret.
Hver indeks måles pr. time og for et døgn. Forespørgselsmønsteret
afhængighed af tidspunktet i døgnet kan derfor beskrives.
$nl2$
Gennemsnitlig CPU-tid pr. forespørgsel i hver proces.
$nl$
Fordelingen af CPU-tiden.
$nl$
Disse indeks kan sammenholdt med antallet af pladelagertilgange i de
enkelte processer, betragtes som en beskrivelse af forespørgslernes
ressourcekrav.
$nl$
Alle de anførte indeks kan måles i logfilen, og samlet danner
de den belastningsmodel, der anvendes ved vurderingen.
$nl$
Et alternativ til denne model kan anføres:
$nl$
I stedet for at betragte gennemsnitlige CPU-tider pr. forspørgsel og
fordelingen af CPU-tiden, kunne CPU-tiden pr. forespørgselstype være anvendt
som et mål. Det har imidlertid vist sig, at der ikke er væsentlig
forskel i CPU-tiden for de forskellige forespørgselstyper.
Dette kan bedst illustreres ved opslagprocessen. Denne proces behandler
både gennemførte søge- og tlfnr.forespørgsler. Den første type
skal i gennemsnit fremfinde 7.5 kandidater og den anden 1 kandidat.
Man kunne så forvente, at CPU-tiden havde en fordeling som
angivet på nedenstående figur.
$nl10$
$sj$
figur 4.1
$rj$$nl$
De to anførte "pukler" skulle stamme fra dels gennemførte søge-
og dels tlfnr.forespørgsler. Det har imidlertid vist sig, at
kurven ikke har det skitserede forløb, men derimod ligner
en eksponentialfordeling. Dvs. antallet af forespørgsler
falder jævnt i forhold til CPU-tiden. Dette er nøjere illustreret
i afsnit 6, hvor kurven for CPU-tidsfordelingen præcist
er angivet.
$nl3$
2.Systemindeks.
$nl$
$nl2$
Gennemsnitlig procestid pr. forespørgsel i hver proces.
$nl$
Procestiden defineres, som afgangstiden - ankomsttiden. Størrelsen
beskriver således, hvorlænge en forespørgsel befinder sig i processen.
Hvis indekset sammenlignes med CPU-tiden findes derved, hvor lang
tid forespørgslen anvender både til
overførsel af information fra pladelageret og til tiden der stammer
fra at OP-systemet i RC8000 er multiprogrammeret.
Gennemsnitlig køtid pr. forespørgsel ved hver proces.
$nl$
Køtiden ved en proces defineres som afkomsttiden til processen -
afgangstiden fra forrige proces.
Køtiden anvendes til at undersøge om der eventuelt
sker en ophobning af forespørgsler ved en proces.
$nl2$
De indtil nu anførte indeks er alle primære indeks, som
kan måles direkte i logfilen. De betragtes for et døgn og
pr. time.
$nl2$
Derudover betragtes følgende sekundære præstationsindeks.
$nl$
Gennemsnitlig svartid pr. forespørgsel.
$nl$
Den gennemsnitlige svartid defineres som totalprocestid divideret
med antal behandlede forespørgsler.
$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.
$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 den 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 defineres dog
som den tid den er optaget og ikke kan benyttes af andre. Dvs.
$nl$$sj$
8.3 * antalpladelagertilgange
______________________________
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.
$nl2$
For hele OP-systemet dvs. med RC3500 delen betragtes kun den gennemsnitlige
svartid for en forespørgsel.
Figur 4.2 viser en simplificeret udgave af OP-systemet.
$nl10$
figur 4.2
$nl2$
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.
Der undersøgtes forskellige muligheder
for at finde svartiden i en RC3500.
$np$
Muligheden for at indsætte nogle "soft-ware"-tællere i RC3500
blev 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 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 sonder. Disse kan
registerer, når en forespørgsel sendes og modtages. Ved at koble et
ur i forbindelse med disse sonder, er det muligt at måle, hvor lang tid en
forespørgsel tager i hele OP-systemet.
$rh 1,ANVENDTE MÅLEPROGRAMMER$
$ps0$
$ns 1,4,5.Beskrivelse af anvendte målemetoder.$
$np$
Nedenstående afsnit beskriver, hvilke måleredskaber som anvendes ved
dette evalueringsstudium. Derudover anføres med begrundelse, hvilke eksperimenter, der på
denne baggrund er foretaget.
$np$
De programmelredskaber vurderingen anvender er den i afsnit 3.7
beskrevene logfil.
$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ølgende 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 skrevet 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.
Et eksempel på en OPSTAT er velagt som bilag 3.
Nedenstående afsnit beskæftiger 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 punkter:
$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.
$nl$
$lm0$
$np$
For de to første punkter 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$
$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 procestid 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 4.2
$np$
OPSTAT anvendes nu kun til dele af vurderingen, fordi
ovenstående tabel
kun bygger på gennemførte søgeforespørgsler.
En tilsvarende tabel kan findes for tlfnr.forespørgsler, men
ovennævnte tabel kan 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.
$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 5.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$
$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$
$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$
Eksempelvis ser denne udskrift ved inputprocessen ud på
følgende måde:
$sj$

CPU-TID i ms antalforsp
0 - 5 : 0
5 - 6 : 1219
6 - 7 : 12802
7 - 8 : 5012
8 - 9 : 1820
9 - 10 : 1873
10 - 11 : 891
11 - 12 : 1356
12 - 13 : 652
13 - 14 : 1243
14 - 15 : 575
15 - 16 : 815
16 - 17 : 517
17 - 18 : 79
18 - 19 : 63
19 - ... : 115
$rj$
$nl2$
Den beregnes ved, at optælle antallet af forespørgsler der eksempelvis
har en CPU-tid mellem 6 og 7 ms.
$nl2$
3.Svartidsfordeling og udnyttelsesfordeling.
$np$
Formålet med denne del er præcist at se CPU-ens udnyttelsesgrads afhængighed af
belastningen.
Et udsnit af denne har eksempelvis følgende udseende:
$sj$

antalforsp svartid i ms udnyttelse af CPU
______________________________________________________

2868 426.7 14.4 %
2869 441.3 15.0 %
3139 440.8 16.0 %

$rj$
$nl$
Udskriften konstrueres så målingerne svarende til timerne i døgnet
udskives i stigende orden efter antallet af forespørgsler. For
hver observation, dvs. hver time udskives den gennemsnitlige svartid
og udnyttelsen af CPU-en.
$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.
$nl$
Et udsnit af denne har eksempelvis følgende udseende:

$sj$

Svartid i ms antalforsp procent af alle acc.procent
________________________________________________________________
0 - 249 44 40.00 % 40.00 %
250 - 499 17 15.45 % 55.45 %
500 - 749 11 10.00 % 65.45 %
750 - 999 8 7.27 % 72.73 %
1000 - 1249 10 9.09 % 81.82 %
1250 - 1499 7 6.36 % 88.18 %
1500 - 1749 3 2.73 % 90.91 %
1750 - 1999 5 4.55 % 95.45 %
2000 - 2499 2 1.82 % 97.27 %
2500 - 2749 1 0.91 % 98.18 %
2750 - 3000 1 0.91 % 99.09 %
3000 - 3249 1 0.91 % 100.00 %
3250 - 3500 0 0.00 % 100.00 %

$rj$
Denne uskrives for hver time i døgnet. Den beregnes ved at optælle
antallet af forespørgsler der eksempelvis har en svartid mellem 0 -249 ms.
Derefter beregnes, hvor stor en procentdel af alle forespørgsler dette udgør.
Kolonnen acc.procent er beregnet ved at summere antallet af forespørgsler
der har en mindre svartid, og derefter beregne, hvor stor en procentdel
af alle forespørgsler de består af.
$nl2$
5.Ydertilfælde.
$np$
Her udskrives de mindste og største værdier for den samlede svartid.
Dette gøres for hver time i døgnet og samlet for hele døgnet
$nl$
Eksempelvis har et udsnit af denne udskift følgende udseende.
$sj$
minimal maksimal
mellem kl. 0. og kl. 1 38 1416

$rj$
De minimale og maksimale værdier er for svartiden.
Et eksempel på hele udskriften er vedlagt som bilag 4. Programteksten
til KTASSTAT er vedlagt som bilag 5.
$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(1,2) a(1,3) a(1,4)

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

opslag 0 0 0 a(3,4)

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(1,2) 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ølgende størrelser findes direkte fra KTASSTAT.
Opsummerende kan nævnes, at de kendte størrelser er antal forespørgsler
i hver proces, og antal forespørgsler der passere fra input- til
outputprocessen. Derudover kendes det totale antal forespørgsler.
$sj$

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

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

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

a(3,4) = 1
$rj$
Det er mere vanskeligt at finde a(2,3). 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(2,3)*AS + a(1,3)*AI

og dermed er

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

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

$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$
$rh 1,VURDERING AF OP-SYSTEMET$
$ps0$
$ns 1,4,6.Vurdering af OP-systemet.$
$np15$
Dette afsnit indeholder vurderingen af OP-systemet. Afsnittet er disponeret så
afsnit 6.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 6.2 giver en vurdering af OP-systemet ud fra målinger i logfilen.
Afsnit 6.3 beskriver derefter, hvilke resultater der er opnået ved hjælp af den konstruerede
simulator. Afsnit 6.4 illustrerer de teoretiske modeller, der er betragtet.
$ns 1,4,6.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 6.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 6.1.1. 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 6.1.1.
$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 6.1.2 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 6.1.2.
$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 6.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 6.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 6.1.3.
$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 6.1.3
$rj$$nl$
De i tabel 6.1.3 anførte svartider kan ikke findes for de enkelte forespørgselstyper.
Med de i tabellen anførte svartider i RC8000 og RC3500
betragtes nu hele OP-systemet som vist på figur 6.1.2. Forkortelserne anført på
figuren står for det samme som angivet ved tabel 6.1.1.
$nl15$
$sj$
Figur 6.1.2.
$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.0 %, idet der mindst findes 15 af denne type.
$np$
Begrundelsen for kun at betragte OP-systemets RC8000-del ved resten af evalueringen, kan nu på baggrund af ovenstående opsummeres i
følgende punkter:
$sb ^,6$
$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.
$lm0$
$ns 1,4,6.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 6.3,
hvad der herved opnås.
$ns 1,4,6.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 KTASSTAT
har 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 brug 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 ikke 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,6.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ørgselstypen.
$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 6.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 i 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 afsender 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 6.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.
$ps0$$ps0$
$np$
OP-systemets RC8000-dels reaktionsevne på dette antal
forespørgsler afhænger nu udover transaktionernes antal 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 6.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 sandsynligheden for at
forespørgslens CPU-tid befinder sig i intervallet. Kurven viser
således fordelingsfunktionen fo CPU-tiden.
$ps0$$ps0$$ps0$
$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 6.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 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 forespørgsler pr.
time. Dette gøres, fordi det er eneste størrelse i belastningen, der direkte ændres.
$ps0$
$ps0$
Figur 6.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 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.5. 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 ankommende i en time.
$ns 1,4,6.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 6.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 gennemsnitlige svartiden stiger i timer, hvor
antallet af forespørgsler er stort er på figur 6.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 6.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 6.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 på figur 6.2.6 og 6.2.7 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
er, at den forholdvis store forøgelse i svartiden ikke
kan forklares ved at procestiden forøges.
$np$
Figur 6.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ørgsel 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 vides ikke, 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 den gennemsnitlige 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 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.
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,6.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 gennemsnitlige svartid på 4.9 %. Hvis en kurve for
konstrueres
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 6.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 angivet 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 6.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,
Til dette bemærkes,
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 til 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 er dermed
væsentligt større end processkift stammende fra
at en forespørgsel skifter mellem to processer. Det antages derfor at
udnyttelsesgraden af monitoren ved simulatoren beregnes rigtigt.
$np$
Kurven figur 6.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 6.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 det 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 6.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.

Ved køtiden i opslagprocessen er
simulatoren 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 6.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
til søgeprocessen
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 6.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 6.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.
Når nogle forbedringsforslag skal opstilles, bør disse sigte mod at formindske
de størrelser, der har størst stigning
ved en forøgelse af antallet af forespørgsler.
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 pladelagerkanalen.
$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 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 6.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
pladelagerkanalen vist i tabel 6.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.
Intuitivt er det 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.
$np$
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 6.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 til en RC8000 til
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,6.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 6.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. 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 6.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 6.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 fungere således, at den ud fra hvert kriterie i en søgeforespørgsel
danner en mængde af kandidater. For at finde frem til eventuelle kandidater
findes fællesmængden af disse kandidater.
$nl2$
Eksempel
$nl$
Antag at følgende søgeforespørgsel bliver stillet
$sj$

*bFrederikssund *nLarsen *fKnud
$rj$
$nl2$

Ud fra første kriterie *bFrederikssund slås op i en tabel
kaldet hypperboltabellen over stednavne. Her findes alle normalt
brugte stednavne. Fra en OPSTAT vides, at ca. 82 % af alle
stednavne findes i denne tabel. I tabellen er der ved stednavnet
angivet en pointer til en tabel kaldet AB-tabellen og
to pointere til en fil kaldet navnesøgefil. I AB-tabellen
findes en pointer til abonnentfilen. Abonnentfilen indeholder information om
telefonabonnenter.
$np$
Ud fra andet søgekriterie *nLarsen findes ved hjælp af Larsen en pointer
i navneindeksfilen. Denne fil indeholder pointere til navnesøgefil
hvor navne findes opdelt efter område.
På nedenstående figur er de forskellige filer og pointere angivet.
$nl20$
$sj$
figur 6.2.?
$rj$$nl$
Figuren er noget simplificeret, men det vigtigste
at observere er, at ud fra stednavnet opnås en pointer til
abonnentfilen og ud fra efternavnet opnås to pointere i abonnentfilen.
De kandidater som søgekriteriet giver adgang til bliver en mængde af pointere i abonnentfilen,
og ud fra denne dannes en fællesmængde svarende til de enkelte søgekriterier.
$np$
Undersøgelsen med en dubleret søgeproces viste, at dette bevirkede en bedre
udnyttelse af CPU-en. dette skyldes, at det var muligt at behandle mere
end en forespørgsel ved søgeprocessen. Formålet med ovenstående
beskrivelse er, at forsøge at afgøre om samme effekt kan opnås ved at opspalte
søgeprocessen i mere end en proces.
$np$
Dette kunne gøres ved at lave en proces, der svarer til et
eller to kriterier, og derefter en anden proces, der
svarer til resten af søgekriterierne. Ud fra en OPSTAT
kan kriteriesammensætningen findes. Det viser sig, at udover stednavnet er det mest
anvendte kriterie efternavnet.
$np$
Udfra dette vil jeg så foreslå følgende opdeling af søgeprocessen.
Der laves to søgeprocesser. En søgeproces behandler stednavnet og
et gadenavn og husnr. De sidste kriterier er søgekriterier, som
ikke er det mest anvendte, men det forekommer i omkring 53.3 % af
søgeforespørgsler. Tallet 53.3 % er opnået fra en OPSTAT. Den anden
søgeproces skal derefter behandle resten af søgekriterierne.
Op-systemet i RC8000 vil derefter få følgende udseende:
$nl20$$sj$
figur 6.2.?
$rj$
$nl$
De nye veje for en forespørgsel er på
figuren markeret A,B,C og D.
Det er ikke muligt præcist at angive, hvor stor en procentdel der vil passere
gennem de enkelte veje. Ved at betragte en OPSTAT vides, at en søgeforespørgsel
i gennemsnit tager 703 ms. En forespørgsel, hvor stednavnet ikke findes
tager i gennemsnit 272 ms.
$np$
De forespørgsler, der behandles i søgeproces 1 er forespørgsler på
stednavn,gade og husnr.
Det er ikke muligt at angive, hvormeget tid søgeproces 1 skal anvende,
men det vil formentlig
ligge omkring tiden for en afvist forespørgsel, hvor stednavnet ikke
findes.
Antallet af pladelagertilgange i søgeproces 1 kan ikke findes, men det kan
maksimalt være (0.18 +(2*2*3.5)= 12.68 pr. forespørgsel fundet
ud fra formlen angivet i afsnit 3). Da de to søgekriterier kun findes for
53.3 % af forespørgslerne antages, at antallet af pladelagertilgange
si søgeproces 1 da (53.3 * 12.68)#100= 6.8 pr. forespørgsel og
dermed omkring 7.2 i søgeproces 2. Formålet med opdelingen
er, at dele processerne således at de vil have samme arbejdsbyrde pr.
forespørgsel. Ved dette vil der opstå en vekselvirkning mellem CPU-behandling
i den ene proces og pladelagertilgange. Dette kan illustreres på nedenstående
figur.
$nl10$
$sj$
figur 6.2.?
$rj$
$nl$
På figuren er forholdene beskrevet optimalt, men ved en opdeling
på tiæsvanrende måde vil en højere udnyttelse af CPU-en kunne opnås.

$np$
Det angivne skal således kun ses som et forslag til, hvordan en opdeling
kan gøres. Det vil dog kræve en meget dybtgående undersøgelse
af hvordan kriteriesammensætningen for en søgeforespørgsel
er og hvilket tidforbrug de enkelte søgekriterier har, før en
anvendelig opdeling kan foretages godt.
$ns 1,4,6.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$
For at sammenligne, hvordan en model 55 kan behandle forespørgsler
er i tabel 6.3.10 vist de vigtigste indeks i en RC8000.
$sj$
model 45 model 55
antal forsp 6142 11952

Procestid søge 452.2 ms 325.4 ms
-"- opslag 176.1 ms 129.2 ms

Køtid søge 318.1 ms 454.1 ms
-"- opslag 20.7 ms 17.9 ms

Gnst svartid 657.8 ms 619.0 ms

Udnyttelse af søgedisk 22.5 % 43.6 %
-"- opslagdisk 7.2 % 13.3 %
Udnyttelse af diskkanal 15.6 % 30.3 %

Udnyttelse af CPU 37.2 % 34.9 %

Kølængde søge 0.86 1.7

tabel 6.3.10

$rj$
$nl$
Tabellen viser, at en model 55 faktisk ved en belastning på
6000 forespørgsler til en model 45 kan klare ca. dobbelt så
mange forespørgsler med samme svartid. Dette giver anledning til en
del forundring. Man skulle tro at andre størrelse end
hastigheden af CPU-en har indflydelse på,
hvordan svartiden for forespørgslerne er.
$np$
For nærmere at belyse om, hvordan svartiden anhænger af
belastningen, så er figur 6.3.11 anført. Den viser,
at den gennemsnitlige svartid stiger på tilsvarende måde som
ved en model 45. Der er her blot den forskel, at den maksimale
belastning ikke ligger på dobbelt så mange forespørgsler.
$ns 1,4,6.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 6.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 6.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 6.4.3.
Den findes beskrevet i Buz71.
$nl15$
$sj$
figur 6.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 6.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 6.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

⟦2c4dd668d⟧ TextFile

Derivation

TextFile