⟦b48d5f1fe⟧

TextFile

mode list.yes
vko2=set 50
afs=set 50
scope user afs
afs=typeset check.no proof.vko2 machine.diablo
*se $* $pl ,30,235,,10$
$lw 160$$ld18$
$ps0$
$nl$
Datalogisk Institut
$nl$
Sigurdsgade 41
$nl$
2100 København Ø
$nl17$
$ct$
Konstruktion af simulator
til 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$
Sven Larsen
Viggo Nis Kørst
$nl$
$rj$
$pn 5,3$
$rh 1,INDLEDNING$
$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$
Den foreliggende rapport er fremkommet som et delprojekt i
forbindelse med et speciale i præstationsvurdering. Til det betragtede system
-et oplysningssystem ved KTAS- ønskes udviklet en simulator, hvorved
et slagkraftigt værktøj til præstationsvurdering kan opnås.
$np$
Opgaveløserne satte sig ved starten af projektet nogle
mål, som beskrevet i "arbejdsbeskrivelse for 2.dels projekt". De
stillede krav gik i korthed ud på at konstruere en "passende" simulator
af OP-systemet og at eftervise at konstruktionen var lykkedes.
Med "passende" menes i denne sammenhæng, en simulator der kan opfylde
en række fleksibilitets- , detaljerings- og valideringskrav.
$np$
De stillede mål er i vid udstækning opnået, omend
tidsrammerne må siges at være sprængt flere gange. I forhold til
den oprindelige plan (arbejdsbeskrivelse) er beskrivelsen af simulatorens evne til
at præstere rigtige resultater sammenholdt med teretiske udledede formler,
i denne rapport stort set udeladt.
Udeladelse skyldes dels tidspres dels at nogen teori i stedet
er henlagt til det sideløbende speciale.
$np$
Indholdet i dette projekt skal kort nævnes. Der startes med
de generelle betragtninger over hvilke krav, der bør stilles til
en simulator af det omtalte system. Herefter vurderes nogle allerede udviklede simulatortyper
og på baggrund af disse overvejelser afgrænses og bestemmes en ønskelig
simulator. I afsnittet modelbeskrivelse omtales den faktisk udviklede
simulator m.h.t. struktur og funktion, og modellen beskrives på
flere detaljeringsniveauer.
$np$
Endelig afsluttes med et afsnit, hvor simulatorens komponenter afprøves
og hele simulatoren valideres i forbindelse med omtale af
det udviklingsarbejde, der måtte gøres før
den definitive simulator var klar.
$np$
På grund af krav til bedømmelsen af opgaven vil det her blive anført,
hvem der er ansvarlig for de følgende afsnit. Denne opdeling er
ikke udtryk for at vedkommende alene har udarbejdet afsnittet, men
kun en angivelse af, hvem der har skrevet afsnittet. Hele udarbejdelsen
af simulatoren og denne opgave er sket i et snævert samarbejde mellem
opgaveløserene.
$nl$
Følgende afsnit er Sven Larsen ansvarlig for:
$nl$
Afsnit 4 og 5.
$nl$
Følgende afsnit er Viggo Nis Kørst ansvarlig for:
$nl$
Afsnit 3,6 og 7.
$nl$
Afsnit 1 og 2 er begge ansvarlige for.
$rh 1,SIMULATOROVERVEJELSER$
$ps0$
$ns 1,4,_«bs»2_«bs»._«bs»S_«bs»i_«bs»m_«bs»u_«bs»l_«bs»a_«bs»t_«bs»o_«bs»r_«bs»o_«bs»v_«bs»e_«bs»r_«bs»v_«bs»e_«bs»j_«bs»e_«bs»l_«bs»s_«bs»e_«bs»r_«bs».$
$np$
Dette afsnit beskriver de overvejelser, der er foretaget for at finde
frem til en brugbar simulationsmodel af KTAS's OP-system.
Afsnittet redegører for, hvilket specificationskrav modellen skal
have. Disse er f.eks. krav om, at modellen skal afbilde
et antal maskinel- og programmelenheder. Derudover skal modellen have en vis
grad af fleksibilitet for at kunne tillade omfattende eksperimenter med modellen.
Ydermere kan krav til detaljeringsgrad have betydning i valget af simulatortype.
$np$
Afsnit 2 er disponeret således, at afsnit 2.1 indeholder nogle generelle overvejelser i forbindelse med et simuleringsstudium.
Det beskrives heri, hvad formålet med simulatoren er.
Derefter beskrives i afsnit 2.2, hvilke generelle krav, der stilles til simulatoren.
Det diskuteres her ganske kort, hvilke løsningsforslag, der tilfredsstiller opbygningen af en anvendelig model
bedst. Afsnit 2.3 indeholder en grundig beskrivelse af valget af simulationsmodel.
Til sidst beskrives i afsnit 2.4, hvilke krav vi specielt har lagt vægt på
ved udviklingen af simulatoren.
$ns 1,4,_«bs»2_«bs»._«bs»1_«bs»._«bs»K_«bs»o_«bs»n_«bs»s_«bs»t_«bs»r_«bs»u_«bs»k_«bs»t_«bs»i_«bs»o_«bs»n_«bs»s_«bs»-__«bs»o_«bs»g__«bs»i_«bs»m_«bs»p_«bs»l_«bs»e_«bs»m_«bs»e_«bs»n_«bs»t_«bs»a_«bs»t_«bs»i_«bs»o_«bs»n_«bs»s_«bs»o_«bs»v_«bs»e_«bs»r_«bs»v_«bs»e_«bs»j_«bs»e_«bs»l_«bs»s_«bs»e_«bs»r_«bs».$
$np$
Ved et kørende Edb-system, som det foreliggende OP-system hos KTAS, vil
det være meget vanskeligt at foretage en præstationsvurdering med
henblik på forbedringsstudier.
Problemerne ligger i, at det er vanskeligt at afprøve virkningen af de
forbedringsforslag, der kommer ved evalueringen af OP-systemet.
Disse problemer kan uddybes ved følgende:
$np$
OP-systemet, der kører ved KTAS, består af nogle maskinel- og programmelenheder.
Ved en evaluering af systemet kan det vise sig, at f.eks. en enhed
er kritisk m.h.t. ændringer i systemets ydeevne.
At afprøve om en forøgelse i hastigheden af
denne enhed bevirker en forøgelse i systemets ydeevne, er særdeles vanskeligt.

Det vil være urealistisk at foretage eksperimenter på selve
systemet med anskaffelse af nye enheder eller med at ændre i programmel ved
systemet.
$np$
Først når virkningen af et forbedringsforslag kan belyses grundigt vil anskaffelsen
af hurtigere maskinelle enheder eller omprogrammering af dele ved systemet
blive foretaget. Behovet for en simulator til systemet er derfor fremkommet netop
for at kunne foretage dyberegående eksperimenter ved systemet,
og for derved at
kunne afprøve virkningen af forskellige forbedringsforslag.
$np$
Ved anvendelsen af en
simulator

kan varieres på belastningen og på maskinelle enheder for at
simulere, hvordan systemet reagerer på ændrede forhold. Mulighederne
for at måle på en simulator af systemet er kun begrænset
af simulatorens detaileringsgrad. Det vil sige, hvordan
og hvor præcist simulatoren er et billede af det virkelige system.
$np$
Det efterfølgende afsnit beskriver, hvilke ting det er vigtigt at tage hensyn
til, når en simulator skal konstrueres. Afsnittet besvarer således
spørgsmål som:
$nl$
$lm20$
$nl$
Hvad formålet med simuleringen er ?
$nl$
Hvilken detaljeringsgrad skal simulatoren have ?
$nl$
Hvad der skal måles ?
$nl$
Hvilke størrelser skal kunne ændres ?
$nl$
$lm0$
$ns 1,4,_«bs»2_«bs»._«bs»1_«bs»._«bs»O_«bs»v_«bs»e_«bs»r_«bs»v_«bs»e_«bs»j_«bs»e_«bs»l_«bs»s_«bs»e_«bs»r__«bs»v_«bs»e_«bs»d__«bs»e_«bs»t__«bs»s_«bs»i_«bs»m_«bs»u_«bs»l_«bs»a_«bs»t_«bs»i_«bs»o_«bs»n_«bs»s_«bs»s_«bs»t_«bs»u_«bs»d_«bs»i_«bs»u_«bs»m_«bs».$
$np$
Inden en simulator til et datamatisk system konstrueres, må det
besluttes, hvilke dele af systemet simulatoren skal afbilde. Det
må besluttes, hvordan simulatoren skal afbilde det foreliggende datamatiske
system. Til en simulationsmodel hører dels en model af det
datamatiske system og dels en model af inddata.
$np$
Ved en model af et datamatisk system forstås en beskrivelse af de indgående
enheder, og en forklaring af, hvordan enhederne fungerer og kommunikerer
sammen.
Specifikationskravene til systemet hænger sammen med formålet med simuleringsstudiet.
Når simulationsmodellen implementeres skal en model
af inddata være fastlagt.
Det er vigtigt ved fastlæggelsen af en model af inddata præcist at vide,
hvilke eksperimenter man ønsker at foretage i forbindelse med simulatoren.
$np$
Formålet med at konstruere en simulator til OP-systemet hos KTAS, er
at eksperimenter kan foretages, som det ikke
er muligt at foretage på det virkelige system.
Derudover skal det ved hjælp af simulatoren være muligt at måle interessante
præstationsindices, som det ikke er muligt at måle på OP-systemet.
Da
det vil være for uoverskueligt og tidskrævende at simulere hele OP-systemet,
er en afgrænsning nødvendig. Denne afgrænsning er foretaget ud fra
følgende synspunkter:
$lm20$
$nl2$
1.De mest tidsforbrugende dele af OP-systemet skal medtages.
$nl$
2.Det skal være muligt at se om simulatoren giver troværdige
resultater.
$lm0$$nl2$
Afgrænsningen af simulationsmodellen til
OP-systemet er foretaget således, at kun RC8000
simuleres. En dyberegående begrundelse for dette, findes i
vurderingsopgaven.
Det kan her kort anføres, hvad hovedlinierne i begrundelsen er.
Ud fra målinger på hele OP-systemet har det vist sig, at omkring
60-70 % af svartiden for en forespørgsel bliver brugt i RC8000. Derudover
kan der ved en RC8000 til OP-systemet
foretages målinger af, hvordan svartiden for en forespørgsel
forløber i RC8000. Dvs. det kan måles,
hvilke programdele, som benytter mest tid
til at behandle en forespørgsel. Det vil derfor være muligt at eftervise
(validere) om simulatoren
afbilder en RC8000 til OP-systemet.
$np$
$ns 1,4,_«bs»2_«bs»._«bs»1_«bs»._«bs»2_«bs»._«bs»V_«bs»a_«bs»l_«bs»g__«bs»a_«bs»f__«bs»s_«bs»i_«bs»m_«bs»u_«bs»l_«bs»e_«bs»r_«bs»i_«bs»n_«bs»g_«bs»s_«bs»s_«bs»p_«bs»r_«bs»o_«bs»g_«bs».$
$np$
Da implementeringen af simulatoren påbegyndtes, var det nødvendigt at
beslutte, hvilket simuleringssprog simalatoren skulle
programmeres i.
Ved valget af programmeringssprog har to sprog været overvejet.
Disse sprog begge velegnede til simulering, og
det er de sprog som opgaveløserne er mest fortrolige med.
De overvejede sprog er SIMULA og ALGOL 8.
$np$
Valget af simuleringssprog har indflydelse på modellens struktur
og funktion.
$np$
ALGOL 8 blev overvejet
mest af afviklingstekniske
årsager.
Det forholder sig således, at KTAS har en ALGOL 8 oversætter, men ikke en
SIMULA-oversætter. Endvidere har den ene af opgaveløserne
adgang til en RC8000 med en ALGOL 8 oversætter. Fordelene ved at
implementere simulatoren i ALGOL 8 er, at der er ubegrænsede mulighed
for kørsler med simulatoren. Ved en implementering i SIMULA er det
nødvendigt at benytte RECKU som afviklingssted. Dette kræver, at
der skal opnås bevillinger til kørsler her. Da bevillingerne er begrænsede,
og tidligere erfaringer med SIMULA har vist, at det er et forholdvis
dyrt implementeringssprog, var valget ikke helt simpelt.
$np$
Begrundelsen for at vælge SIMULA som implementeringssprog var nu følgende:
$nl$
Der er indhøstet positive erfaringer med brugen af SIMULA. Det har
været anvendt i forbindelse med en del andre simuleringsopgaver. Simuleringsfaciliteterne
i SIMULA er derudover væsentlig bedre end i ALGOL 8. Således er det eksempelvis
ikke muligt at erklære køer
i ALGOL 8.
Hvis køer skal anvendes, skal et rutinesæt
til behandling af disse først implementeres. En simulationsmodel
vil i SIMULA kunne gøres mere simpel end i ALGOL, på grund af
de mange indbyggede rutiner, der findes i SIMULA.
Her kan eksempelvis nævnes, de i SIMULA indbyggede fordelinger og
rutiner til trækning af tilfældige tal.
$ns 1,4,_«bs»2_«bs»._«bs»2_«bs»._«bs»G_«bs»e_«bs»n_«bs»e_«bs»r_«bs»e_«bs»l_«bs»l_«bs»e__«bs»k_«bs»r_«bs»a_«bs»v__«bs»t_«bs»i_«bs»l__«bs»m_«bs»o_«bs»d_«bs»e_«bs»l_«bs»l_«bs»e_«bs»n_«bs».$
$np$
Det fremlægges her , hvilke
elementære fysiske komponenter (ressourcer, processer o.l.)
modellen skal medtage. Alternative udformninger af disse diskuteres og
vægtes.
$np 15$
Herefter skal det datamatiske system, der i første
række ønskes simuleret, beskrives ( for nærmere detaljer se vurderingsopgaven).
$np 15$
En RC8000 tilføres forespørgsler eller "jobs". Disse behandles ved hjælp
af _«bs»4__«bs»p_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs»s_«bs»e_«bs»r, der kører ikke simultant på RC8000.
Processerne betegnes hhv. input-, søge- , opslag- og outputproces.
Derudover er der til systemet koblet 3 diske til hhv. søge- ,opslag- og outputprocessen.

$np 15$
På et givet tidspunkt kan _«bs»4__«bs»j_«bs»o_«bs»b_«bs»s være under afvikling:
$nl$$nl$$lm 25$
$nl$
1 behandles ved inputprocessen
$nl$
1 behandles ved søgeprocessen + associeret disk
$nl$
1 behandles ved opslagsprocessen + associeret disk
$nl$
1 behandles ved outputprocessen + associeret disk
$nl$
$lm 0$
$np 15$
_«bs»E_«bs»g_«bs»e_«bs»n_«bs»t_«bs»l_«bs»i_«bs»g__«bs»p_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs»v_«bs»i_«bs»r_«bs»k_«bs»s_«bs»o_«bs»m_«bs»h_«bs»e_«bs»d__«bs»f_«bs»o_«bs»r_«bs»e_«bs»g_«bs»å_«bs»r__«bs»d_«bs»o_«bs»g__«bs»k_«bs»u_«bs»n__«bs»v_«bs»e_«bs»d__«bs»e_«bs»e_«bs»n__«bs»a_«bs»f__«bs»d_«bs»i_«bs»s_«bs»s_«bs»e
_«bs»(_«bs»i__«bs»e_«bs»t__«bs»g_«bs»i_«bs»v_«bs»e_«bs»n_«bs»t__«bs»ø_«bs»j_«bs»e_«bs»b_«bs»l_«bs»i_«bs»k_«bs»)
_«bs»,__«bs»d_«bs»a__«bs»a_«bs»l_«bs»l_«bs»e__«bs»p_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs»s_«bs»e_«bs»r_«bs»n_«bs»e__«bs»k_«bs»ø_«bs»r_«bs»e_«bs»r__«bs»p_«bs»å__«bs»e_«bs»n__«bs»R_«bs»C_«bs»8_«bs»0_«bs»0_«bs»0_«bs».
Under udførelsen af en proces kan der være en disktransport igang,
og/eller een eller flere diskpositioneringer.
$np 15$
Processerne får tildelt CPU-tid på skift, idet hver proces kører uafbrydligt
i et tidskvant ( 25.6 ms), _«bs»h_«bs»v_«bs»i_«bs»s der er en forespørgsel at behandle,
og behandlingsrækkefølgen kan betragtes som en modificeret ROUND-ROBIN strategi.
Scheduleringsstrategien beskrives grundigt i afsnit 3.
$np 15$
Udover de 4 processer og de 3 associerede diske, skal der til
styring af kommunikationen mellem processerne og diskene findes
en datakanal.De indtil nu nævnte enheder er dem, som indgår i
OP-systemet hos KTAS.
Det betegnes fremover grundmodellen til simulatoren.
$np$
Grundmodellen ønskes implementeret så fleksibel, at det er nemt
at
ændre i modellen.
Ændringerne, der må kunne tilføjes modellen, skal i første
række være, at det må være muligt at dublere de indgående processer.
Den proces det er vigtigst at dublere er søgeprocessen. Ved evalueringen
har det vist sig at søgeprocessen netop er den proces, der benytter mest tid
til behandling af en forespørgsel.
$np$
Udover en dublering af processerne ønskes datakanalen implementeret, så
den også kan dubleres.
Derudover skal der ved scheduleringsstrategien også
være mulighed for at kunne prioritere de enkelte processer.
$np$
At netop disse faciliteter skal implementeres, skal
ses i forbindelse med de forbedringsforslag.
fra forbedringsgevinsten af forslaget.
Som resultat af evalueringen opstilles foreslag til forbedring af
systemets ydeevne, hvor kriteriet for opregningen af forslaget er dets
umiddelbare anvendelse ved KTAS og#eller dets kvantitative indflydelse
på ydeevnen.
De forslag der har
størst virkning vil nok være en dublering af en proces, og et sådant forslag
vil være vanskeligt at tilføje OP-systemet.
$np$
Variationerne i grundmodellen kommende fra dublering af datakanalen og prioritering
af de indgående processer er forslag, det er simpelt at implementere
i OP-systemet. Ved KTAS råder man over en ekstra datakanal som kan tilsluttes
systemet. Prioritering af processerne kan ligeledes implementeres ved ganske få
ændringer ved OP-systemet.
$np$
Udover de ovenfor beskrevne variationer kan grundmodellen af simulatoren
til OP-systemet, bestående af de 4 processer, 3 diske og en datakanal, opfattes
som fast. De forespørgsler, der passerer gennem systemet, følger et på
forhånd givet mønster. Det er derfor valgt at implementere dette mønster
i modellen.
$np$
Et alternativ til at implementere forespørgselsmønsteret i modellen, ville
være at lade forespørgslerne selv "bestemme" vej gennem processystemet. Dette
sidste ville afgjort være en fordel, hvis forespørgselsmønsteret varierer meget,
og en stor variation i antallet af processer skulle foretages.
$np$
De 4 processer
må
anses at være en beskrivelse af, hvilke programdele
systemet består af. Det vil være urealistisk at forestille sig, at der
sker uforholdsmæssigt store ændringer i forbindelse med disse 4 processer.
Ændringer, der kan ske, vil dels kunne
være ovenfor beskrevne dublering af en eller to processer og
dels en opspaltning af de enkelte processer.
$np$
Ved implementeringen af simulatoren valgtes at lægge størst
vægt på at kunne dublere processerne, og
derved blev muligheden for opspaltning af processerne skubbet
i baggrunden.
$np 15$
Styringen af tidskvantallokeringen til de respektive processer kunne
tænkes lavet som et fast programstykke i hver proces.
Efter forbrug af et kvant skulle næste proces, der skal aktiveres,
kaldes explicit fra den netop "færdige" proces.
Det kræver, at programstykket i hver proces er implementeret
til at undersøge de andre processers jobkøer.
(her er evt. placeret forespørgsler _«bs»u_«bs»n_«bs»d_«bs»e_«bs»r behandling
og evt. forespørgsler, der _«bs»v_«bs»e_«bs»n_«bs»t_«bs»e_«bs»r på behandling.)
$np 15$
En smartere løsning implementeres dog ved at introducere
et decideret styringsobjekt, eller ( et noget simpelt)
operativsystem. Når en proces har udnyttet
sit tidskvant, aktiveres operativsystemet, der efter den modificerede
ROUND-ROBIN-strategi
gennemløber processernes jobkøer, startende med processen _«bs»e_«bs»f_«bs»t_«bs»e_«bs»r
den aktuelt kørte, indtil en ikke-tom jobkø findes.
Den løsning, der er implementeret ved KTAS-OP-system,
lader operativsystemet operere med en kø aktive processer,
dvs. processer, der venter på tidskvanter.
$np 15$
Også ved implementering af processerne synes 2 muligheder at vise sig
$lm 25$
$nl$
a) _«bs»h_«bs»v_«bs»e_«bs»r proces afbildes som en SIMULA-PROCES.
$nl$$nl$
b) _«bs»a_«bs»l_«bs»l_«bs»e processer samles i een SIMULA-PROCES, idet
hver proces afbildes, som en SIMULA-PROCEDURE.
$nl$$lm 0$
$nl$
_«bs»A_«bs»D__«bs»a_«bs»)
$lm 25$$nl$
Denne løsning giver yderst overskuelig
afbildning af forespørgselssystemet. Hver proces betragtes,
som en (fysisk) selvstændig proces, der altså i princippet godt kunne køre
tidssimultant med de andre processer. Dette er dog ikke nødvendigt,
da OP-systemet ikke er opbygget til at gøre dette.
$lm 0$
$nl$$nl$
_«bs»A_«bs»D__«bs»b_«bs»)
$lm 25$
$nl$
Netop fordi de 4 processer _«bs»i_«bs»k_«bs»k_«bs»e kører egentlig tidssimultant
kunne en ganske ligefrem og tilstrækkelig løsning være at lade
en SIMULA-PROCEDURE simulere hver proces.
$lm 0$
$np 15$
Ud fra en fleksibilitetsbetragtning bør alternativ a nok foretrækkes,
idet kommunikationen med de tidssimultane pladelagre mest
simpelt implementeres i tilfælde a. Alternativ a åbner også op for eksperimenter
med ægte tidssimultan kørsel.
$np 15$
Begrebsmæssigt føler vi ligeledes, at det er godt at understrege processernes
tidsmæssige aspekt, ved det mere overordnede PROCESS-begreb-forbrug
af tid ved en proces sidestilles med forbrug af tid ved en disk eller
et styringsobjekt.
$nl$$nl$$nl$
$ns 1,4,_«bs»2_«bs»._«bs»3_«bs»._«bs»E_«bs»v_«bs»a_«bs»l_«bs»u_«bs»e_«bs»r_«bs»i_«bs»n_«bs»g__«bs»a_«bs»f__«bs»f_«bs»o_«bs»r_«bs»e_«bs»l_«bs»i_«bs»g_«bs»g_«bs»e_«bs»n_«bs»d_«bs»e__«bs»s_«bs»i_«bs»m_«bs»u_«bs»l_«bs»a_«bs»t_«bs»o_«bs»r_«bs»t_«bs»y_«bs»p_«bs»e_«bs»r_«bs».$
$nl$
$np 15$
I forbindelse med et tidligere kursus ved datalogistudiet "Vurdering
af datamatiske systemers præstation og ydeevne" afholdt i 1979/80,
blev der af kursisterne udviklet nogle simulatorer, der skulle belyse
forskellige aspekter ved simulering.
Da de systemer, der afbildedes har lighed med det foreliggende
OP-system, var det naturligt at udnytte erfaringerne fra de allerede
konstruerede simulatorer. Dette afsnit forklarer, hvad
disse simulatorer brugtes til, og hvilke konfigurationer de
simulerede.
$np$
I dette afsnit vurderes således 3 simulatorer fra ovennævnte
kursus med henblik på at opfylde kravene til en OP-simulator.
Det må fremhæves, at kriteriet for vurderingen af disse
udelukkende er graden af anvendelighed i denne konkrete sammenhæng.
De 3 simulatorer vil blive beskrevet for at vise deres struktur, og
især funktion. Karakteristika fremdrages og svagheder/styrken
af disse facetter vurderes i forhold til det ønskede mål.
$np$
De
betragtede simulationsmodeller har behandlet aspekter så som ( se ref Ferrari):
$nl$$nl$
_«bs»m_«bs»o_«bs»d_«bs»e_«bs»l_«bs»t_«bs»y_«bs»p_«bs»e_«bs»:
MARKOV, kømodel, åben netværk
$nl$$nl$
_«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»:
Preemptive, non-preemptive
$nl2$
Desuden har generelle teknikker for måling og simulering været anvendt på
forskellige konfigurationer.
$np 15$
Den grundliggende konfiguration har været den simple hard-ware-konfiguraion
illustreret i figur 2.3.1.
$nl20$
figur 2.3.1.
$nl$$nl$$nl$
$np 15$
I forbindelse med gennemgangen af de 3 simulatorer er det imidlertid ikke så meget
valg af konfiguration, og forskellige implementeringer af denne, der er
interessant, som den funktionelle side af simulatorene. Dvs. hvorledes
"kommunikerer" simulatorens enkeltdele (PROCESS'er, PROCEDURE'r m.m.)
med hinanden, hvad får tiden til at gå, og hvorledes sker det ?
$np 15$
Programmeringssproget for alle 3 typer er SIMULA.
For hver af de 3 simulatortyper vil der dog være en kort beskrivelse
af hovedkomponenterne og en forklaring af, i hvilken sammenhæng denne
konfiguration er opstillet.
$np 15$
De 3 simulatorers ophavsmænd er:
$lm 25$
$nl$$nl$
_«bs»N_«bs»o__«bs»1_«bs»:
Sven Larsen og Viggo Nis Kørst ( samt delvis medarbejde af Poul Erik Andersen )
$nl$$nl$
_«bs»N_«bs»o__«bs»2_«bs»:
Bernd Homann
$nl$$nl$
_«bs»N_«bs»o__«bs»3_«bs»:
Jesper Lund og Henrik Lund Nielsen.
$lm 0$
$np 15$
Vi vil nu gennemgå disse 3 simulatorrer i nævnte rækkefølge.
$nl$$nl$$nl$
$ns 1,4,_«bs»2_«bs»._«bs»3_«bs»._«bs»1_«bs»._«bs»E_«bs»v_«bs»a_«bs»l_«bs»u_«bs»e_«bs»r_«bs»i_«bs»n_«bs»g__«bs»a_«bs»f__«bs»s_«bs»i_«bs»m_«bs»u_«bs»l_«bs»a_«bs»t_«bs»o_«bs»r_«bs»t_«bs»y_«bs»p_«bs»e__«bs»1_«bs».$
$nl$$nl$
_«bs»K_«bs»O_«bs»N_«bs»F_«bs»I_«bs»G_«bs»U_«bs»R_«bs»A_«bs»T_«bs»I_«bs»O_«bs»N_«bs»:
$np$
Den konfiguration, der betragtes ved denne simulatortype, er
en SIMULA-baseret afbildning af konfigurationen på figur 2.3.1.
Det bemærkes at det grundlæggende system i figur 2.3.1, i forhold til
KTAS's OP-system er udstyret med processor til tromle og I/O-enheder.
Simulatortype 1 er afbildet i sin logiske opbygning i figur 2.3.2. Primærlageret er
markeret som en stiplet enhed, idet det i denne model ikke eksplicit er repræsenteret ved
nogen SIMULA-type (CLASS f.eks.). Begrebsmæssigt kan de 7 indholdte køer, dog betragtes som et fælles kommunikationsområde i primærlageret.
$nl20$
$sj$
figur 2.3.2.
$rj$$nl$
_«bs»T_«bs»r_«bs»o_«bs»m_«bs»l_«bs»e afbildes ved CLASS DRUMPROCESSOR
og 2 køer DRUMQ,OUTDRUMQ, der indeholder "JOBS", der hhv. venter
på og er færdige med tromlebehandling.
At tromlen også har en "færdigkø", hænger sammen med afviklingsmåden i denne simulatortype, se under simulatorens virkemåde.
$nl$$nl$
_«bs»P_«bs»l_«bs»a_«bs»d_«bs»e_«bs»l_«bs»a_«bs»g_«bs»r_«bs»e
afbildes ved CLASS DISCPROCESSOR og 2 køer DISQ,OUTDISQ, der indeholder
"JOBS", der hhv. venter på og er færdige med pladelagerbehandling.
Samme forhold gør sig gældende med hensyn til "færdigkø".
$nl$$nl$
_«bs»C_«bs»P_«bs»U
afbildes ved CLASS CENTRALPROCESSOR og 1 kø CPUQ, der indeholder
"JOBS" under behandling ved centralprocessoren.
$nl$$nl$
_«bs»I_«bs»n_«bs»p_«bs»u_«bs»t_«bs»/_«bs»o_«bs»u_«bs»t_«bs»p_«bs»u_«bs»t_«bs»e_«bs»n_«bs»h_«bs»e_«bs»d_«bs»e_«bs»r
afbildes ved CLASS IOPROCESSOR og 2 køer, INPUTBUFFER,OUTPUTBUFFER,
der indeholder "JOBS", der hhv. skal have bestemt sit første
ressourcekrav og skal forlade simulatormodellen.
$nl$$nl$
_«bs»S_«bs»t_«bs»y_«bs»r_«bs»e_«bs»e_«bs»n_«bs»h_«bs»e_«bs»d
("Operativsystem") afbildes ved CLASS OPSYS.
$nl$$nl$$nl$
Endvidere sker jobgenereringen ved CLASS JOBGENERATOR, og de enkelte "JOBS"
ressourceforbrug - og rækkefølge afspejles af CLASS JOB.
_«bs»S_«bs»I_«bs»M_«bs»U_«bs»L_«bs»A_«bs»T_«bs»O_«bs»R_«bs»E_«bs»N_«bs»S__«bs»V_«bs»I_«bs»R_«bs»K_«bs»E_«bs»M_«bs»Å_«bs»D_«bs»E
$nl$$nl$
For programtekst se bilag 2.1.
Job tilføres modellen i CLASS JOBGENERATOR f.eks. med en
eksponentiel mellemankomsttid. Herefter aktiverer JOBGENERATOREN
selve JOB'et..
$nl$$nl$
JOB indeholder en række jobtrin, hvor hvert trin består af 2 oplysninger:
$sj$

1) ressourcetype (Eks. CPU,DRUM )

2) ressourcetidsforbrug

$rj$
$np$
Jobtrinnets karakteristika aflæses af operativsystemet(CLASS OPSYS), hvorefter
JOB passiveres (PASSIVATE).
$np 15$
Idet vi udelader befordringen af JOB via IOPROCESSOREN indsættes jobbet i kø til
CLASS CPU (afspejlende at centralenheden skal afgøre, hvilke ressourcer,der skal benyttes af jobbet).
$np 15$
CPU'en og _«bs»k_«bs»u_«bs»n denne
aktiverer operativsystemet CLASS OPSYS, enten fordi et job har fået sin
tilmålte CPU-tid eller CPU'en er blevet underrettet om, at en af
ressourcerne CLASS DISCPROCESSOR eller CLASS DRUMPROCESSOR
_«bs»h_«bs»a_«bs»r__«bs»a_«bs»f_«bs»s_«bs»l_«bs»u_«bs»t_«bs»t_«bs»e_«bs»t en transport,
hvilket meddeles i køerne OUTDISCQ eller OUTDRUMQ.
$np 15$
OPSYS aktiveres for at finde jobbets "NYE" ressourcetype - "ny" fordi et
CPU-tidsforbrug godt kan efterfølges af et nyt CPU-tidsforbrug.
OPSYS undersøger, hvilke hændelser, der ligger til grund for aktiveringen,
idet køerne (OUTDISCQ,OUTDRUMQ,INPUTBUFFER og CPUQ)
undersøges for "færdige" jobtrin.
$np 15$
V.h.a. en procedure i OPSYS, kaldet NEXTEVENT, bestemmes nu næste type ressource og
jobbet sættes rigtigt i kø (DISCQ,DRUMQ eller CPUQ)
til pågældende ressource.
$np 15$
Endelig aktiveres ressourcen explicit, undtagen for CPU, der altid afvikler.
CPU'en "afvikler"
afspejlende 3 forskellige situationer:
$lm 25$
$nl$$nl$
1)_«bs»J_«bs»o_«bs»b_«bs»b_«bs»e_«bs»t benytter centralenheden (simulerer egentlig udførelse)
$nl$
2)_«bs»o_«bs»p_«bs»e_«bs»r_«bs»a_«bs»t_«bs»i_«bs»v_«bs»s_«bs»y_«bs»s_«bs»t_«bs»e_«bs»m_«bs»e_«bs»t benytter centralenheden ( simulerer overhead )
$nl$
3)_«bs»s_«bs»i_«bs»m_«bs»u_«bs»l_«bs»a_«bs»t_«bs»o_«bs»r_«bs»e_«bs»n benytter centralenheden ( simulerer tidsrum,
hvor "det tomme system" kører, dvs. når hverken job eller
operativsystem benytter CPU-en).
$lm 0$
$nl$$nl$
$nl$$nl$
_«bs»K_«bs»O_«bs»M_«bs»M_«bs»E_«bs»N_«bs»T_«bs»A_«bs»R_«bs»E_«bs»R
$np 15$
Det principielt vigtige i denne model er den underliggende kvantfilosofi,
der sikrer, at for hvert tidskvant, bliver CPU'en aktiv, hvad enten jobbene
, operativsystemet eller "det tomme system" er under afvikling.
$np 15$
Det problematiske ( både generelt og specifikt m.h.t.
implementering af en simulator til KTAS) er:
$lm 25$
$nl$$nl$
1) at tiden for CLASS OPSYS, operativsystemet ikke simuleres brugt i OPSYS,
men i CLASS CPU.
Selvfølgelig benytter operativsystemet centralenheden, når det kører,
men rent strukturmæssigt er det naturligt at lade hver CLASS, styre sig eget tidsforbrug.
$nl$$nl$
2) at CPU'en også simulerer den tid, hvor ingenting sker i systemet
(fremfor at simulatoren tidsmæssigt springer til næste aktive PROCESS)
$nl$$nl$
3) at simulatoren derfor bliver kostbar i real tid, da tidskvanterne
nødvendigvis må være ganske små, hvis ikke simulatorens fejlvisning p.g.a.
henholdt "interrupt" fra CLASS DRUM,DISK og CPU skal blive for stor.
$lm 0$
$nl$$nl$
_«bs»K_«bs»O_«bs»N_«bs»K_«bs»L_«bs»U_«bs»S_«bs»I_«bs»O_«bs»N
$np 15$
Modellen er realistisk forsåvidt angår kvantfilosofien,
der til gengæld er meget dyr i real tid. Modellen er forholdvis simpelt
opbygget, men samspillet OPSYS og CPU er ikke tilfredsstillende.
Tiden i OPSYS bør simuleres anvendt i denne CLASS, som det ellers gøres i
de andre CLASS'er.
$np 15$
Modellen må, p.g.a. at OP-systemet hos KTAS stiller krav om behandling af
store datamængder, siges at være uegnet i den forbindelse.
$nl$$nl$$nl$
$ns 1,4,_«bs»2_«bs»._«bs»3_«bs»._«bs»2_«bs»._«bs»E_«bs»v_«bs»a_«bs»l_«bs»u_«bs»e_«bs»r_«bs»i_«bs»n_«bs»g_«bs»s__«bs»a_«bs»f__«bs»s_«bs»i_«bs»m_«bs»u_«bs»l_«bs»a_«bs»t_«bs»o_«bs»r__«bs»t_«bs»y_«bs»p_«bs»e__«bs»2_«bs».$
$nl$$nl$
_«bs»K_«bs»O_«bs»N_«bs»F_«bs»I_«bs»G_«bs»U_«bs»R_«bs»A_«bs»T_«bs»I_«bs»O_«bs»N
$nl$$nl$
Modellen består af følgende komponenter:
$nl$
1) En jobafvikler
$nl$
2) En CPU-processor
$nl$
3) En tromle-processor
$nl$
4) En pladelager-processor
$nl$
5) En jobgenerator
$nl$
6) En job beskrivelse
$nl$
7) 5 dobbelthægtede lister: Jobkø, aktivkø, cpukø, tromlekø og
pladekø.
$np$
Figur 2.3. viser sammenhængen mellem komponenterne i
udarbejdede simulationsmodel.
$nl$
$np$
Figur 2.3 skal forstås således: En pil fra komponent X til komponent Y
betyder, at der flyder information fra komponent X til komponent Y.
Informationsstrømmen består af jobbeskrivelser (JOB). Modellen arbejder
på 5 jobkøer: JOBKØ, AKTIVKØ, CPUKØ, TROMLEKØ og PLADEKØ, på
3 processer (dvs. jobkøafviklere): CPUPROCESSOR, TROMLEPROCESSOR og
PLADEPROCESSOR, en jobgenerator JOBGEN samt en jobafvikler
(operativsystem) JOBAFVIKLER.
$nl$
Ovenstående er taget fra Bernd Homann rapport nr. 1 side 10-11.
$sj$
figur 2.3
$rj$
Det bemærkes, at operativsystemet OPSYS i den forrige simulator
her er erstattet af CLASS JOBAFVIKLER, der også her fungerer som et mini-operativsystem.
$nl$$nl$
_«bs»S_«bs»I_«bs»M_«bs»U_«bs»L_«bs»A_«bs»T_«bs»O_«bs»R_«bs»E_«bs»N_«bs»S__«bs»V_«bs»I_«bs»R_«bs»K_«bs»E_«bs»M_«bs»Å_«bs»D_«bs»E
$np 15$
For programtekst se bilag 2.2.
Job tilføres modellen i CLASS JOBGENERATOR.
$nl$$nl$
$np$
Herefter aktiveres CLASS JOB, der indsætter jobbet i IOKØ og
passivere sig selv. Jobgeneratoren aktiverer herefter CLASS IOPROCESSOR
der simulerer indlæsningstid til kø i indre lager AKTIVKØ.
IO-enheden aktiverer herefter operativsystemet CLASS JOBAFVIKLER.
JOBAFVIKLER besørger afviklingen af jobbene i det indre lager, idet
køen af _«bs»a_«bs»k_«bs»t_«bs»i_«bs»v_«bs»e jobs AKTIVKØ gennemløbes cyklisk, og job hægtes op til en
ønsket processor i pågældende processkø.
$np 15$
For at afspejle tidsforbruget i operativsystemet, der kører på CPU'en, stoppes
CPU-processorens tid anvendt for jobprocessing, og der simuleres i JOBAFVIKLEREN
et tidsforbrug allokeret til operativsystemet. Under
operativsystemsperioden er CLASS CPU blevet "CANCEL'et"(passiveret af
JOBAFVIKLER), og CPU aktiveres først når JOBAFVIKLER er færdig.
$np 15$
Den ønskede processor bestemmes ud fra CLASS JOB,
der beskriver et job m.h.t. ressourcekrav og ressourcetidsforbrug.
Jobbet indsættes i ressourcens kø, ressourcen
aktiveres, og jobbet passiveres.
Jobbet aktiveres, når det engang efter evt. køventetid og ressourtcetidsforbrug
er klar til at beskrive sine nye ressourcekrav.
$nl$$nl$
_«bs»K_«bs»O_«bs»M_«bs»M_«bs»E_«bs»N_«bs»T_«bs»A_«bs»R
$np 15$
Den vigtigste forskel på denne simulatortype og den forrige er naturligvis
opbygningen af operativsystemet. Her aktiveres (interruptes) JOBAFVIKLER,
når et job skal hægtes op til en ny ressource ( evt. samme for CPU-processor).
Denne simulator undgår ud over at CPU'en skal "kvante" sig igennem,
mens modellen indeholder job under behandling af centralenheden, også
at skulle simulere "CPU ledig", og
det må klart siges at være til type 2's fordel.
$nl$$nl$
_«bs»K_«bs»O_«bs»N_«bs»K_«bs»L_«bs»U_«bs»S_«bs»I_«bs»O_«bs»N
$np 15$
Denne simulatortype er alt i alt fornuftigt opbygget,
med et lidt omstændigt præg. Efter vores mening kan den udmærket
ved implementering af den rette KTAS-konfiguration anvendes til at simulere
denne.
$np 15$
Det der gør denne type lidt tung er den omfattende
programmering i CLASS JOB, der skal afbilde en efterspørgsel ( et jobs)
samtlige muligheder for procesvalg.
$nl$$nl$$nl$
$ns 1,3,_«bs»2_«bs»._«bs»4_«bs»._«bs»3_«bs»._«bs»E_«bs»v_«bs»a_«bs»l_«bs»u_«bs»e_«bs»r_«bs»i_«bs»n_«bs»g__«bs»a_«bs»f__«bs»s_«bs»i_«bs»m_«bs»u_«bs»l_«bs»a_«bs»t_«bs»o_«bs»r_«bs»t_«bs»y_«bs»p_«bs»e__«bs»3_«bs».$
$nl$$nl$
_«bs»K_«bs»O_«bs»N_«bs»F_«bs»I_«bs»G_«bs»U_«bs»R_«bs»A_«bs»T_«bs»I_«bs»O_«bs»N__«bs»O_«bs»G__«bs»V_«bs»I_«bs»R_«bs»K_«bs»E_«bs»M_«bs»Å_«bs»D_«bs»E
$np 15$
For programtekst se bilag 2.3.
Denne model er udviklet til at kunne simulere et stor varietet
af _«bs»n_«bs»e_«bs»t_«bs»v_«bs»æ_«bs»r_«bs»k_«bs»s_«bs»m_«bs»o_«bs»d_«bs»e_«bs»l_«bs»l_«bs»e_«bs»r
såvel åbne,
hvor jobs tilføjes modellen af en kilde udenfor netværket som
lukkede, hvor modellen indeholder et konstant antal jobs
, dvs. modellen har et vist generelt tilsnit.
$np 15$
Netværket i simulatoren bygges implicit op v.h.a.
en TRANSITION-matrix, der beskriver overgangssandsynligheder
fra knudepunkt til knudepunkt i netværket.
I denne opgave er knudepunkterne servicecentre, men de kan ligesåvel
opfattes som repræsentationer af processer.
$np 15$
Simulatormodellens elementer er samlet i CLASS NETWORK,
der indeholder nedenstående CLASS-komponenter. NETWORK
har _«bs»a_«bs»n_«bs»t_«bs»a_«bs»l_«bs»l_«bs»e_«bs»t
af servicecentre som parametre.
CLASS-komponenter:
$nl$$nl$$sj$
CLASS SERVICECENTER

CLASS SERVER

CLASS SOURCE

CLASS LOADER

CLASS FINISH

CLASS JOB
$rj$$nl$
_«bs»C_«bs»L_«bs»A_«bs»S_«bs»S__«bs»S_«bs»E_«bs»R_«bs»V_«bs»I_«bs»C_«bs»E_«bs»C_«bs»E_«bs»N_«bs»T_«bs»E_«bs»R
er prefix til CLASS SERVER og CLASS FINISH, dvs. indeholder de overordnede
begreber for de 2 klasser, der er 2 forskellige typer af servicecentre.
SERVICENTER består af en kø til de job, der skal behandles ved det pågældende
servicecenter. Når et job skal have service ved et nyt center, bestemmes v.h.a.
overgangsmatricen centeret, og en procedure REQUEST sætter jobbet i dette
centers kø.
$nl$$nl$
_«bs»C_«bs»L_«bs»A_«bs»S_«bs»S__«bs»S_«bs»E_«bs»R_«bs»V_«bs»E_«bs»R
simulerer det egentlige servicecenters aktiviteter såsom: tag første job
i ventekø, bestem servicetid og simuler afvikling, hvorefter
CLASS SERVICECENTER kaldes for at befordre jobbet videre, som ovenfor beskrevet.
$nl$$nl$
_«bs»C_«bs»L_«bs»A_«bs»S_«bs»S__«bs»F_«bs»I_«bs»N_«bs»I_«bs»S_«bs»H
ligeledes prefixet med SERVICECENTER, fungerer som måle-
og statistikobjekt.
$nl$$nl$
_«bs»C_«bs»L_«bs»A_«bs»S_«bs»S__«bs»S_«bs»O_«bs»U_«bs»R_«bs»C_«bs»E__«bs»o_«bs»g__«bs»C_«bs»L_«bs»A_«bs»S_«bs»S__«bs»L_«bs»O_«bs»A_«bs»D_«bs»E_«bs»R
bruges som jobgenerator ved henholdsvis åbent og lukket
netværk.
$nl$$nl$
_«bs»C_«bs»L_«bs»A_«bs»S_«bs»S__«bs»J_«bs»O_«bs»B
er prefixet med SIMULA-klassen LINK, således
at de generede jobs kan anbringes i servicecentrenes behandlingskøer.
Klassen indeholder iøvrigt kun attributter, nemlig et jobnummer og jobbets ankomsttid
til systemet.
$nl$$nl$$nl$
_«bs»K_«bs»O_«bs»M_«bs»M_«bs»E_«bs»N_«bs»T_«bs»A_«bs»R
$np 15$
Tilsyneladende er ideen med en matrix af overgangssandsynligheder i stand til at gøre modellen
meget fleksibel, specielt når et job kan følge "mange veje".
$np 15$
På den måde som simulatortype 3 laver denne administration,
undgås både at gøre jobbet til et klodset objekt, der hele tiden kaldes
for at bestemme vej gennem netværket(hvilket er tilfældet for de 2 tidligere betragtede typer),
samt at lade processerne
(her SERVICECENTER'NE) tage sig af en explicit vejfinding.
$nl$$nl$
_«bs»K_«bs»O_«bs»N_«bs»K_«bs»L_«bs»U_«bs»S_«bs»I_«bs»O_«bs»N
$np 15$
Alt i alt forekommer denne model at være ganske
formålstjenlig. Det kan bemærkes, at vi inden denne sammenlignende analyse,
havde udarbejdet et skitseforslag til en simulatortype, der på mange punkter
var sammenfaldende med simulatortype 3.
$np 15$
Modellen forekommer at være den bedst egnede af de 3 beskrevne med henblik på
den specielle applikation. Modellen er overskuelig, logisk opbygget og "billig i
drift", når der ses på realtids-forbrug.
$ns 1,4,_«bs»2_«bs»._«bs»4_«bs»._«bs»V_«bs»a_«bs»l_«bs»g__«bs»a_«bs»f__«bs»s_«bs»i_«bs»m_«bs»u_«bs»l_«bs»a_«bs»t_«bs»o_«bs»r_«bs»t_«bs»y_«bs»p_«bs»e_«bs».$
$np 15$
Generelt har vi under udviklingen af simulatoren lagt vægt på følgende punkter:
$nl$$nl$$sj$
- simpel logisk struktur og funktion

- hurtighed ( i realtid)

- minimal (tilstrækkelig !) detaljeringsgrad

- udstrakt brug af parametre

$rj$
$np 15$
Da forrige underafsnit konkluderede, at simulatortype 3 syntes
at være en løsning, der tilfredsstillede
de fleste grundkrav, man kunne stille til simulatoren til brug ved simulering af OP-systemet
har vi bygget den foreliggende simulator op omkring type 3's hovedideer.
$np 15$
De punkter, vi derefter har kunnet arbejde med, har været detaljeringsgrad,
Dette beskrives i næste afsnit.
Om brugen af parametre kan siges, at det har været efterstræbt at gøre denne total.
$rh 1,BEGRÆNSNINGER VED VALGTE SIMULATIONSMODEL$
$ps0$
$ns 1,4,_«bs»3_«bs»._«bs»M_«bs»o_«bs»d_«bs»e_«bs»l_«bs»l_«bs»e_«bs»n_«bs»s__«bs»d_«bs»e_«bs»t_«bs»a_«bs»l_«bs»j_«bs»e_«bs»r_«bs»i_«bs»n_«bs»g_«bs»s_«bs»g_«bs»r_«bs»a_«bs»d_«bs».$
Dette afsnit beskriver først, hvilke begrænsninger der findes ved simulatoren
i forhold til en RC8000. Derefter beskrives så i næste afsnit, hvilke
dele af RC8000 der er lagt størst vægt på at simulere. Ud fra
betragtningerne i dette afsnit vil selve detaljeringsgraden af simulatoren
fremgå.
$ns 1,4,_«bs»3_«bs»._«bs»1_«bs»._«bs»B_«bs»e_«bs»g_«bs»r_«bs»æ_«bs»n_«bs»s_«bs»n_«bs»i_«bs»n_«bs»g_«bs»e_«bs»r__«bs»i__«bs»v_«bs»a_«bs»l_«bs»g_«bs»t_«bs»e__«bs»s_«bs»i_«bs»m_«bs»u_«bs»l_«bs»a_«bs»t_«bs»i_«bs»o_«bs»n_«bs»s_«bs»m_«bs»o_«bs»d_«bs»e_«bs»l_«bs».$
$np$
Den valgte simulationsmodel afspejler naturligvis ikke alle
facetter ved OP-systemet. Dette afsnit vil redegøre for, hvilke
begrænsninger der er foretaget ved konstruktionen af simulatoren,
i forhold til, hvordan en RC8000 ved OP-systemet fungerer.
$nl2$
_«bs»1_«bs»)__«bs»L_«bs»a_«bs»g_«bs»e_«bs»r_«bs»s_«bs»t_«bs»ø_«bs»r_«bs»r_«bs»e_«bs»l_«bs»s_«bs»e_«bs»n__«bs»a_«bs»f__«bs»d_«bs»e__«bs»e_«bs»n_«bs»k_«bs»e_«bs»l_«bs»t_«bs»e__«bs»p_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs»s_«bs»e_«bs»r__«bs»a_«bs»f_«bs»b_«bs»i_«bs»l_«bs»d_«bs»e_«bs»s__«bs»i_«bs»k_«bs»k_«bs»e_«bs»._
$np$
Når et system som OP-systemet implementeres på en RC8000, er det nødvendigt at beslutte, hvor
stort et lagerområde hver enkelt proces kan optage.
Denne lagerstørrelse vil have indflydelse
på hastigheden, hvormed de indgående processer kan behandle en forespørgsel. Normalt
vil lagerstørrelsen således være en særdeles vigtig faktor, når hurtighed af en proces skal vurderes.
Da OP-systemet er implementeret i form af 4 processer, der permanent befinder sig
i lageret, er det besluttet ikke at simulere lagerstørrelsens indflydelse
på udførelsestiden. Dette skyldes, at vi går ud fra at
da man implementerede OP-systemet på RC8000, blev processtørrelsen for de indgående
processer valgt så optimalt som muligt.
$np$
Lagerstørrelsen indgår ikke i simulatoren som direkte variabel størrelse,
men lagerstørrelsens indflydelse på udførelsestiden kan varieres indirekte,
idet en facilitet som dublering af søgeprocessen bliver indført. En dublering
af søgeprocessen vil kræve endda meget mere lager
på en RC8000, for at
OP-systemet kan køre.
$nl2$
_«bs»2_«bs»)__«bs»B_«bs»e_«bs»g_«bs»r_«bs»æ_«bs»n_«bs»s_«bs»n_«bs»i_«bs»n_«bs»g_«bs»e_«bs»r__«bs»v_«bs»e_«bs»d__«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$
Hvordan den modificerede form for ROUND-ROBIN scheduleringsstrategi virker,
er
præcist beskrevet i afsnit 3 i vurderingsopgaven. Da det er særdeles vigtigt
at forstå, hvordan den fungerer vil de vigtigste ting blive fremhævet her.
Endvidere vil det blive forklaret og begrundet,
hvordan der scheduleres i simulatoren.
Det bør fremhæves, at det ikke ved simulatoren har været
muligt præcist at simulere den på RC8000 anvendte scheduleringsstrategi.
$np$
Formålet med sheduleringsstrategien er dels at sikre at ingen proces
monopoliserer en ydre enhed og dels at udnytte de ydre enheder bedst muligt.
Det skal her anføres, at vi ikke føler os helt overbeviste om, hvordan
strategien på RC8000 fungerer. Ved konsultation med forskellige eksperter i monitoren til
en RC8000, er vi dog nået frem til et billede af strategien.
Det bemærkes, at det i afsnit 6 om valideringsforløbet er beskrevet,
hvordan simulatoren først udvikledes med en streng ROUND-ROBIN-strategien. Resultaterne
her viste dog ikke tilstrækkelig overenstemmelse med målingerne på OP-systemet,
så det var nødvendigt at implementere den modificerede form for ROUND-ROBIN.
Begrundelsen for at vi ikke føler os sikre i forståelsen af scheduleringsstrategien
er en noget mangelfuld beskrivelse af den i manualer fra RC. (Dette
er beskrevet mere konkret i afsnit 6).
$np$
For at forklare scheduleringsstrategien er det nødvendigt at
forstå, hvilken tilstand en proces kan være i. En proces kan være
i følgende tilstande:
$sj$

1.Kørende
2.Ventende på at blive kørende
3.Passiv
$rj$$nl$
Til processerne eksisterer en fælles kø som fremover betegnes aktivkøen,
hvori processer i tilstand 1 og 2 findes. Det er processernes rækkefølge i denne kø,
der alene bestemmer rækkefølgen af afviklingen af processerne.
$np$
Den kørende proces er første proces i aktivkøen, og når denne proces
bliver afbrudt tages processen enten ud af køen og placeres bagest eller den
bliver stående på sin plads i køen.
Derudover tages processen helt ud af køen,
hvis den for øjeblikket ikke har mere at udføre, f.eks. fordi
den beder om information fra disken.
$sb ^,6$
$nl$
En proces kan blive afbrudt af følgende grunde:
$lm20$$nl$
$lt 1,^^^^1)$
Af klokken, fordi den har kørt en hel tidsskive(25.6 ms). Klokken afbryder
endvidere alle kørende processer for hvert 25.6 ms.
$nl$$lt 1,^^^^2)$
Der kommer et interrupt fra en ydre enhed.
$lm0$$nl$
Afgørelsen for om processen omplaceres i aktivkøen, er en størrelse der betegnes
"timequantum".( Oversættes i det følgende med tidskvant, men må absolut ikke
forveksles med en tidsskive som altid er 25.6 ms).
Når en proces afbrydes tildeles tidskvant værdien for den tid
processen har brugt siden den kørende proces blev afbrudt plus dens tidligere
værdi af tidskvant.
Hvis tidskvantet herved bliver større end en tidsskive tages
processen ud af aktivkøen og indsættes bagest.
Derudover sættes dens tidskvant til 0.
$np$
Hvis derimod tidskvantet for den kørende proces er mindre end en tidsskive beholder
processen sin plads i aktivkøen.
$np$
Da en kørende proces afbrydes hver gang et interrupt fra en ydre enhed kommer, kan
dette interrupt stamme fra en anden proces end den kørende. Processen, interruptet
er beregnet til, skal nu også indsættes i aktivkøen. Dette gøres efter samme
princip som angivet ovenfor. Dvs. hvis processens tidskvant er
mindre end en tidsskive indsættes den forrest ellers indsættes den bagest.
$np$
Denne komplicerede scheduleringsstrategi har det ikke været muligt helt
præcist at simulere. Inden en forklaring af grunden til dette vil
to eksempler blive givet. Det første eksempel illustrerer den "rigtige"
strategi, og det andet illusterer, hvordan strategien ved simulatoren er.
$nl2$
_«bs»E_«bs»k_«bs»s_«bs»e_«bs»m_«bs»p_«bs»e_«bs»l__«bs»1_«bs».
$np$
Antag at der i aktivkøen findes 3 processer A,B og C. På figur 3.1 er angivet
3 tidslinier. En skravering af tidslinien angiver, at processen
benytter CPU-en og dermed er kørende.
$nl10$
$sj$
figur 3.1
$rj$$nl$
Det antages, at processerne er indføjet således, at rækkefølgen i aktivkøen
til tiden 0 er
A,B,C.
Proces A bliver kørende først, og anvender en tidsskive. Derefter bliver den afbrudt
af klokken. Tidskvant for A er så 25.6 ms og da dette ikke er mindre end en tidsskive
bliver proces A sat bagest i aktivkøen. (Aktivkø: B,C,A). Derefter bliver B kørende
, og efter at der er gået 14.4 ms skal B anvende pladelageret. (Det antages,
at denne pladelagertilgang tager 42.0 ms.)
B tages ud af aktivkøen. (aktivkø: C,A) Derefter bliver C kørende. Efter
der er gået 11.2 ms bliver C afbrudt af klokken. Da C kun har kørt 11.2 ms
(= tidskvant for C), bliver C stående forrest i aktivkøen, og bliver igen kørende.
(Aktivkø: C,A). Ved tiden 72.0 er disken færdig til proces B, og der kommer
et interrupt til proces B.
Proces C bliver derfor afbrudt, og den har kørt i 20.8 ms. Dens tidskvant
bliver så sat til 20.8+11.2 = 32.0, og den bliver derfor placeret bagest i
aktivkøen. B tidskvant er mindre end en tidsskive, og den indsættes
forrest. (Aktivkø: B,A,C). B kører nu i 4.8 ms, og bliver derefter afbrudt
af klokken. Den tidskvant bliver ved afbrydelsen 14.4+4.8= 19.2 ms, hvilket er
mindre end en tidsskive. Den bliver derfor indsat forrest i aktivkøen.
(Aktivkø: B,A,C).
Derefter tildeles B en tidsskive. (Aktivkø: A,C,B). Det foregår _
ækvivalent videre.
$nl3$
_«bs»E_«bs»k_«bs»s_«bs»e_«bs»m_«bs»p_«bs»e_«bs»l__«bs»2_«bs».
$np$
Scheduleringsstrategien ved simulatoren adskiller sig nu ved, at en
proces kun kan afbrydes af klokken. For at konpensere lidt for dette
indsættes processerne dog rigtigt i køen, hver gang et interrupt ankommer.
En proces, der skulle have været aktiv ved interruptets afsendelse,
må altså vente til den kørende proces afbrydes af klokken eller
afsluttes.
$nl15$
$sj$
figur 3.2
$rj$$nl$
Startforudsætningerne ved dette eksempel er
præcist de samme som ved eksempel 1. Proces A kører en tidsskive, og afbrydes af
klokken. Den tages ud af aktivkøen og placeres bagest. (Aktivkø: B,C,A). B
kører derefter 14.4 ms og skal benytte pladelageret. Den tages derfor ud
af aktivkøen. (Aktivkø: C,A). C kører i 11.2 ms og bliver afbrudt af
klokken. Da dens tidskvant er mindre end en tidsskive får den tildel
en hel tidsskive, og kører til tiden 76.8. I mellemtiden er B's pladelagertilgang
færdig og B indsættes i aktivkøen efter C. Medens C kører fra tiden 51.2 til
76.8 er aktivkøen ved interruptet fra færdiggørelsen af B's pladelagertilgang
blevet sat til ( C,B,A). Ved 76.8 blive C taget ud og sat ind bagest og B
bliver kørende. Herefter fortsættes præcist som ved eksempel 1.
$nl2$
Begrundelsen for ikke at kunne afbryde en proces fra andet end klokken i simulatoren, er
at det er vanskeligt at implementere det pænt i SIMULA. Strategien kan kun implementeres ved
at lade tiden gå i meget små tidsenheder. Ved dette bliver simulatoren særdeles
dyr i drift.
$nl2$
_«bs»3_«bs»)__«bs»A_«bs»n_«bs»v_«bs»e_«bs»n_«bs»d_«bs»e_«bs»l_«bs»s_«bs»e__«bs»a_«bs»f__«bs»e_«bs»k_«bs»s_«bs»p_«bs»o_«bs»n_«bs»e_«bs»n_«bs»t_«bs»i_«bs»a_«bs»l_«bs»f_«bs»o_«bs»r_«bs»d_«bs»e_«bs»l_«bs»i_«bs»n_«bs»g_«bs»e_«bs»n__«bs»t_«bs»i_«bs»l__«bs»C_«bs»P_«bs»U_«bs»-_«bs»t_«bs»i_«bs»d_«bs»e_«bs»r_«bs»n_«bs»e_«bs».
$np$
Dette er en begrænsning, som uden tvivl bevirker, at resultaterne
fra simulatoren bliver mindre nøjagtige. Det er imidlertid vanskeligt
at finde den præcise fordeling, og derefter implementere den i SIMULA.
$np$
Ved målinger på OP-systemet har det vist sig at fordelingen af CPU-tiden
faktisk ligner en eksponential fordeling i søge- og opslagsprocessen.
Ved input- og outputprocessen er fordelingen ikke en eksponentialfordeling.
Ved simulatoren benyttes i stedet en konstant fordeling, hvilket giver nøjagtigere simulering.
$nl2$
_«bs»4_«bs»)__«bs»S_«bs»i_«bs»m_«bs»p_«bs»l_«bs»i_«bs»f_«bs»i_«bs»c_«bs»e_«bs»r_«bs»i_«bs»n_«bs»g__«bs»a_«bs»f__«bs»e_«bs»n__«bs»p_«bs»l_«bs»a_«bs»d_«bs»e_«bs»l_«bs»a_«bs»g_«bs»e_«bs»r_«bs»t_«bs»i_«bs»l_«bs»g_«bs»a_«bs»n_«bs»g_«bs».
$nl$
Normalt, når en datamaskine benyttes, vil der findes en vekselvirkning sted
mellem
et jobs CPU-tidsforbrug og dets pladelagerforbrug. Dette kan illusteres på
nedenstående figur.
$nl$$sj$
CPU
!-----! !-----! !-----! !-------!

pladelageret
!----------! !------! !------!
$rj$
Figuren viser et normalt jobs afvikling på en datamaskine. CPU-en vil være
ledig, når jobbet skal benytte data fra disken. Ved at multiprogrammere datamaskinen
vil det være muligt at udfylde den tid, hvor CPU-en er ledig med et andet
job.
$np$
Ved de 3 processer, hvor der findes en associeret disk ved OP-systemet
simuleres en pladelagertilgang på ovenstående vis. Dette betyder, at
når en proces benytter pladelageret kan den ikke samtidig benytte
CPU-en.(Dog kan en anden proces naturligvis benytte CPU-en).
$np$
Dette er imidlertid en simplificering i forhold til
det implementerede OP-system, idet ved opslag- og outputprocessen
vil en pladelagertilgang ikke forløbe på denne måde. Her kan ske
en overlapning af brugen af pladelageret og CPU-en. At dette ikke er medtaget
i simulatoren skyldes vanskeligheder med at bestemme, hvor tit
denne overlapning foregår. Det er ikke muligt at udtale f.eks. at
overlapningen foregår altid eller hver 2. gang. På grund af dette
faktum vil det være særdeles vanskeligt at indbygge i simulatoren.
En tilnærmelse af det kan dog implementeres ved at lade en pladelagertilgang
i opslagsprocessen være hurtigere end ved de andre processer.
$nl2$
_«bs»5_«bs»)__«bs»B_«bs»e_«bs»s_«bs»k_«bs»r_«bs»i_«bs»v_«bs»e_«bs»l_«bs»s_«bs»e__«bs»a_«bs»f__«bs»e_«bs»n__«bs»p_«bs»l_«bs»a_«bs»d_«bs»e_«bs»l_«bs»a_«bs»g_«bs»e_«bs»r_«bs»t_«bs»i_«bs»l_«bs»g_«bs»a_«bs»n_«bs»g_«bs».
$np$
En pladelagertilgang består ved simulatoren af en hovedflytning og overførslen af data.
Til styring af kommunikationen mellem disken og en proces anvendes datakanalen.
Denne datakanal er en kritisk ressource med hensyn til overførslen af data fra
pladelageret.
$np$
Når en proces ønsker en pladelagertilgang sker følgende:
Hvis der ikke er en overførsel i gang ved datakanalen, så kan en positionering
af diskhovedet sættes igang. Efter en positionering reserverer disken datakanalen,
hvis dette er muligt. Når diskkanalen er reserveret overføres data.
$np$
Hvis en anden proces ønsker en diskaccess, når en overførsel er i gang ved datakanalen, og denne derfor er reserveret, så sættes
disken i kø til datakanalen.
Der kan via datakanalen således ske en hovedflytning
på de 3 diske samtidig, men under overførslen af data fra disken til processen, kan
de andre diske ikke sættes igang med en positionering.
$np$
Baggrunden for at konstruere kommunikationen mellem diskene og processerne
på denne måde ved hjælp af datakanalen er,
at man deved faktisk præcist simulerer
hvordan det foregår ved en RC8000.
$ns 1,4,_«bs»3_«bs»._«bs»2_«bs»._«bs»D_«bs»e__«bs»o_«bs»p_«bs»n_«bs»å_«bs»e_«bs»d_«bs»e__«bs»s_«bs»p_«bs»e_«bs»c_«bs»i_«bs»f_«bs»i_«bs»c_«bs»a_«bs»t_«bs»i_«bs»o_«bs»n_«bs»s_«bs»k_«bs»r_«bs»a_«bs»v_«bs».$
$np$
Ud fra de i afsnit 3.1 beskrevne begrænsninger skal det her forklares,
hvilke aspekter ved en RC8000, der er lagt mest vægt på under udviklingen af simulatoren.
$np$
Der er to ting vi specielt har lagt vægt på:
scheduleringsstrategien og simuleringen af en diskoverførsel.
Scheduleringsstrategien er gennemført så nøjagtigt, som det efter vores mening kan lade
sig gøre. Ikke alle dens facetter er medtaget, men de begrænsninger, der
er foretaget har vist sig kun at have ringe betydning, jvf. målereslutater.
Kommunikationen mellem en disk
og en proces er simuleret med høj detaljeringsgrad for at kunne måle om diskkanalen
er en begrænsende enhed ved systemet.
$rh 1,MODELBESKRIVELSE$
$ps0$
$ns 1,4,_«bs»4_«bs»._«bs»M_«bs»o_«bs»d_«bs»e_«bs»l_«bs»b_«bs»e_«bs»s_«bs»k_«bs»r_«bs»i_«bs»v_«bs»e_«bs»l_«bs»s_«bs»e_«bs».$
$np$
Indholdet i dette afsnit er en strukturel og funktionel beskrivelse af den simulatormodel, der blev udviklet til simulering af OP-systemet.
$np$
Modellen vil først blive forklaret på et overordnet plan,
hvor hovedkomponenternes funktion kort omtales og hele systemets struktur afbildes.
For en uddybning af de enkelte programdeles virkemåde, ses derefter på den mere
detaljerede opbygning af disse. Herunder vil komponenternes logiske struktur blive
beskrevet i et "hjemmestrikket" metasprog, hvilket skulle gøre kendskabet til det
aktuelle simuleringssprog (SIMULA) mindre betydningsfuldt.
Sluttelig trækkes komponenternes indbyrdes kommunikationsmønster op.
$np$
Det skal her bemærkes, at den beskrevne simulatormodel,
er at betragte som en grundmodel af den fuldt udviklede simulator.
Den fuldt udviklede model indeholder eksperimenter, tilføjelser og ændringer til
grundmodellen af
OP-systemet, og begrundelse for og opbygning af disse følger i næste afsnit.
Modellen der omtales her, skal altså ses som en grundtype uden nedennævnte
indbyggede potentialer:
$nl$$lm20$
$nl$
- dublering af søgeproces
$nl$
- dublering af datakanal
$nl$
- prioritering af processer.
$lm0$$nl$
$ps0$
$sj$
SIMULA-PROGRAMDELE
__________________
BEGIN
SIMULATION CLASS KTASSYSTEM;
BEGIN
PROCESS CLASS CENTER;
CENTER CLASS INPUTPROCES;
CENTER CLASS SOEGEPROCES;
CENTER CLASS OPSLAGPROCES;
CENTER CLASS OUTPUTPROCES;
PROCESS CLASS JOBGENERATOR;
PROCESS CLASS DISKKONTROL;
PROCESS CLASS DISK;
PROCESS CLASS PROCESSTYRING;
PROCESS CLASS KOEOBJEKT;
PROCEDURE KOEINDSAET(NUMMER);
PROCEDURE KOELENGDE(I);
PROCEDURE KANALKOE(I);
PROCEDURE OVERGANG(JOBREFERENCE,PROCESNR);
PROCESS CLASS JOB;
CENTER CLASS STATISTIK;
PROCEDURE SKRIVRESULTAT(TID);
REAL PROCEDURE BEREGNSNIT(L,TID);
REAL PROCEDURE BEREGNVAR(I,L,TID);
PROCEDURE SKRIVINPUT;
PROCEDURE SPOR(NUMMER,PROCESTYPE,STATUS);

<globale variable erklæres>
<initialisering>
END;
KTASSYSTEM
BEGIN
<styr simuleringens længde og udskrifter>
END;
END;
$rj$
$ps0$
_«bs»M_«bs»o_«bs»d_«bs»e_«bs»l_«bs»l_«bs»e_«bs»n_«bs»s__«bs»p_«bs»r_«bs»o_«bs»g_«bs»r_«bs»a_«bs»m_«bs»o_«bs»p_«bs»b_«bs»y_«bs»g_«bs»n_«bs»i_«bs»n_«bs»g_«bs»/_«bs»s_«bs»t_«bs»r_«bs»u_«bs»k_«bs»t_«bs»u_«bs»r
Findes i området tegn1
$ps0$
_«bs»A_«bs»k_«bs»t_«bs»i_«bs»v_«bs»i_«bs»t_«bs»e_«bs»t__«bs»o_«bs»v_«bs»e_«bs»r_«bs»s_«bs»i_«bs»g_«bs»t_«bs»:
$ps0$
$ns 1,4,_«bs»4_«bs»._«bs»1_«bs»._«bs»O_«bs»v_«bs»e_«bs»r_«bs»o_«bs»r_«bs»d_«bs»n_«bs»e_«bs»t__«bs»m_«bs»o_«bs»d_«bs»e_«bs»l_«bs»b_«bs»e_«bs»s_«bs»k_«bs»r_«bs»i_«bs»v_«bs»e_«bs»l_«bs»s_«bs»e_«bs».$
$np$
Det undersøgte OP-system ved KTAS skal her kort beskrives i den form
det fik, da det blev afbildet som en simulatormodel. Der ses først på,
hvilken funktion programdelkomponenterne afbilder i det virkelige system, og derefter
vises, hvilke kommunikationsveje modellen indeholder og afbilder. I næste afsnit redegøres der for
de enkelte komponenters detaljerede virkemåde og indbyrdes dataudveksling.
$np$
Selve modellen af det undersøgte system har fået navnet KTASSYSTEM.
$nl2$
KTASSYSTEM indeholder følgende hovedkomponenter:
$nl2$
_«bs»-__«bs»I_«bs»N_«bs»P_«bs»U_«bs»T_«bs»-_«bs»,_«bs»S_«bs»O_«bs»E_«bs»G_«bs»E_«bs»-_«bs»,_«bs»O_«bs»P_«bs»S_«bs»L_«bs»A_«bs»G__«bs»o_«bs»g__«bs»O_«bs»U_«bs»T_«bs»P_«bs»U_«bs»T_«bs»P_«bs»R_«bs»O_«bs»C_«bs»E_«bs»S_
$nl$
Disse modelerer de 4 processer i OP-systemet. Den sidste proces (PARENT proces)
i OP-systemet er det ikke fundet nødvendigt at simulere.
$nl$
De 4 komponenter modelerer CPU-tidsforbruget anvendt i processerne, samt
antallet af diskaccesser til pladelager.
$nl2$
_«bs»-__«bs»J_«bs»O_«bs»B_«bs»G_«bs»E_«bs»N_«bs»E_«bs»R_«bs»A_«bs»T_«bs»O_«bs»R
$nl$
Simulerer ankomst af forespørgsler til OP-systemet.
$nl2$
_«bs»-__«bs»D_«bs»I_«bs»S_«bs»K_«bs»K_«bs»O_«bs»N_«bs»T_«bs»R_«bs»O_«bs»L
$nl$
modelerer den datakanal, der kontrolerer kommunikation mellem
CPU'ens procesafvikling og pladelager. Styrer tidsforbrug og datakanaltilgang.
$nl2$
_«bs»-__«bs»D_«bs»I_«bs»S_«bs»K
$nl$
Modelerer de 3 pladelagre, der indeholder information anvendt henholdsvis af
søge-, opslag- og outputproces. Simulerer pladelageraccestid og pladelageroverførselstid.
$nl2$
_«bs»-__«bs»P_«bs»R_«bs»O_«bs»C_«bs»E_«bs»S_«bs»S_«bs»T_«bs»Y_«bs»R_«bs»I_«bs»N_«bs»G
$nl$
Kan sammenlignes med monitoren i OP-systemet. Sørger for at skifte mellem
ventende processer og simulerer tidsforbrug til dette.
$nl2$
_«bs»-__«bs»J_«bs»O_«bs»B
$nl$
Modelerer en forespørgsel.
$nl2$
_«bs»-__«bs»O_«bs»V_«bs»E_«bs»R_«bs»G_«bs»A_«bs»N_«bs»G
$nl$
Modelerer v.h.a. en sandsynlighedsmatrix de veje en forespørgsel kan
komme mellem processerne i OP-systemet.
$nl2$
_«bs»-__«bs»K_«bs»O_«bs»E_«bs»I_«bs»N_«bs»D_«bs»S_«bs»A_«bs»E_«bs»T
$nl$
Afbilder den afviklingsstrategi, der benyttes se afsnit 3.2.
$nl2$
_«bs»-__«bs»K_«bs»O_«bs»E_«bs»L_«bs»E_«bs»N_«bs»G_«bs»D_«bs»E
$nl$
Måler kølængden, der opstår ved ophobning af forespørgsler til processerne.
$nl$
_«bs»-__«bs»S_«bs»T_«bs»A_«bs»T_«bs»I_«bs»S_«bs»T_«bs»I_«bs»K_«bs»,_«bs»S_«bs»K_«bs»R_«bs»I_«bs»V_«bs»R_«bs»E_«bs»S_«bs»U_«bs»L_«bs»T_«bs»A_«bs»T_«bs»,_«bs»S_«bs»K_«bs»R_«bs»I_«bs»V_«bs»I_«bs»N_«bs»P_«bs»U_«bs»T__«bs»o_«bs»g__«bs»S_«bs»P_«bs»O_«bs»R_
$nl2$
Komponenter, der indeholder tællevariable og udskriver resultater,
inputkonfiguration samt giver et spor ved fejlfinding.
$nl$$np$
For at give et bedre indtryk af modellens funktionsmåde er der i figur 4.2
illustreret, hvorledes komponenterne kommunikerer indbyrdes.
$np$
Det skal om figur 4.2 bemærkes, at komponenterne med dobbelt ramme skal
betragtes som processer i simulatormodellen, dvs. det anvendte simuleringssprog
skal kunne indsætte disse i en tidsordnet rækkefølge, mens de resterende
er procedurer.
$np$
Figur 4.2 giver med det viste aktivitetsbillede også en grov skitse
af inddata (forespørgsler afbildet ved job) mulige vej
gennem modellen. Under afsnittet om systembeskrivelse (afsnit 3
i vurderingsopgaven.) er
vist, hvilke veje en forespørgsel kan få imellem processerne i OP-systemet,
og i næste afsnit vil inddatas vej gennem modellen blive nærmere belyst gennem
de detaljerede beskrivelser af komponenterne.
$ns 1,4,_«bs»4_«bs»._«bs»1_«bs»._«bs»1_«bs»._«bs»B_«bs»e_«bs»s_«bs»k_«bs»r_«bs»i_«bs»v_«bs»e_«bs»l_«bs»s_«bs»e__«bs»a_«bs»f__«bs»h_«bs»o_«bs»v_«bs»e_«bs»d_«bs»k_«bs»o_«bs»m_«bs»p_«bs»o_«bs»n_«bs»e_«bs»n_«bs»t_«bs»e_«bs»r_«bs»n_«bs»e_«bs».$
$np$
Inden de enkelte komponenter omtales, skal 2 af modellens køer forklares.
$np$
Til at modelere ophobning af forespørgsler ved de 4 processer anvendes køer af typen
KOE(<PROCESNR>), således at hver proces bliver forsynet med sin kø af ventende
forespørgsler.
$np$
For at kunne simulere en afviklingsstrategi, hvor processerne skiftes til at få
adgang til CPU-behandling, indføres en kø af processer, der er parate til at
anvende CPU. Denne kø kaldes AKTIVKOE.
$nl2$
_«bs»J_«bs»O_«bs»B_«bs»G_«bs»E_«bs»N_«bs»E_«bs»R_«bs»A_«bs»T_«bs»O_«bs»R_
$nl$
Genererer nye forespørgsler, hvis mellemankomsttid er bestemt af en negativ eksponentialfordeling. Komponenternes øvrige funktion fremgår af nedenstående programforklaring.
$sj$
_«bs»S_«bs»T_«bs»R_«bs»U_«bs»K_«bs»T_«bs»U_«bs»R

while true do
begin
<tæl antal forespørgsler>;
<bestem mellemankomsttid og simuler dette tidsforbrug>;
<juster kølængde for INPUT-proces>;
<indsæt forespørgsel i kø til INPUTPROCES>;
<sæt INPUTPROCES i AKTIVKOE>;
<hvis modellen ikke bruger CPU aktiver PROCESSTYRING>;
end;

$rj$
$nl$
_«bs»I_«bs»N_«bs»P_«bs»U_«bs»T_«bs»P_«bs»R_«bs»O_«bs»C_«bs»E_«bs»S
$np$
Har som funktion at simulere tidsforbrug for OP-systemets inputproces. Inputprocessen
(og alle de øvrige processer) tildeles tidsskiver i overensstemmelse med
den
kvanttildelingspolitik, der er beskrevet i afsnit 3.
$np$
Når en forespørgsel er færdig med inputprocessen, kaldes OVERGANG, der
bestemmer næste proces for denne forespørgsel. Ligeledes undersøges, om forespørgsleskøen til processen er tom. Er den det aktiveres PROCESSTYRING ellers
fortsætter INPUTPROCES med den næste forespørgsel.
$sj$
_«bs»S_«bs»T_«bs»R_«bs»U_«bs»K_«bs»T_«bs»U_«bs»R

while true do
begin
<gentag indtil inputkøen er tom>
<tag 1.job i inputkø>;
<bestem CPU-behandlingstid>;
while CPU-behandlingstid > 0 do
begin
if CPU-krav opfyldelig then
begin
<simuler CPU-tidskrav>;
<juster tællere og INTERRUPT>;
<kald OVERGANG>;
end else
begin
<simuler opnåelig CPU-tid>;
<juster tællere og INTERRUPT>;
<aktiver PROCESSTYRING>;
<indsæt INPUTPROCES i aktivkøe>;
<passiver INPUTPROCES>;
end;
<hvis inputkø er tom aktiver PROCESSTYRING>;
end;
<passiver inputproces>;
end;

$rj$$nl$
_«bs»S_«bs»Ø_«bs»G_«bs»E_«bs»-__«bs»+__«bs»O_«bs»P_«bs»S_«bs»L_«bs»A_«bs»G_«bs»P_«bs»R_«bs»O_«bs»C_«bs»E_«bs»S
$np$
Disse 2 komponenter gennemgås her samtidig, da deres logik er identisk.
Dette gælder dog kun i simulatorens grundmodel; hvis søgeprocessen
ønskes dubleret, ændres der noget i denne PROCES (se nærmere i afsnit
4.3).
$np$
Til forskel fra INPUTPROCES skal disse 2 komponenter også modelere pladelagertilgange,
idet de 2 komponenter kræver 1 eller flere oplysninger fra deres associerede
pladelager.
$np$
Antallet af pladelagertilgange og den samlede CPU-behandlingstid
fastlægges og udfra disse tal bestemmes CPU-behandlingstiden for processerne mellem 2
pladelagertilgange (og før den 1. tilgang og efter den sidste tilgang)
$np$
Når en forespørgsel har simuleret sidste CPU-behandling færdig, foretages
samme rutine som ved INPUTPROCES, dvs. kald af OVERGANG og
videre programforgrening afhængig af om forespørgselskøen til
PROCES'en er tom eller ej.
$sj$
_«bs»S_«bs»T_«bs»R_«bs»U_«bs»K_«bs»T_«bs»U_«bs»R

while true do
begin
<gentag indtil proceskøen er tom>;
<tag 1.job i proceskø>;
<bestem CPU-behandlingstid, og antal pladelagertilgange>;
<udregn del-CPU-behandlingstid>;
<For hver pladelagetilgang: >;
while del-CPU-behandlingstid > 0 do
begin
if CPU-krav opfyldelig then
begin
<simuler CPU-tidskrav>;
<juster tællere og INTERRUPT>;
end else
begin
<simuler opnåelig CPU-tid>;
<juster tællere og INTERRUPT>;
<aktiver PROCESSTYRING>;
<indsæt proces i aktivkø>;
<passiver proces>;
end;
end;
<aktiver DISKKONTROL for diskaccess>;
<hvis disktilgang = 0 gentag While-løkke og kun den>;
end;

$rj$
$nl$
_«bs»O_«bs»U_«bs»T_«bs»P_«bs»U_«bs»T_«bs»P_«bs»R_«bs»O_«bs»C_«bs»E_«bs»S
$np$
Har som funktion at simulere tidsforbruget for OP-systemets outputproces,
Da outputproces, hvis den skal benytte pladelageret, kun anvender 1 pladelagertilgang,
kan OUTPUTPROCES opbygges stort set som INPUTPROCES. Først CPU-tidsallokering
som ved INPUTPROCES, derefter bestemmes om forespørgslen kræver pladelagertilgang
og i givet fald aktiveres DISKKONTROL.
$np$
Afslutningsvis behandles en forespørgsel som ved de andre 3 processer,
dog kaldes komponenten STATISTIK for opdatering af målevariable.
$sj$
_«bs»S_«bs»T_«bs»R_«bs»U_«bs»K_«bs»T_«bs»U_«bs»R_

while true do
begin
<gentag indtil outputkøen er tom: >;
<tag 1.job i outputkø>;
<bestem CPU-behandlingstid>;
while CPU-behandlingstid > 0 do
begin
if CPU-krav opfyldelig then
begin
<simuler CPU-tidskrav>;
<juster tællere og INTERRUPT>;
* if pladelagertilgang then
* <aktiver DISKKONTROL>;
* <opdater målevariable vha. STATISTIK>;
end else
begin
<simuler opnåelig CPUtid>;
<juster tællere og INTERRUPTS>;
<aktiver PROCESSTYRING>;
<indsæt OUTPUTPROCES i aktivkø>;
<passiver OUTPUTPROCES>;
end;
<hvis outputkø er tom aktiver PROCESSTYRING>;
end;
<passiver outputproces>;
end;

* indikerer ændringer i forhold til INPUTPROCES.
$rj$
$nl$
_«bs»D_«bs»I_«bs»S_«bs»K_«bs»K_«bs»O_«bs»N_«bs»T_«bs»R_«bs»O_«bs»L
$np$
Denne komponent afbilder datakanalen, der er forbindingsled mellem CPU og
pladelager. DISKKONTROL bruges til at initiere pladelagertilgang
og dataoverførsel fra pladelager til centralenheden. Desuden skal DISKKONTROL sørge for,
at diskkanalen ved pladelageroverførsel er eksklusivt tilegnet
en PROCES og dennes associerede pladelager. Dvs. det er under en dataoverførsel
umuligt at initiere pladelagertilgang eller overførsel
for andre processer.
$np$
Hvad angår dublering af søgeproces og DISKKONTROL, henvises til afsnit 4.3
Begrundelse for simulatorbeskrivelse.
_«bs»S_«bs»T_«bs»R_«bs»U_«bs»K_«bs»T_«bs»U_«bs»R

while true do
begin
if "kaldt fra proces" then
begin
<Indsæt i kø til rigtig disk, hvis datakanalen er optaget,
ellers aktiver den ønskede disk>;
end
else
begin
if "kaldt fra disk, der har afsluttet tilgangstiden"
then
begin
<hvis ikke datakanalen er optaget, tildelt datakanalen
til den "kaldende" disk, for overførsel af data>;
end
else
if "kaldt fra disk, der har afsluttet overførselstiden"
then
begin
<kald KOEINDSAET>;
<Hvis der er forespørgsler i kø til disk(e),
aktiveres pågældende disk(e)>;
<Hvis der er kø til datakanalen, tildeles datakanalen
til den første i køen, for overførsel af data>;
<Juster tællere>;
end;
end;
end;
$rj$$nl$
$nl2$
_«bs»D_«bs»I_«bs»S_«bs»K
$np$
Komponenten DISK bruges til at modelere de 3 pladelagre, indeholdende
abonnentinformation m.m. og associeret henholdsvis søge-, opslag- og
outputproces. Programteknisk åbner simuleringssproget SIMULA op
for, at komponenterne med ens struktur og funktion, som f.eks. disse
pladelagre, kan afbildes som samme programstykke.
$np$
DISK bestemmer først, hvor stort et tidsforbrug tilgang til
pladelageret kræver, hvorefter denne tid simuleres anvendt hertil.
Så kaldes DISKKONTROL, der skal sikre, at datakanalen ikke benyttes af andre processer. DISK er passiv
indtil datakanalen er blevet eksklusivt tilegnet dette pladelager.
Når DISK kaldes af DISKKONTROL, simuleres tidsforbrug til overførsel
af information til centralenheden. Ved overførslens slutning gives der besked
til DISKKONTROL om at datakanalen igen er ledig.
$np$
Sluttelig aktiveres PROCESSTYRING, hvis ingen andre processer for øjeblikket
er under CPU-afvikling.
$sj$
_«bs»S_«bs»T_«bs»R_«bs»U_«bs»K_«bs»T_«bs»U_«bs»R

while true do
begin
<juster tællere>;
<simuler disktilgangstid>;
<juster tællere>;
<aktiver DISKKONTROL>;"<REQUEST datakanal>;"
<pasiver DISK>;
<simuler overførselstid>;
<juster tællere>;
<aktiver DISKKONTROL;"<RELEASE datakanal>;"
<hvis modellen ikke bruger CPU aktiver PROCESSTYRING>;
end;

$rj$$nl$
_«bs»P_«bs»R_«bs»O_«bs»C_«bs»E_«bs»S_«bs»S_«bs»T_«bs»Y_«bs»R_«bs»I_«bs»N_«bs»G
$np$
Komponenten har som primær funktion at aktivere den første proces
(INPUT-,SØGE-,OPSLAG- eller OUTPUTPROCES) i køen af ventende
processer. (For indplacering i denne kø se gennemgang af næste komponent,
KOEINDSAET).
$np$
Iøvrigt simulerer denne komponent tidsforbruget anvendt til at skifte
mellem processerne.
$nl$
Processtyring bliver kaldt:
$nl$
1) når modelllens CLOCKPULS kommer ( svarer til RESTTIDSKVANT = 0)
$nl$
eller
$nl$
2) når en proces har færdigbehandlet sin kø af ventende forespørgsler
$nl$
eller
$nl$
3) hvis ingen proces er under CPU-afvikling, når
$lm20$
$nl$
a) en forespørgsel ankommer til INPUTPROCES
$nl$
eller
$nl$
b) en forespørgsel har afsluttet en pladelageroverførsel.
$lm0$$nl$
$sj$
_«bs»S_«bs»T_«bs»R_«bs»U_«bs»K_«bs»T_«bs»U_«bs»R

while true do
begin
<gentag indtil aktivkø er tom: >;
<tag 1.proces i AKTIVKOE >;
<simuler skiftetid>;
<aktiver den udtagne proces>;
<juster tællere>;
<passiver PROCESSTYRING>;
<passiver PROCESSTYRING>
end;
$rj$

$nl$
_«bs»K_«bs»O_«bs»E_«bs»I_«bs»N_«bs»D_«bs»S_«bs»A_«bs»E_«bs»T
$np$
Komponentens funktion er at afbilde den strategi OP-systemet(RC8000) anvender,
ved tildeling af CPU-tidskvanter til de 4 processer. For en udførlig
gennemgang af denne strategi henvises til vurdringensopgaven.
$np$
KOEINDSAET indsætter processer, der ønsker CPU-tid, i en ventekø til
CPU-aktivkøen. Indplacering sker i henhold til den omtalte
strategi, idet en proces kan placeres enten forrest i aktivkø eller
bagest i denne. (er aktivkø tom indsættes den naturligvis bare).
$sj$
_«bs»S_«bs»T_«bs»R_«bs»U_«bs»K_«bs»T_«bs»U_«bs»R

begin
if "bagest i kø" then
begin
<indsæt bagest i aktivkø>;
<juster køkriterium>;
end else
begin
if aktivkø er tom then
<indsæt proces i aktivkø>
else
<indsæt proces forrest i aktivkø>;
end;
end;

$rj$$nl$
_«bs»O_«bs»V_«bs»E_«bs»R_«bs»G_«bs»A_«bs»N_«bs»G
$nl$
Denne komponent sørger for, at når en forespørgsel er færdigbehandlet
ved en proces, findes næste proces, hvor behandling kræves.
$np$
Overgangen fra en proces til den næste bestemmes i modellen v.h.a. en
sandsynlighedsmatrix. Denne er konstrueret på baggrund
af et stort empirisk materiale, indhentet ved gennemløb af logfilen ved OP-systemet.
Dette materiale har muliggjort at udtale sig om, med hvilken sandsynlighed
en forespørgsel vil skulle anvende en proces, givet at den netop
har brugt en anden proces.
$sj$
_«bs»S_«bs»T_«bs»R_«bs»U_«bs»K_«bs»T_«bs»U_«bs»R

begin
<find næste proces v.h.a.sandsynlighedsmatrix>;
<udregn gnst. kølængde for nuværende proces>;
<indsæt forespørgsel til næste proceskø>;
<hvis processen ikke er i aktivkø indsættes den heri>;
end;
$rj$
$nl$
_«bs»J_«bs»O_«bs»B
$nl$
Denne komponents funktion er at afbilde en enkelt
forespørgsel. Komponenten holder regnskab med, hvor længe
forespørgslen opholder sig ved hver proces, og hvor meget
af denne tid, der er CPU-tid.
$np$
Ydermere har denne komponent en anden (ligeledes) passiv funktion, idet
komponenten, når en forespørgsel kommer til en proces, indsættes
i ventekø til denne.
$nl$
$nl2$
_«bs»K_«bs»O_«bs»E_«bs»L_«bs»E_«bs»N_«bs»G_«bs»D_«bs»E
$nl$
Denne komponent edregner kontinuerligt den gennemsnitlige kølængde
ved de 4 processer. Kølængden justeres hver gang en forespørgsel
ankommer til eller forlader en proces, og den gennemsnitlige kølængde
findes som det tidsvægtede gsnt. af disse kølængder.
_«bs»K_«bs»A_«bs»N_«bs»A_«bs»L_«bs»K_«bs»O_«bs»E
$nl$
Samme funktion og logisk opbygning som KOELENGDE, men her
måles køen af processer ved datakanalen.
$nl$
_«bs»K_«bs»O_«bs»E_«bs»O_«bs»B_«bs»J_«bs»E_«bs»K_«bs»T
$np$
Komponenten, der erer repræsentation af en proces.. Aktivkøen består af disse komponenter.
$nl$
_«bs»S_«bs»K_«bs»R_«bs»I_«bs»V_«bs»R_«bs»E_«bs»S_«bs»U_«bs»L_«bs»T_«bs»A_«bs»T
$np$
Komponenten udskriver akkumulerede måleresultater især fra komponenten
STATISTIK; tal fra målevariable som antal forespørgsler, gnst. procestid,
gnst. CPU-tid, gnst KØTID og variancen af disse.
$nl$
_«bs»S_«bs»K_«bs»R_«bs»I_«bs»V_«bs»I_«bs»N_«bs»P_«bs»U_«bs»T
$np$
Udskriver de parameterværdier simuleringen foretages med. Eks. maskinelkarakteristika
som pladelagertilgangstid o.l.
$nl$
_«bs»S_«bs»T_«bs»A_«bs»T_«bs»I_«bs»S_«bs»T_«bs»I_«bs»K
$np$
Indeholder tællevariable, der primært akkumulerer de opsamlede måleresultater fra
komponenten JOB.
$nl$
_«bs»S_«bs»P_«bs»O_«bs»R
$np$
En komponent der har været anvendt som sporudskriver under implementeringen og
afprøvningen af simulatoren.
$ns 1,4,4.1.2.Kommunikationsforklaring.$
$nl$
_«bs»1_«bs»)__«bs»J_«bs»O_«bs»B_«bs»G_«bs»E_«bs»N_«bs»E_«bs»R_«bs»A_«bs»T_«bs»O_«bs»R__«bs»-_«bs»>__«bs»P_«bs»R_«bs»O_«bs»C_«bs»E_«bs»S_«bs»S_«bs»T_«bs»Y_«bs»R_«bs»I_«bs»N_«bs»G_«bs»:
$nl$
Kun hvis modellen ikke har forespørgsler, der CPU-behandles, aktiveres PROCESSTYRING eksplicit.
$nl$
_«bs»2_«bs»)__«bs»P_«bs»R_«bs»O_«bs»C_«bs»E_«bs»S_«bs»S_«bs»T_«bs»Y_«bs»R_«bs»I_«bs»N_«bs»G__«bs»-_«bs»>__«bs»<_«bs»P_«bs»R_«bs»O_«bs»C_«bs»E_«bs»S_«bs»>
$nl$
Den første proces i aktivkøen (køen af ventende processer til CPU) tages ud og processen aktiveres. Der simuleres en processkiftetid.
$nl$
_«bs»3_«bs»)__«bs»<_«bs»P_«bs»R_«bs»O_«bs»C_«bs»E_«bs»S_«bs»>__«bs»-_«bs»>__«bs»P_«bs»R_«bs»O_«bs»C_«bs»E_«bs»S_«bs»S_«bs»T_«bs»Y_«bs»R_«bs»I_«bs»N_«bs»G
$nl$
Når modelinterrupt kommer (RESTTIDSKVANT = 0) aktiveres PROCESSTYRING eller
når processen ikke har flere forespørgsler i kø.
$nl$
_«bs»4_«bs»)__«bs»<_«bs»P_«bs»R_«bs»O_«bs»C_«bs»E_«bs»S_«bs»>__«bs»-_«bs»>__«bs»D_«bs»I_«bs»S_«bs»K_«bs»K_«bs»O_«bs»N_«bs»T_«bs»R_«bs»O_«bs»L
$nl$
Når en del-CPU behandling er afsluttet og en diskaccess ønskes, aktiveres DISKKONTROL.
$nl$
_«bs»5_«bs»)__«bs»O_«bs»U_«bs»T_«bs»P_«bs»U_«bs»T__«bs»-_«bs»>__«bs»D_«bs»I_«bs»S_«bs»K_«bs»K_«bs»O_«bs»N_«bs»T_«bs»R_«bs»O_«bs»L
$nl$
Hvis en bestemt type forespørgsel (tilfældighedsbestemt) optræder aktiveres DISKKONTROL.
$nl$
_«bs»6_«bs»)__«bs»D_«bs»I_«bs»S_«bs»K_«bs»K_«bs»O_«bs»N_«bs»T_«bs»R_«bs»O_«bs»L__«bs»-_«bs»>__«bs»D_«bs»I_«bs»S_«bs»K
$lm10$$nl$
a) Hvis ikke diskoverførsel pågår, simuleres diskaccess fra en proces til disken.
$nl$
b) Hvis ikke diskoverførsel pågår, initieres tidsforbrug af overførsel af information
fra DISK til <PROCES>.
$nl$
c) Hvis søgeprocessen er dubleret, og søgedisken optaget gemmes evt. ankommende
"dublet"-søgeproces, indtil overførsel fra søgedisk er afsluttet, hvorefter
DISK aktiveres.
$lm0$
$nl$
_«bs»7_«bs»)__«bs»D_«bs»I_«bs»S_«bs»K__«bs»-_«bs»>__«bs»D_«bs»I_«bs»S_«bs»K_«bs»K_«bs»O_«bs»N_«bs»T_«bs»R_«bs»O_«bs»L
$lm10$$nl$
a) Når modellen har simuleret egentlig DISK-accestid = positioneringstid + omdrejningstid
aktiveres DISKKONTROL. (Disken er så klar til pkt 2) i DISKKONTROL -> DISK,
dvs. venter på klarmelding til overførsel.)
$nl$
b) Når modellen har simuleret overførselstid fra DISK via DISKKONTROL (datakanal) til en given <PROCES>.
$lm0$
$nl$
_«bs»8_«bs»)__«bs»O_«bs»U_«bs»T_«bs»P_«bs»U_«bs»T_«bs»P_«bs»R_«bs»O_«bs»C_«bs»E_«bs»S__«bs»-_«bs»>__«bs»S_«bs»T_«bs»A_«bs»T_«bs»I_«bs»S_«bs»T_«bs»I_«bs»K
$nl$
Når en forespørgsel er færdigbehandlet i OUTPUTPROCES kaldes CLASS STATISTIK.
$nl$
_«bs»9_«bs»)__«bs»D_«bs»I_«bs»S_«bs»K__«bs»-_«bs»>__«bs»P_«bs»R_«bs»O_«bs»C_«bs»E_«bs»S_«bs»S_«bs»T_«bs»Y_«bs»R_«bs»I_«bs»N_«bs»G
$nl$
Som ved 1).
$ns 1,4,_«bs»4_«bs»._«bs»2_«bs»._«bs»B_«bs»e_«bs»s_«bs»k_«bs»r_«bs»i_«bs»v_«bs»e_«bs»l_«bs»s_«bs»e__«bs»a_«bs»f__«bs»i_«bs»n_«bs»d_«bs»-__«bs»o_«bs»g__«bs»u_«bs»d_«bs»d_«bs»a_«bs»t_«bs»a_«bs».$
$np$
Nedenstående afsnit beskriver, hvilke inddata simulatoren skal have.
Disse inddata bestemmer belastningen simulatoren udsættes for. Uddata
er konstrueret således, at det direkte er muligt at sammenligne resultaterne
fra simulatoren med de resultater, der er opnået ved målinger ved KTAS.
Udover størrelser som er direkte sammenlignelige med målinger fra KTAS, udskrives en del størrelser som det ikke er muligt at måle ved
OP-systemet. Af disse er de vigtigste udnyttelsesgraderne af de indgående
pladelagre og diskkanalen. Desuden findes til sidst i uddata nogle
præstationsindeks, der skal benyttes, når en teoretisk model af OP-systemet
skal anvendes. Til de sidste størrelse hører bl.a. antal processkift og antal
pladelageraccesser.
$np$
Nedenstående vil indeholde en gennemgang af både ind- og uddata.
Et eksempel på ind- og uddata er vedlagt som bilag 3.
$nl$
_«bs»I_«bs»N_«bs»D_«bs»D_«bs»A_«bs»T_«bs»A_«bs».
$nl2$
_«bs»a_«bs»n_«bs»t_«bs»a_«bs»l_«bs»j_«bs»o_«bs»b_«bs»s__«bs»p_«bs»r_«bs».__«bs»m_«bs»s_«bs».
$nl$
Denne størrelse angiver ankomsthastigheden for forespørgsler. Er gennemgående
eneste størrelse der skal varieres for at ændre på belastningen.
$nl2$
_«bs»p_«bs»l_«bs»a_«bs»d_«bs»e_«bs»l_«bs»a_«bs»g_«bs»e_«bs»r_«bs»t_«bs»i_«bs»d__«bs»f_«bs»o_«bs»r__«bs»d_«bs»i_«bs»s_«bs»k__«bs»1__«bs»t_«bs»i_«bs»l__«bs»4_«bs».
$nl$
Simulatoren er konstrueret så generel, at der kan kobles et pladelager til
inputprocessen.
(Derfor er der 4 diske).
Pladelagertid skal kun ses
som positioneringstiden ved en pladelagertilgang.
$nl2$
_«bs»O_«bs»v_«bs»e_«bs»r_«bs»f_«bs»ø_«bs»r_«bs»s_«bs»e_«bs»l_«bs»s_«bs»t_«bs»i_«bs»d
$nl$
Betragtes som ens for de 3 indgående pladelagre. Overførselstiden
simuleres både i diskkanalen (DISKKONTROL) og i selve (DISK'en).
Under overførselstiden vil diskkanalen være reserveret af det
pladelager som ønsker overførsel af data.
$nl2$
_«bs»M_«bs»i_«bs»n_«bs»i_«bs»m_«bs»a_«bs»l__«bs»o_«bs»g__«bs»m_«bs»a_«bs»k_«bs»s_«bs»i_«bs»m_«bs»a_«bs»l__«bs»a_«bs»n_«bs»t_«bs»a_«bs»l__«bs»d_«bs»i_«bs»s_«bs»k_«bs»a_«bs»c_«bs»c_«bs»e_«bs»s_«bs»s_«bs»e_«bs»r__«bs»i__«bs»s_«bs»ø_«bs»g_«bs»e_«bs»-__«bs»o_«bs»g_
$nl$
_«bs»o_«bs»p_«bs»s_«bs»l_«bs»a_«bs»g_«bs»s_«bs»p_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs»s_«bs»e_«bs»n_«bs».
$nl$
opslagsprocessen.
$nl$
For at simulere en variation i antallet af diskaccesser fra forespørgsel
til forespørgsel trækkes et tilfældigt tal mellem en nedre og en øvre grænse
for antallet af pladelagertilgange.
Det gennemsnitlige antal pladelagertilgange vil således ligge midt i mellem disse
to værdier.
$nl2$
_«bs»P_«bs»l_«bs»a_«bs»d_«bs»e_«bs»l_«bs»a_«bs»g_«bs»e_«bs»r__«bs»t_«bs»i_«bs»l_«bs»g_«bs»a_«bs»n_«bs»g_«bs»s_«bs»s_«bs»a_«bs»n_«bs»d_«bs»s_«bs»y_«bs»n_«bs»l_«bs»i_«bs»g_«bs»h_«bs»e_«bs»d__«bs»i__«bs»o_«bs»u_«bs»t_«bs»p_«bs»u_«bs»t_«bs»p_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs».
$nl$
Da antallet af pladelagertilgange i outputprocessen er særdeles få og
formentlig kun er ca. 1 for hver 10. forespørgsel, gives som
inddata til simulatoren en sandsynlighed for
en diskaccess.
$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»C_«bs»P_«bs»U_«bs»-_«bs»t_«bs»i_«bs»d__«bs»f_«bs»o_«bs»r__«bs»d_«bs»e__«bs»4__«bs»p_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs»s_«bs»e_«bs»r_«bs».
$nl$
Dette angiver, hvor lang tid en forespørgsel skal benytte CPU-en i
en proces. For søge- og opslagsprocessen bliver CPU-tidskravet fundet
ud fra en eksponentialfordeling med inddata som gennemsnit. For input-
og outputprocessen vil forespørgslen benytte et konstant CPU-tidskrav.
(Dette har ved simulering vist sig bedre end en eksponentialfordeling.)
$nl2$
_«bs»S_«bs»k_«bs»i_«bs»f_«bs»t_«bs»e_«bs»t_«bs»i_«bs»d
$nl$
Angiver den tid monitoren (betegnes i simulatoren PROCESSTYRING)
er om at skifte mellem to processer.
$nl2$
_«bs»T_«bs»i_«bs»d_«bs»s_«bs»k_«bs»v_«bs»a_«bs»n_«bs»t
$nl$
Angiver den tidsskive en proces får tildelt.
$nl2$
Startværdi for tilfældighedsgenerator.
$nl$
Ved alle fordelinger i SIMULA skal angives en startværdi.
$nl$
_«bs»S_«bs»i_«bs»m_«bs»p_«bs»e_«bs»r_«bs»i_«bs»o_«bs»d_«bs»e
$nl$
Angiver, hvor lang tid der skal simuleres. Normalt simuleres i en time.
(3.600.000 tidsenheder.)
$nl$
_«bs»O_«bs»v_«bs»e_«bs»r_«bs»g_«bs»a_«bs»n_«bs»g_«bs»s__«bs»s_«bs»a_«bs»n_«bs»d_«bs»s_«bs»y_«bs»n_«bs»l_«bs»i_«bs»g_«bs»h_«bs»e_«bs»d_«bs»s__«bs»m_«bs»a_«bs»t_«bs»r_«bs»i_«bs»x_«bs».
$nl$
Ud fra denne bestemmes forespørgslernes vej gennem processerne.
De indgående sandsynligheder angiver sandsynligheden for, at
en forespørgsel passerer fra en proces til en anden.
Matricen beskriver således, hvor hyppigt de enkelte forespørgselstyper
forekommer, og den beskriver forespørgselsmønsteret.
$nl$
_«bs»D_«bs»u_«bs»b_«bs»l_«bs»e_«bs»r_«bs»i_«bs»n_«bs»g__«bs»a_«bs»f__«bs»s_«bs»ø_«bs»g_«bs»e_«bs»p_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s__«bs»o_«bs»g__«bs»d_«bs»a_«bs»t_«bs»a_«bs»k_«bs»a_«bs»n_«bs»a_«bs»l_«bs».
$nl$
Her angives om en dublering ønskes eller ej.
$nl$
_«bs»P_«bs»r_«bs»i_«bs»o_«bs»r_«bs»i_«bs»t_«bs»e_«bs»t_«bs».
$nl$
Prioriteten til de 4 processer angives. Dette vil så have indflydelse
på afviklingsrækkefølgen, i overenstemmelse med scheduleringsstrategien.
$nl2$
_«bs»U_«bs»D_«bs»D_«bs»A_«bs»T_«bs»A_«bs».
$nl$
De fleste
resultater simulatoren giver udskrives for hvert kvarter (1/4 simuleringsperiode) og
samlet for hele simuleringsperioden. Dette er gjort for at kunne iagttage
såkaldte indsvingsfænomener. Hvis simulatoren kører svarende til
en særdeles stor belastning af systemet, vil der ske en ophobning
af forespørgsler.
Dette fænomen
vil man have mulighed for at se, når resultaterne udskrives for
hvert kvarter.
$nl2$
_«bs»F_«bs»o_«bs»r__«bs»h_«bs»v_«bs»e_«bs»r_«bs»t__«bs»k_«bs»v_«bs»a_«bs»r_«bs»t_«bs»e_«bs»r__«bs»o_«bs»g__«bs»s_«bs»a_«bs»m_«bs»l_«bs»e_«bs»t__«bs»u_«bs»d_«bs»s_«bs»k_«bs»r_«bs»i_«bs»v_«bs»e_«bs»s__«bs»f_«bs»ø_«bs»l_«bs»g_«bs»e_«bs»n_«bs»d_«bs»e__«bs»s_«bs»t_«bs»ø_«bs»r_«bs»r_«bs»e_«bs»l_«bs»s_«bs»e_«bs»:
$nl2$
For hver af de 4 processer udskrives:
$nl$
_«bs»a_«bs»n_«bs»t_«bs»a_«bs»l__«bs»f_«bs»o_«bs»r_«bs»e_«bs»s_«bs»p_«bs»ø_«bs»r_«bs»g_«bs»s_«bs»l_«bs»e_«bs»r
$nl$
Benyttes til at kontrolere om overgangssandsynlighedsmatricen fungerer efter
hensigten.
$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»p_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs»t_«bs»i_«bs»d__«bs»o_«bs»g__«bs»v_«bs»a_«bs»r_«bs»i_«bs»a_«bs»n_«bs»s__«bs»p_«bs»å__«bs»d_«bs»e_«bs»n_«bs»n_«bs»e_«bs».
$nl$
Procestiden defineres som den tid en forespørgsel er under behandlig i processen. Dvs. afgangstid-ankomstid = procestid.
$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»C_«bs»P_«bs»U_«bs»-_«bs»t_«bs»i_«bs»d__«bs»o_«bs»g__«bs»v_«bs»a_«bs»r_«bs»i_«bs»a_«bs»n_«bs»s__«bs»p_«bs»å__«bs»d_«bs»e_«bs»n_«bs»n_«bs»e_«bs».
$nl$
CPU-tiden gives som beskrevet ovenfor som inddata til simulatoren. Denne
størrelse indikere så om SIMULA-funktionen NEGEXP giver den rigtige
middelværdi.
CPU-tiden defineres som den tid en forespørgsel benytter CPU.
$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»k_«bs»ø_«bs»t_«bs»i_«bs»d__«bs»o_«bs»g__«bs»v_«bs»a_«bs»r_«bs»i_«bs»a_«bs»n_«bs»s__«bs»p_«bs»å__«bs»d_«bs»e_«bs»n_«bs»n_«bs»e_«bs».
$nl$
Køtiden defineres (som ankomsttiden til en proces - afgangstiden fra
den proces, hvor forespørgslen kom fra.) For denne størrelse og de 2 førnævnte
gælder, at netop disse størrelser måles hos KTAS, så de benyttes
primært til validering af simulatoren.
$nl2$
_«bs»T_«bs»o_«bs»t_«bs»a_«bs»l_«bs»t_«bs»i_«bs»d__«bs»i__«bs»s_«bs»y_«bs»s_«bs»t_«bs»e_«bs»m_«bs»e_«bs»t_«bs».
$nl$
Udskrives for at kunne danne sig et indtryk af multiprogrammeringsgraden.
$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»p_«bs»r_«bs».__«bs»f_«bs»o_«bs»r_«bs»e_«bs»s_«bs»p_«bs»ø_«bs»r_«bs»g_«bs»s_«bs»e_«bs»l__«bs»o_«bs»g__«bs»v_«bs»a_«bs»r_«bs»i_«bs»a_«bs»n_«bs»s__«bs»p_«bs»å__«bs»d_«bs»e_«bs»n_«bs»n_«bs»e_«bs».
$nl$
Den gennemsnitlige svartid for en forespørgsel defineres som summen af samtlige
svartider divideret med antal forespørgsler.
Den gennemsnitlige svartid udskrives både hvor køtiden i inputprocessen
er medregnet, og hvor den ikke er. Den gennemsnitlige svartid uden
køtid fra inputprocessen benyttes til at sammenligne med resultater fra KTAS.
$nl2$
_«bs»a_«bs»n_«bs»t_«bs»a_«bs»l_«bs»f_«bs»e_«bs»j_«bs»l
$nl$
Betegnelsen for en speciel forespørgselstype, som går direkte fra input- til
outputprocessen.
Udskrives for at kunne kontrollere om det er rigtig overgangssandsynlighedsmatrix.
$nl2$
_«bs»U_«bs»d_«bs»n_«bs»y_«bs»t_«bs»t_«bs»e_«bs»l_«bs»s_«bs»e_«bs»s_«bs»g_«bs»r_«bs»a_«bs»d__«bs»a_«bs»f__«bs»i_«bs»n_«bs»p_«bs»u_«bs»t_«bs»-_«bs»,_«bs»s_«bs»ø_«bs»g_«bs»e_«bs»-_«bs»,_«bs»o_«bs»p_«bs»s_«bs»l_«bs»a_«bs»g_«bs»s_«bs»-__«bs»o_«bs»g__«bs»o_«bs»u_«bs»t_«bs»p_«bs»u_«bs»t_«bs»p_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs».
$nl$
Benyttes til en præstationsvurdering af OP-systemet. Udnyttelsesgraden
defineres (som forbrugt CPU-tid i en proces/simperiode.)
$nl2$
_«bs»U_«bs»d_«bs»n_«bs»y_«bs»t_«bs»t_«bs»e_«bs»l_«bs»s_«bs»e_«bs»s_«bs»g_«bs»r_«bs»a_«bs»d__«bs»a_«bs»f__«bs»d_«bs»i_«bs»s_«bs»k_«bs»1_«bs»,_«bs»d_«bs»i_«bs»s_«bs»k_«bs»2_«bs»,_«bs»d_«bs»i_«bs»s_«bs»k_«bs»3_«bs»,_«bs»d_«bs»i_«bs»s_«bs»k_«bs»4_«bs»,__«bs»d_«bs»i_«bs»s_«bs»k_«bs»k_«bs»a_«bs»n_«bs»a_«bs»l__«bs»o_«bs»g__«bs»c_«bs»p_«bs»u_«bs».
$nl$
Disse størrelser er særdeles interessante, idet de ikke kan måles ved KTAS.
Ved udnyttelses af CPU-en medregnes den del der kommer fra, at der
skiftes mellem processer.
Dvs. udnyttelsen af monitoren.
$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»k_«bs»ø_«bs»l_«bs»æ_«bs»n_«bs»g_«bs»d_«bs»e__«bs»t_«bs»i_«bs»l__«bs»i_«bs»n_«bs»p_«bs»u_«bs»t_«bs»-_«bs»,_«bs»s_«bs»ø_«bs»g_«bs»e_«bs»-_«bs»,_«bs»o_«bs»p_«bs»s_«bs»l_«bs»a_«bs»g_«bs»-__«bs»o_«bs»g__«bs»o_«bs»u_«bs»t_«bs»p_«bs»u_«bs»t_«bs»p_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs».
$nl$
Disse størrelser som heller ikke kan måles hos KTAS, udskrives bl.a.
for at kunne sammenligne resultaterne med Little's lov.
$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»k_«bs»ø_«bs»l_«bs»æ_«bs»n_«bs»g_«bs»d_«bs»e__«bs»f_«bs»o_«bs»r__«bs»d_«bs»i_«bs»s_«bs»k_«bs»k_«bs»a_«bs»n_«bs»a_«bs»l__«bs»o_«bs»g__«bs»a_«bs»k_«bs»t_«bs»i_«bs»v_«bs»k_«bs»ø_«bs».
$nl$
Interessante størrelser for evalueringsstudiet.
$nl2$
_«bs»A_«bs»n_«bs»t_«bs»a_«bs»l__«bs»p_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs»s_«bs»k_«bs»i_«bs»f_«bs»t_«bs»,_«bs»p_«bs»l_«bs»a_«bs»d_«bs»e_«bs»l_«bs»a_«bs»g_«bs»e_«bs»r_«bs»t_«bs»i_«bs»l_«bs»g_«bs»a_«bs»n_«bs»g_«bs»e_«bs».
$nl$
Disse størrelse udskrives, idet de skal anvendes i forbindelse
med en teoretisk model af OP-systemet.
$ns 1,4,_«bs»4_«bs»._«bs»3_«bs»._«bs»Æ_«bs»n_«bs»d_«bs»r_«bs»i_«bs»n_«bs»g_«bs»e_«bs»r__«bs»d_«bs»e_«bs»r__«bs»k_«bs»a_«bs»n__«bs»f_«bs»o_«bs»r_«bs»e_«bs»t_«bs»a_«bs»g_«bs»e_«bs»s__«bs»i__«bs»m_«bs»o_«bs»d_«bs»e_«bs»l_«bs»l_«bs»e_«bs»n_«bs».$
_«bs»D_«bs»u_«bs»b_«bs»l_«bs»e_«bs»r_«bs»i_«bs»n_«bs»g__«bs»a_«bs»f__«bs»s_«bs»ø_«bs»g_«bs»e_«bs»p_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs».
$np$
Ud fra eksperimenter med simulatoren og ud fra målinger på OP-systemet,
blev det hurtigt klart, at den mest belastede proces var søgeprocessen.
Specielt ved en model med lille mellemankomsttid (særdeles stor belastning)
for forespørgsler, kan man formode, at det er muligt at øge gennemstrømningen.
Udvidelsen skal begrænses til en dublering af søgeprocessen.
$nl$
Et eksempel kan vise tidsgevinsten ved at anvende 2 søgeprocesser.
$nl$
_«bs»E_«bs»k_«bs»s_«bs»e_«bs»m_«bs»p_«bs»e_«bs»l_«bs».
$nl20$
$np$
Hvis 2 processer skal medtages i modellen kræves der logiske ændringer i
komponenterne OVERGANG og DISKKONTROL.
$np$
I simulatormodellen identificeres hver proces med et tal. I modellen uden dublering
er søgeprocessen karakteriseret ved tallet 2. Da de eksisterende 5 processer
(input-,søge-,opslag-,output- og statistikprocessen) beslaglægger tallene 1,2,3,4 og 5, tildeles den nye søgeproces tallet 6. Ved brug af overgangsmatricen,
når en forespørgsel er færdig ved denne nye proces, må vi derfor lade som om
den
stadig svarer til "2", ellers må denne matrice ændres.
$np$
I OVERGANG skal forespørgsler, der før blev sat i kø til søgeprocessen,
nu sættes i kø til 2 søgeprocesser.
Der er valgt en simpel fordelingsstrategi mellem de dublerede processer,
men en strategi, der med hensyn til at maksimere
gennemstrømningen forekommer optimal.
$nl$
Strategi:
$lm20$$nl$
Hvis proces 1 er optaget og proces 2 ledig sættes forespørgslen i kø ved
proces 2 ellers altid ved proces 1.
$nl$
Hvis en forespørgsel ved proces 2 er færdigbehandlet og køen ved proces 1 indeholder mere
end en forespørgsel overflyttes forespørgsel nr. 2 fra proces 1 til proces 2.
$lm0$$nl$
$np$
I DISKKONTROL bevirker dubleringen flg. forholdsregler:
$nl$
Da de 2 søgeprocesser godt kan anmode om pladelagertilgang indenfor samme tidsperiode, må der være en kø (SOEGEDISKKOE) til søgedisken, som jo ikke er dubleret.
$np$
Når en søgeproces anmoder om pladelagertilgang undersøges så, om datakanalen er
optaget af pladelageroverførsel, samt om søgedisken allerede er allokeret til en
anden søgeproces.
Så snart DISKKONTROL aktiveres fra DISK med besked om, at en pladelageroverførsel fra
søgedisken er afsluttet, undersøges om SOEGEDISKKOE er tom. Hvis
den anden proces er sat i kø initieres søgedisken atter for at simulere pladelagertilgang for denne proces.
$nl2$
_«bs»D_«bs»u_«bs»b_«bs»l_«bs»e_«bs»r_«bs»i_«bs»n_«bs»g__«bs»a_«bs»f__«bs»d_«bs»a_«bs»t_«bs»a_«bs»k_«bs»a_«bs»n_«bs»a_«bs»l_«bs».
$np$
Vi har også fundet det interessant at undersøge om belastningen af datakanalen, implementeres ved
DISKKONTROL, kan være så væsentlig en faktor i belastningen af den
totale model, at en dublering af denne ressource, vil give en præstationsforbedring for svartiden for en forespørgsel.
$np$
Ved dublering af DISKKONTROL har vi valgt at lade den ene datakanal styre kommunikationen mellem søgeproces(ser) og søgedisken, og den anden styre kommunikationen
mellem henholdsvis opslagsproces og opslagdisk samt outputproces og outputdisk.
$nl$
Alle 3 processer er i gang med en pladelagertilgang (søgeprocessen
er ikke dubleret). Med * er på figur 7.4.2 markeret, når en overførsel
ønskes initieret:
$nl10$
_«bs»Æ_«bs»n_«bs»d_«bs»r_«bs»i_«bs»n_«bs»g_«bs»e_«bs»r__«bs»i__«bs»m_«bs»o_«bs»d_«bs»e_«bs»l_«bs»l_«bs»e_«bs»n
$np$
Væsentligste ændring i modellen ved 2 datakanaler er at variable,
der måler egenskaber ved datakanalen må ændres til array variable, der
kan indeholde 2 værdier. Til at måle længden af køen til datakanalen, kaldes
en komponent KANALKOE med samme logik som KOELENGDE.
$nl2$
_«bs»P_«bs»r_«bs»i_«bs»o_«bs»r_«bs»i_«bs»t_«bs»e_«bs»r_«bs»i_«bs»n_«bs»g__«bs»a_«bs»f__«bs»p_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs»s_«bs»e_«bs»r_«bs».
$np$
For at eksperimentere med den rækkefølge, hvori komponenten PROCESSTYRING udvælger
processerne til CPU-allokering indføres en simpel form for prioritering
af de 4 processer.
$nl$
prioriteringen af de 4 processer bevirker at:
$lm20$$sb 6,^$$nl$
$lt 1,^^^a)$
hvis 2 processer har samme prioritet gælder de hidtidige indsættelsesregler i
AKTIVKOE (køen af ventende processer til CPU).
$nl$
$lt 1,^^^b)$
hvis 2 processer har forskellig prioritet, indsættes processen med højst
prioritet foran processen med lavere prioritet uanset, hvad størrelsen
tidskvant indikere (se afsnit 3)
$nl$$lm0$
$np$
Konsekvensen af disse principper er bl.a. at hvis en proces som den eneste
har en højere prioritet end alle de andre, vil denne proces kunne afvikle lige
så længe der ønskes (kun afbrudt af processkiftetid). Hvis f.eks. 2
processer har samme og højere prioritet, vil disse 2 processer køre,
så længe der er forespørgsler til dem.
$nl2$
_«bs»Æ_«bs»n_«bs»d_«bs»r_«bs»i_«bs»n_«bs»g_«bs»e_«bs»r__«bs»i__«bs»m_«bs»o_«bs»d_«bs»e_«bs»l_«bs»l_«bs»e_«bs»n
$np$
Modificeringer i modellen ved implementering af denne facilitet sker i
komponenten KOEINDSAET. Ved hjælp af en pegepind gennemløbes AKTIVKOE'en,
når et nyt procesnummer (repræsentation af een proces) skal indsættes i denne kø. Pegepinden sættes til at
pege på den første proces i køen, med prioritet "=" eller "<" end
prioriteten for den proces, der ønskes indsat. Hvis alle komponenter i AKTIVKOE
har
højere prioritet sættes processen ind bagest i køen.
$np$
Hvis nu en proces, der ønskes indsat i grundmodellen (dvs. uden prioritering)
skulle have været bagest i AKTIVKOE, indplaceres den nu bagest blandt processerne
i AKTIVKOE med samme prioritet. Skulle den normalt have været forrest i AKTIVKOE,
indsættes processen foran den proces pegepinden peger på.
$rh 1,AFPRØVNING$
$ps0$
$ns 1,4,_«bs»5_«bs»._«bs»A_«bs»f_«bs»p_«bs»r_«bs»ø_«bs»v_«bs»n_«bs»i_«bs»n_«bs»g_«bs».$
$np$
Dette afsnit indeholder en beskrivelse af, hvordan simulatoren er afprøvet.
Først omtales, hvilken form for strategi, der er blevet benyttet. Herefter
redegøres der for afprøvningen af de enkelte programdele.
$np$
Det er nok på sin plads først at konkretisere, hvad der menes med termen
afprøvning. I dette afsnit vil simulatorens nøjagtighed i forhold til
resultater opnået ved målinger på OP-systemet ikke blive vurderet. En sådan
egentlig validering er foretaget i afsnit 6, hvor simulatorens
uddata for givne variationer i inddata sammenholdes med empirisk målte
resultater ved KTAS.
$np$
En decideret afprøvningsstrategi er ved udviklingen af simulationsmodellen ikke
let at planlægge. Da modelopbygningen og kalibreringen af modellen sker
dynamisk fra grunden af, ændrer modellen karakter kontinuerligt, selvom
visse overordnede strukturer og modelkomponenternes funktion ikke
ændres undervejs.
$np$
Afprøvningen har derfor nødvendigvis måtte ske under implementeringen. Til
selve afprøvningen er udviklet en sporingsrutine SPOR, der
aktiveres under fejlfindingsarbejdet. SPOR giver et meget
nyttigt tidsbillede af de enkelte programkomponenters aktivering. Et
eksempel på uddata ved spor er vedlagt som bilag 3.
$np$
For at konstatere om modellen giver de ønskede værdier på de udvalgte
præstationsindeks er udarbejdet en udskrivningsprogramdel (SKRIVRESULTAT).
Denne programdel udregner og udskriver de ved simuleringen opnåede måleresultater.
Ved variation i belastningen til modellen kan SKRIVRESULTAT verificere
de enkelte komponenters virkemåde. Et eksempel på uddata fra SKRIVRESULT
er vedlagt som bilag 3.
$rh 1,VALIDERINGSFORLØB$
$nl2$
Afprøvning af programdele.
$np$
Generelt er der ikke sket nogen afprøvning af de enkelte
modelkomponenter enkeltvis, idet den "totale" simulators funktionsduelighed
har været centrum - jvf. bemærkningerne em at simulatoren kontinuerlig
modificeres.
$np$
Vi ser først på de 4 processer ( søge, opslag, input og output).
$np$
Antallet af forespørgsler til disse processer bestemmes i modellen
v.h.a. komponenten OVERGANG. Overgangsmatricen, der afbilder en
forespørgsels sandsynlighed for at gå fra en proces til en anden, er vist i
bilag 4. Det skal bemærkes, at indices refererer til:
$nl$
$sj$
1) input - 2) søge - 3) opslag - 4) output - 5) statistik

$rj$$nl$
Antallet af forespørgsler ( i % ) ialt i hver proces kan let beregnes
fra matricen:
$sj$

INPUTPROCES=OUTPUTPROCES= 100 % (alle må igemnem disse)
= STATISTIK
SØGEPROCES = 66 % (fra INP. til SØG)
OPSLAGPROCES = = 59.2 % (fra INP til OPS +
58 % af SØGE)
$rj$$nl$
At antallet af modellens forespørgsler modsvarer de empirisk beregnede
kan ses på bilag 4.
$sj$

beregnet genererede afvigelse
søge 308.22 306 < 1 %
opslag 276.84 280 ca.1 %

$rj$$nl$
$nl$
SPOR
$np$
For at lette fejlfinding ved implementeringen af simulatormodellen
kan der (valgfrit), udskrives et spor (Eng. trace) af
væsentlige begivenheder under simuleringen. Hvis variablen TEST har
værdien 1 udskrives sporet.
Udover den udskrivning SPOR bevirker, udskrives adskillige
andre sporlinier. (F.eks. i PROCESSTYRING og OVERGANG).
Normalt kaldes SPOR første gang en proces aktiveres, og
når den forlader processen endeligt.
$np$
Da det eksakte programforløb -scheduleringsrækkefølgen og
-tiden- kan aflæses af udskriften, kan logiske fejl i
programmel aflæses forholdsvis let ved granskning af sporet.
$nl2$
SKRIVRESULTAT
$np$
For at dokumentere simulatorens funktionsduelighed,
og sandsynliggøre at beregningprocedurer m.m. fungere efter hensigten
er i bilag 3 vist et eksempel på en kørsel:
$np$
Inddata til simulatoren udskrives på side 1 og 2 af procedure
SKRIVINPUT.
$np$
Vi vil eftervise tallene for gnst. procestid i eksemplet.
(Gnst. CPU-tid uinteressant da tallet fremkommer ved tilfældighedsgenerator,
mens der ved beregning af gnst. køtid er for mange ubekendte eller usikre
variable.)
$np$
Vi kan ud fra inddata lave flg. rimelige forudsætninger ved beregning af
en procestid:
$sj$

procestid = CPUTID + DISKTID + overhead ved processkift
+ ventetid i aktivkø

CPUTID = inddata-værdi

DISKTID = p(pladelagertilgang)*(accestid+overførselstid)*
antal pladelagertilgange
OVERHEAD v.= minimum ca. 25 % af CPU-tid
PROCESSKIFT Findes ved s.4 i bilag 3 at udregne
forholdet belastning ved processkift 0.112
__________________________ _____
belastning ved processing 0.355

VENTETID I
AKTIVKØ = 5-30 % af CPU-tid
(skøn ud fra udnyttelsesgrader af processer)
$rj$$nl2$
$np$
Da indflydelse af pladelagertilgang også må medregnes,
har vi slået de sidste 2 faktorer sammen (kaldes så OVERHEAD)
og sat deres værdi lig 0.25*(CPU+DISKTID)
$np$
Vi kan nu opstille en afprøvningstabel(tal i ms.
$sj$

PROCES CPU-TID DISKTID OVERHEAD BEREGNET PROCESTID AFG
TID MÅLT
_______________________________________________________________
INPUT 16.33 - 4.08 20.41 20.69 1%
SØGE 173.33 3.5*54=189 90.5 452.83 437.99 4%
OPSLAG 66.34 2.0*54=108 43.5 217.84 227.20 4%
OUTPUT 8.92 0.07*54=4 3.18 15.88 14.79 7%
________________________________________________________________

$rj$
$np$
Tabellen viser, at modellen ud fra de givne inddata og
forudsætninger producerer resultater, som vi ville forvente.
(om så modellen afbilder OP-systemet er en
ganske anden sag, som er belyst i valideringsafsnittet).
$np$
Beregning af varians sker ved flg. formel
-REAL PROCEDURE BEREGNVAR i programmet -
$nl$
$sj$

varians på måleserie =

$rj$$nl$
Formlen sparer n subtraktioner i forhold til
det normale udtryk for varianse.
$nl3$
Udnyttelsesgraden af diske er jvf. bilag 3 s.4.
$sj$
DISK beregnet målt
____________________________________________
SØGE = 24.5 % 23.0 %
OPSLAG = 13.6 % 12.3 %
OUTPUT = 0.77 % 0.77%
______________________________________________
$rj$$nl$
Udnyttelse af proceser (kun CPU-behandling) er korrekte jvf. bilag 3 s.4.
$sj$

PROCES forventet målt
____________________________________________
INPUT = 3.1 % 3.3 %
SØGE =22.6 % 21.9 %
OPSLAG = 8.4 % 8.5 %
OUTPUT = 1.82 % 1.95 %
_____________________________________________

$rj$$nl$$np$
Kølængde kan ikke umiddelbart eftervises. Det bør bemærkes,
at de målte kølængder er for proceskøer
inclusive jobbet, der i øjeblikket er kørende eller er i aktivkø.
$rh 1,VALIDERINGSFORLØB$
$ps0$
$ns 1,4,_«bs»6_«bs»._«bs»V_«bs»a_«bs»l_«bs»i_«bs»d_«bs»e_«bs»r_«bs»i_«bs»n_«bs»g_«bs»s_«bs»f_«bs»o_«bs»r_«bs»l_«bs»ø_«bs»b_«bs».$
$np$
Dette afsnit beskriver den udviklingsproces simulatoren har gennemløbet.
Processen er foregået over en tidsperiode på ca. 1/2 år og har været
ret tidskrævende.
Årsagen til det forholdsvise langvarige udviklingsarbejde, er at
indførte ændringer undervejs har tenderet til at
til at øge kompleksiteten af simulatoren.
Dette har derfor bevirket, at det har været vanskeligt at ændre i simulatoren.
$np$
Ved beskrivelsen af udviklingsforløbet vil der blive skelnet
mellem 2 grundmodeller af simulatoren.
At det ikke fra starten
har været muligt at konstruere en fast model til at simulere en RC8000 ved OP-systemet
skyldes i første række, at kendskabet til en RC8000 ikke var stort nok. Mangler

i kendskabet til RC8000 skyldes at dokumentationen til RC8000 ikke helt
afspejler de aspekter, som har været væsentlige i forbindelse med konstruktionen
af simulatoren. Manglerne her refererer primært til den scheduleringsstrategi, der
anvendes på en RC8000. Beskrivelsen af denne
i RCSL no. 31-d476 RC8000 MONITOR PART 1 SYSTEM DESIGN
side 43-46
er ret kortfattet, og derved ikke helt præcist dækkende
de facetter som anvendes til konstruktionen af simulatoren.
$np$
Når resultaterne fra simulatoren sammenlignes
med resultaterne opnået ved målinger på OP-systemet, har vi valgt at gøre dette
ud fra timer, hvor der behandles ca. 2000 forespørgsler.
En belastning på 2000 forespørgsler pr. time svarer til en gennemsnitlig belastning .
$ns 1,4,_«bs»6_«bs»._«bs»1_«bs»._«bs»R_«bs»O_«bs»U_«bs»N_«bs»D_«bs»-_«bs»R_«bs»O_«bs»B_«bs»I_«bs»N_«bs».$
$np$
På et tidligt tidspunkt i udviklingen af simulatoren, skete tildelingen af CPU-tidskvanter efter en gængs
ROUND-ROBIN strategi. Processtyringen foregik ved,
at processerne cyclisk blev allokeret CPU-tid såfremt, de havde behov
for det( se figur 6.1). Processerne fik altid tildelt hele tidskvantet på 25.6 ms, idet kontrollen blev overdraget til processtyringskomponenten, hvis ikke hele
tidskvantet behøvedes.
$nl$$sj$

--------------------------------------------
! !
! !
! ----- ----- ----- ----- !
! ! ! ! ! ! ! ! ! !
--->! ? !-->! ? !-->! ? !-->! ? !------->--
! ! ! ! ! ! ! !
----- ----- ----- -----
input søge opslag output

?: Har processen behov for CPU.
Hvis ja, alloker CPU'en.
Hvis nej, gå til næste proces.

figur 6.1

$rj$
Resultaterne fra kørsler med denne simulator er ikke umiddelbart sammenlignelige
med resultater opnået ved målinger på OP-systemet. Dette skyldes, at
under udformningen af denne model, havde vi ikke viden om antallet af pladelagertilgange
i de enkelte processer.
Imidlertid var antallet af pladelagertilgange og deres tidsforbrug sat til sådanne

størrelser, at en vis sammenligning kan foregå.
Tabel 6.1 viser, hvilke resultater og nøjagtigheden af resultaterne
ved kørsler med denne simulatortype.
Det bemærkes, at simulatoren er kørt under forudsætning af, at
der er mellem 4 og 6 pladelagertilgange for en forespørgsel i
søgeprocessen. I opslagprocessen er antallet mellem 1 og 3. Derudover
antages, at en pladelagertilgang tager 38.0 ms. Ved outputprocessen er
ingen pladelagertilgange.
$sj$

målinger simulator afg. i %

INPUT-proces
antal forsp. 1999 1910 4.4
procestid 21.16 16.35 22.7
CPU-tid 16.22 15.41 5.0
køtid ? ? -

SØGE-proces
antal forsp. 1336 1204 9.9
procestid 399.3 465.9 16.7
CPU-tid 180.3 185.1 2.6
køtid 36.4 79.9 119.5

OPSLAG-proces
antal forsp. 1196 1201 0.4
procestid 160.4 150.9 5.9
CPU-tid 66.4 61.4 7.5
køtid 12.8 27.7 116.4

OUTPUT-proces
antal forsp. 1999 1910 4.4
procestid 11.6 7.9 31.9
CPU-tid 8.8 7.7 12.5
køtid 8.4 35.6 316.3

Gnst. svartid 437.1 516.0 18.1

tabel 6.1

$rj$$nl$
Det bemærkes, at ved denne model beregnedes køtiden ved inputprocessen ikke.
$np$
For ROUND-ROBIN gælder, at afvigelses i svartiden er for stor. Derudover er
afvigelserne ved køtiderne ved processerne for store. Da køtiden hænger sammen
med, hvordan der scheduleres blev det hurtigt klart, at det var nødvendigt
at ændre scheduleringsstrategien.
$ns 1,4,_«bs»6_«bs»._«bs»2_«bs»._«bs»M_«bs»o_«bs»d_«bs»i_«bs»f_«bs»i_«bs»c_«bs»e_«bs»r_«bs»e_«bs»t__«bs»R_«bs»O_«bs»U_«bs»N_«bs»D_«bs»-_«bs»R_«bs»O_«bs»B_«bs»I_«bs»N_«bs».$
$np$
Denne simulationsmodel bygger på den specielle scheduleringsstrategi, som
anvendes ved en RC8000. De første kørsler med denne model blev
foretaget uden at diskkanalen var implementeret. Resultaterne
fra disse kørsler er angivet i tabel 6.2. Tabellen er lavet på
baggrund af en kørsel, hvor antal pladelagertilgange i søgeprocessen er mellem
2-5, i opslagprocessen er det mellem 1 og 3, og sandsynligheden for en
pladelagertilgang i outputprocessen er 0.06. Derudover er skiftetiden,
dvs. den tid det tager at skifte mellem to processer sat til 3.9 ms.
$sj$

målinger simulator afg. i %

INPUT-proces
antal forsp. 1999 2257 12.9
procestid 21.16 19.4 8.3
CPU-tid 16.22 16.1 0.7
køtid ? 6.23 -

SØGE-proces
antal forsp 1336 1426 6.7
procestid 399.3 354.7 11.2
CPU-tid 180.3 167.9 6.9
køtid 36.4 75.0 106.0

OPSLAG-proces
antal forsp. 1196 1384 15.7
procestid 160.4 160.0 0.2
CPU-tid 66.4 60.3 9.2
køtid 12.8 54.3 324.2

OUTPUT-proces
antal forsp. 1999 2257 12.9
procestid 11.6 12.7 9.5
CPU-tid 8.8 8.6 2.3
køtid 8.4 9.5 13.0

Gnst. svartid 437.1 446.6 1.7

tabel 6.2

$rj$$nl$
Resultaterne vist i tabel 6.2 fra de første kørsler med modificeret
ROUND-ROBIN viser pånær køtiderne en pæn overenstemmelse med målingerne.
Både ved kørsler med simulatoren og ud fra målinger på OP-systemet har det vist
sig, at der er særdeles stor variation på køtiden. Ved at ændre
på antallet af pladelagertilgange og processkiftetiden har køtiden ved f.eks.
søgeprocessen svinget mellem 56.9-119.9 ms.
$np$
Ved dette punkt i forbindelse med udviklingen af simulatoren fremkom nogle oplysninger
om antallet af pladelagertilgange og diskkanalen. Dette førte så til fastlæggelsen
af den endelige simulator model.
$np$
Den eneste størrelse der herefter er ukendt er skiftetiden
mellem to processer. For at ligge sig fast på en størrelse for en endelig værdi
af denne blev tre kørsler foretaget.
Her viste det
sig, at en skiftetid på 1.5 ms var mest nøjagtig.
$sj$

Skiftetid 1.0 1.5 2.0 I virkeligheden

gnst. svartid 436.6 ms 437.6 ms 467.7 ms 437.1 ms

tabel 6.4
$rj$
$nl$
På baggrund af disse tal blev de endelige kørsler foretaget med en
skiftetid på 1.5 ms. Typen med en skiftetid på 2.0 forkastedes, da
svartiden var for unøjagtig. Af de to sidste typer er der ikke den stor
forskel i nøjagtigheden ved svartiden, men det viste sig at den valgte
var mere nøjagtig for proces- og køtiden ved opslagprocessen.
$np$
Til beskrivelse af simulatoren nøjagtighed kan følgende to
tabeller anføres. Resultaterne i tabel 6.4 bygger på 2000 forespørgsler pr
time og tabel 6.4 bygger på 6000 forespørgsler pr time.
$sj$

målinger simulator afg. i %
INPUT-proces
antal forsp. 1999 2012 0.7
procestid 21.16 17.73 16.2
CPU-tid 16.22 16.3 0.5
køtid ? 3.1 -
SØGE-proces

antal forsp. 1336 1310 1.9
procestid 399.3 418.2 4.7
CPU-tid 180.3 175.8 2.6
køtid 36.4 52.9 45.2

OPSLAG-proces
antal forsp. 1196 1204 0.6
procestid 160.4 160.4 0.0
CPU-tid 66.4 67.9 2.3
køtid 12.8 6.8 46.8

OUTPUT-proces
antal forsp. 1999 2012 0.6
procestid 11.6 10.9 6.0
CPU-tid 8.8 9.0 2.7
køtid 8.4 2.2 74.4

Gnst. svartid 437.1 437.6 0.1

tabel 6.4

$rj$$nl$
Til disse resultater kan anføres, at samtlige størrelser pånær
køtiden viser en meget stor overenstemmelse mellem simulatoren og de målte
resultater ved KTAS. For køtiden gælder, at for både søge- og opslagprocessen er der stor
variation i måleresultaterne. Således varierer køtiden ved søgeprocessen
mellem 12.63 og 64.53 ved målingerne. Ved kørsler med simulatoren har det også vist
sig, at størrelsen variere meget afhængig af, hvilkebn startværdi, der
ngives til tilfældighedstalsgeneratoren. De samme forhold
gælder ved køtiden ved opslagprocessen. Ved opslagprocessen viser
målinger en variation mellem 9.02 og 18.80.
$sj$

målinger simulator afg. i %

INPUT-proces
antal forsp. 5993 6142 2.5
procestid 30.7 18.8 38.7
CPU-tid 16.8 16.3 2.7
køtid ? 6.6 -

SØGE-proces
antal forsp. 3858 4030 4.4
procestid 425.9 452.2 6.1
CPU-tid 172.0 182.4 6.0
køtid 315.9 318.1 0.7

OPSLAG-proces
antal forsp. 3618 3710 2.5
procestid 193.7 176.1 9.1
CPU-tid 67.2 67.2 0.0
køtid 62.8 20.7 67.0

OUTPUT-proces
antal forsp. 5993 6142 2.5
procestid 16.9 10.9 35.7
CPU-tid 9.0 9.0 0.0
køtid 11.7 3.8 67.5

Gnst. svartid 692.0 657.8 4.9

tabel 6.5

$rj$$nl$
Til disse resultater kan anføres at udover køtiderne, er
her også stor afvigelse på procestiden i input- og outputprocessen.
Dette skyldes ganske givet, at vi ikke helt benytter den samme
scheduleringsstrategi ved simulatoren som benyttes i RC8000.
Til køtiden ved outputprocessen kan angives, at ved en belastning
på under 100 forespørgsler pr time har målinger vist, at den er
på omkring 7.2 ms. Dette kommer fra, at når en forespørgsel sendes til outputprocessen
overføres data fra et sted i lageret til et andet sted, og dette tager omkring
7.2 ms. Dette er ikke indbygget i simulatoren, idet vi ud fra målinger på
OP-systemet vidste, at køtiden ved outprocessen, har lille indflydelse på
den gennemsnitlige svartid for en forespørgsel.
$np$
For procestiden ved input- og outputprocessen gælder, at der ved en belastning
på 6000 forespørgsler pr time er ret stor afvigelse. Da de har
særdeles ringe indflydelse på den gennemsnitlige svartid, har vi ikke ment
det var nødvendigt at tilpasse simulatoren bedre.
For til sidst at anskueliggøre, at det er rimeligt at stole
på simulatoren er på figur 6.2 tegnet kurver over svartiden afhængighed
af antallet af forespørgsler pr time. Ud af X-aksen er antallet af
forespørgsler angivet og Y-aksen angiver den gennemsnitlige svartid.
På figuren angiver den stiplede resultaterne fra simulatoren og den
optrukne er fremkommet ud fra målinger i logfilen.
$np$
Kurven viser, at den gennemsnitlige svartid ved simulatoren ligger særdeles
tæt op ad målingerne på svartiden. Det er vanskeligt at få simulatoren
til at passe helt præcist ved små belastninger, idet her er særdeles
stor variation på måleresultaterne.
$nl2$
$ns 1,4,_«bs»7_«bs»._«bs»E_«bs»r_«bs»f_«bs»a_«bs»r_«bs»i_«bs»n_«bs»g_«bs»e_«bs»r__«bs»m_«bs»e_«bs»d__«bs»k_«bs»ø_«bs»r_«bs»s_«bs»e_«bs»l__«bs»m_«bs»e_«bs»d__«bs»s_«bs»i_«bs»m_«bs»u_«bs»l_«bs»a_«bs»t_«bs»o_«bs»r_«bs»e_«bs»n_«bs».$
$np$
Udviklingen af simulatoren beskrevet i denne opgave er
foregået trinvist. Efter færdiggørelsen af en simulationsmodel
som viste sig ikke tilstrækkelig nøjagtig tilføjedes yderligere
detaljering af simulatoren. Et udviklingsforløb som dette
må anses for meget realistisk. Det er meget få store systemer
der kan simuleres nøjagtigt nok ved den første konstruktion af
en simulationsmodel.
Disse problemmer skyldes, at ved et stort datamatisk system, er det
særdeles vanskeligt at afgøre, hvilke faktorer der er væsentlige
i forbindelse med systemets opførsel.
$np$
En simulationsmodel kan således ikke fastlægges engang for altid ved starten af simuleringen.
Dette bevirker, at der tilføjes simulatoren en del ændringer. Da ikke
alle disse ændringer kan forudsiges, vil selve simulationsmodellen
naturligt blive ret kompliceret og programmeringsteknisk mindre pæn.
Disse problemmer har vi naturligvis også haft ved denne opgave.
Specielt ved indførelsen af scheduleringsstrategien og datakanalen har
der været problemmer med at få simulatoren til at fungere korrekt.
Programteknisk er de dele, der simulere disse ting ( DISKKONTROL og
KOEINDSAET) således blevet ret komplicerede.
$np$
Dette har bevirket, at de ændringer vi ønskede at lave,
som dublering af søgeprocessen blev ret komplicerede. Da
det ved simulationskørslerne har vist sig, at der er en særdeles
stor tidsgevinst ved en dublering af søgeprocessen, kunne forsøg
som opspaltning af søgeprocessen være særdeles interessante at foretage.
Imidlertid vil en opspaltning af søgeprocessen kræve en ret stor
ændring i simulationsmodellen så dette er ikke foretaget.
$np$
Udover at simulatoren er blevet kompliceret programteknisk, har
de mange ændringer medført, at simulatoren har været særdeles dyr
når produktionskørsler skal foretages. En simulationskørsel
hvor en belastning på 12000 forespørgsler simuleres tager således
ca. 3 min i CPU-tid. Dette koster omkring 60.00 kr ved normal drift. Da bevillingerne
naturligvis har været begrænsede, har det ikke været muligt at foretage
mange simulationskørsler.
$np$
Et samlet indtryk af erfaringerne må være, at det er særdeles vigtigt
at foretage _«bs»m_«bs»e_«bs»g_«bs»e_«bs»t__«bs»g_«bs»r_«bs»u_«bs»n_«bs»d_«bs»i_«bs»g_«bs»e studier i et datamatisk system før en
simulator til det konstrueres. Ved dette kan man sikkert
undgå mange problemer.
$ef$
scope user vko2
finis
▶EOF◀

DataMuseum.dk

RC4000/8000/9000

⟦b48d5f1fe⟧ TextFile

Derivation

TextFile