Back | Home | Next

Physiology RO

ANNA  K5

@

Home
Glossary
Objectives
Formalism
Morphology
Physiology
Connectors
Serialization
Traits
Methods
Claims
Relations
Dictionary
Core UML
Ring1 Apps
Tiger Server
Features
History
ToDo
Authors
API
Images
ToDo
DNA Declarations
Physiology RO
Real Time RO
ANNA as an Eco System RO
HMM Generator
ERP

 

Revision History

Date/Reviser

Comment

May 18, 2010

Alexandru Mihail

Inceputul documentului

June 13, 2010

Alexandru Mihail

Revenit asupra documentului cu ample completari dupa ce analizorul fiziologic al sistemului ANNA MetaCore 5 a fost implementat si acum poate fi descris.

June 16, 2010

Alexandru Mihail

Sectiuni complete despre tehnici de monitorizare, constructia Monitorului, Trecerile pas-cu-pas, analiza predictiva.

 

 

Contents

 TOC \o "1-3" \h \z \u Revision History. PAGEREF _Toc264437410 \h 1

1        Obiectiv. PAGEREF _Toc264437411 \h 2

2        Domeniul problemei PAGEREF _Toc264437412 \h 2

2.1         Nevoia. PAGEREF _Toc264437413 \h 3

2.2         Metoda. PAGEREF _Toc264437414 \h 3

2.3         Generalizarea metodei PAGEREF _Toc264437415 \h 3

3        Studiu de caz. PAGEREF _Toc264437416 \h 4

3.1         Proces de creare a unei arhive juridice. PAGEREF _Toc264437417 \h 4

3.2         Interfata de control a procesului de codificare. PAGEREF _Toc264437418 \h 4

4        Tehnici de monitorizare. PAGEREF _Toc264437419 \h 5

4.1         Monitorizare prin interlocking (model nemarkovian) PAGEREF _Toc264437420 \h 5

4.2         Monitorizarea prin borne de cod (Checkpoints) PAGEREF _Toc264437421 \h 6

4.3         Monitorizarea prin auto-trace. PAGEREF _Toc264437422 \h 6

4.4         Graful fiziologic. PAGEREF _Toc264437423 \h 7

5        Monitorul fiziologic. PAGEREF _Toc264437424 \h 8

5.1         Lista resurselor PAGEREF _Toc264437425 \h 9

5.2         Lista clientilor PAGEREF _Toc264437426 \h 9

5.3         Lista algoritmilor PAGEREF _Toc264437427 \h 9

5.4         Graful fiziologic. PAGEREF _Toc264437428 \h 10

5.5         Matricea grafului fiziologic. PAGEREF _Toc264437429 \h 11

5.6         Graficul functiei monitorizate. PAGEREF _Toc264437430 \h 11

5.7         Bara de stare. PAGEREF _Toc264437431 \h 12

5.8         Bara de unelte. PAGEREF _Toc264437432 \h 12

6        Tranzitii pas cu pas prin monitor PAGEREF _Toc264437433 \h 13

6.1         Starea #1. PAGEREF _Toc264437434 \h 13

6.2         Starea #2. PAGEREF _Toc264437435 \h 14

6.3         Starea #3. PAGEREF _Toc264437436 \h 15

7        Analiza predictiva. PAGEREF _Toc264437437 \h 16

8        Viitorul sistemului PAGEREF _Toc264437438 \h 17

 

 

NOTA: Materialul acesta contine informatie privilegiata si confidentiala, proprietate a autorului si a societatii Proxima Centuri Romania SRL. Cititorul ia la cunostinta de sensitivitatea materialului si intelege sa respecte toate drepturile de autor, marca, model si brevet de inventie, drepturi morale si patrimoniale derivate din materialul prezentat.

 


 

 

1           Obiectiv

 

Sistemul nostru de operare ANNA Kernel 5 este un nou nivel de inteligenta si de constiinta in lumea virtuala. Celula metamorfica a sistemului intruneste mai multe trasaturi esentiale ale vietii reale. Una dintre calitatile sistemului este abilitatea de auto-morfoza, adica aceea de a-si schimba structurile interne in timpul functionarii. Acesta este un pas semnificativ dincolo de aptitudinile si de ambitiile platformei DotNET si ale masinii Java, ambele cu care ne comparam din multe puncte de vedere. Planurile de detaliu pot fi accesate la www.Anna.ProximaCentauri.ro pentru pe baza de cerere sau de invitatie.

 

In paradigma sistemului nostru, lumea - fie ea reala sau virtuala poate fi caracterizata pe 3 paliere intr-un sistem cartzian de 3 axe: axa topologica - a tuturor obiectelor; axa morfologica - a tuturor tipurilor obiectelor si relatiilor lor de agragare; axa fiziologica - a starilor obiectelor si a evolutiei acestora in timp. Un vector in acest spatiu caracterizeaza la un anumit moment intreaga sa structura, intreaga sa taxonomie, si valoare. In lucrarea de fata ne vom situa in planul topologie-fiziologie.

 

Componenta de timp real a acestui sistem/framework este deosebit de complexa si ridica nenumarate probleme legate de urmarirea functionarii subansamblelor si de interventia utilizatorului in cursul derularii proceselor.

 

Procese precum codificarile si arhivarile cu volum mare de date de intrare necesita forme speciale de reprezentare in interactiunea cu utilizatorul/programator. O fereastra care deruleaza numere nu este nici suficienta si nici concludenta. Monitorizarea unui proces de arhivare prin intermediul log-urilor nu este sugestiva. Asemenea procese se urmaresc cel mai bine cu grafice.

 

Aceasta lucrare va urmari cateva procese de timp real din sistemul de operare ANNA K5, evidentiand posibilitatile si limitele achizitiei de date de performanta din sistem si necesitatile de vizualizare sumarizata. Vom incerca apoi aplicarea unor metode statistice de reprezentare.

 

2           Domeniul problemei

1.      Pe un disc se gasesc n directoare fiecare continand un numar oarecare di (mare - peste 10,000) de documente in format HTML, RTF, TXT, PDF.

2.      Directoarele sunt actualizate prin intermediul unor medii de comunicatii de tip FTP si HTTP.

3.      Fiecare director este reprezentat in sistem printr-un fir de executie zis incarcator care ridica de pe disc fisier cu fisier si pompeaza intr-o coada comuna, de unde urmeaza a fi preluate in lucru de alte procese/fire.

4.      Un motor de codificare preia aceste texte din coada ca sa formeze un numar de dictionare.

5.      Motorul trece fiecare nod prin filtre. Fisierele sistemului gazda sunt pentru noi noduri.

6.      Textul asociat fiecarui nod este transmis cate unui compilator specializat pe cate un tip de fisier: compilatorul de HTML, compilatorul RTF, extractorul TXT, etc.

7.      Rezultatele compilarii sunt apoi transmise catre o anume arhiva in functie de tematica dedusa din document la momentul analizei.

8.      Problema de fond o constituie insonsistenta utilizarii diacriticelor in materialul tehnoredactat de terte persoane. Asimilarea de-a valma a textelor cu si fara diacritice a condus la rezultate satisfacatoare in ce priveste strict arhiva juridica, insa acum urmarim si un alt scop, acela al extragerii din aceste texte a gramaticii statistice a limbii romane. Calitatea acestei gramatici depinde de factori precum gradul de confuzie al termenilor, gradul de disjunctie, de inaccesibilitate al simbolurilor, etc. Vom duce un text care contine cel putin o litera romaneasca in dictionarul cu diacritice, prezumand atunci ca textul a fost tehnoredactat in considerarea diacriticelor. Daca textul nu contine nici o litera cu diacritice, atunci intreg textul este suspect si se va arhiva intr-un alt dictionar. La finalul unei codificari cele doua dictionare vor putea fi comparate si un numar de texte din dictionarul suspect vor putea fi recuperate.

9.      Fiecare arhiva are firul ei propriu de ridicare si bobinaj numite arhivatoare.

10.  Firele de import si arhivare intra in competitie asupra unor resurse comune cum ar fi banda de procesare, alocatorul de memorie, motorul insusi.

11.  O serie de clienti patrund in sistem sa acceseze datele din arhiva. Acestia intra in conflict cu celelallte fire pentru resurse comune precum memoria, coada.

12.  Aceste procese se desfasoara cu zilele, posibil chiar continuu si trebuiesc monitorizate la un nivel suficient de inalt cat rapoartele sa fie inteligibile.

13.  Unele fire (clienti) pot veni si pot iesi din sistem.

2.1         Nevoia

Am dori sa vedem o diagrama care sa descrie sistemul la un nivel optim de detaliu.

1.      Ne intereseaza starea momentana a intregului proces. Starea generala trebuie definita ca un set de stari. Parametrii de stare trebuiesc determinati.

2.      Nu ne poate interesa ce anume a facut un anume fir de executie care a rulat ca toate celelalte pentru cateva minute intr-o zi intre sute de asemenea fire. Ne-ar interesa, insa, sumarul intregii clase careia firul ii apartine.

3.      Ne intereseaza felul in care au fost utilizate resursele. O diagrama Gantt ar fi de dorit.

4.      Daca un algoritm se deruleaza in mod normal in timpul T, atunci in conditii de concurenta acelasi algoritm poate consuma 10*T. Avem nevoie de o metoda de identificare a acelor zone din sistem unde se creaza gatuirile si unde investitia de efort de programare si-ar avea sensul.

5.      Din analiza s-ar putea evidentia unele modele de comportament ale firelor in competitia lor pentru resurse. Aceste modele ar putea fi utile in diagnostic si in rafinarea sistemului.

6.      Pericolul de blocaj prin foamete sau suprasaturare ar trebui din timp identificat si alertat.

2.2         Metoda

Vom face speculatii in jurul unui studiu de caz pe care-l vom prezenta in sectiunile urmatoare: 

1.      In sistem sunt fire in numar fix. Sunt 3 clase de fire: invatatorii, arhivatorii si elevii. Clasele corespund firelor de ridicare de pe disc, de bobinare pe arhiva, si de cautare textuala in arhiva.

2.      Firele utilizeaza resurse. Resursele pot fi asimilate unor stari prin care firele trec. Speculam ca starile vor putea fi fi perechi de genul: FileOpen/FileClose, MemoryAlloc/MemoryFree, Enqueue/Dequeue, Encode/Decode.

3.      Se calculeaza la fiecare oprire a unui fir intr-o stare timpul de stationare si numarul de accesari.

4.      Sistemul determina o secventa, o ordine in care firele fiecarei categorii traverseaza aceste stari.

5.      Sistemul poate astfel forma un graf orientat de trecere dintr-o stare intr-alta.

6.      Graful este calificat cu frecventa cu care firele s-au aflat la noduri.

7.      Aceste frecvente devin probabilitati de prezenta la nod, din care pot fi calculate probabilitatile de trecere pe arcele grafului.

8.      Graful poate fi folosit ca unealta de monitorizare a procesului

9.      Un anume flux teoretic poate fi acum calculat pentru situatia in care am vrea sa se dubleze numarul de fire de intrare.

10.  Ne intereseaza mereu cat avem de asteptat pana la finalul tuturor operatiilor de encodare.

2.3         Generalizarea metodei

ANNA K5 manageriaza raporturile de proprietate dintre fire si resurse si cele de conflict intre fire printr-o structura numita arborele de interlocking.  Acest arbore are la noduri fire si resurse. Teoretic, sistemul ar putea mentine automat o retea marcoviana de trecere intre stari, facand mereu proiectii ale arborelui de interlocking in planul grafului de performanta. Grafurile rezultate sunt in perpetua schimbare, contravenind modelului marcovian. Se pot insa stabili limite ale proiectiei, astfel ca numai nodurile si arcele apartinand unei ramuri (stabile) sa fie proiectate. Un model marcovian ramane valid pana ce o modificare structurala il invalideaza, moment in care acesta este resetat si refacut.

3           Studiu de caz

In cele ce urmeaza vom alege un proces de timp real, il vom caracteriza in termeni de clienti si resurse, apoi ii vom urmari evolutia cu uneltele de diagnostic ale sistemului ANNA K5.

3.1         Proces de creare a unei arhive juridice

1.      Avem 50,000 de fisiere HTML cu legile tarii pe perioada 1880-2009 pe care le vrem codificate in motorul EDICT-GAIUS al sistemului ANNA K5.

2.      Motorul de codificare poate fi considerat ca mergand in perpetuu. Trebuie stiut unde a ajuns, ce mai are de facut, daca poate fi oprit, daca merita sa mai fie lasat sa mearga, etc.

3.      Partea de import si filtre va fi paralelizata pe un numar de 1 - 3 fire de executie.

4.      Partea de admisie in dictionar nu poate fi paralelizata la momentul de fata cu vreun beneficiu real, asa ca fiecare dictionar va avea un singur fir de arhivare.

5.      In sistem sunt o serie de alte fire de executie fara legatura cu problema, dar necesare - ex. firele editorului schematic. Comportamentul acestora ar putea interfera cu codificarea.

3.2         Interfata de control a procesului de codificare


Captura urmatoare surprinde un proces de codificare cu 3 fire de incarcare, 2 dictionare si un fir de bobinare. Prezente in rama sunt interfetele specializate pe probleme independente. In capitolul urmator vom prezenta detaliat interfata generala de analiza a performantei sistemului care aduna intr-un raport comun detaliile fiziologice ale procesului de codificare.

 

Semnificatia panourilor este urmatoarea:

1.      Sistemul nostru are un nucleu/motor si un UI. Captura prezinta interfata utilizatorului la sistemul nostru de operare. Acest UI are natura unui desktop cu utilizari multiple.

2.      Interfata EDICT5-GAIUS5 este unealta specializata in monitorizarea formarii si actualizarii unui dictionar. GAIUS este un navigator pentru asemenea dictionare si este un produs descris la www.proximacentauri.ro/Main/Gaius_Navigator_RO.htm. EDICT5 este mototul de arhivare cu comprtesie gramaticala descris prin "blue-print"-ul EDICT5 RO disponibil la cerere. Din diagnosticele oferite de interfata EDICT5 remarcam: graficul din dreapta sus indica in verde curba de admisie in arhiva a documentelor. In rosu e curba de duplicate gasite in timpul testului (cele 3 fire de admisie aduc aceleasi fisiere si 2/3 sunt respinse de arhivar. Cotul abrupt in sus pe care-l fac curbele se datoreaza unei re-parametrari in cursul analizei.

3.      Interfata alocatorului de memorie, una dintre cele mai importante componente ale sistemului de operare. In fereastra se remarca un obiect de inceput in rosu - sistemul insusi, urmat de doua perechi de benzi (alb,albastru) - cele doua dictionare juridice in curs de formare. O puzderie de mici obiecte si de blocuri amorfe urmeaza dictionarelor si sunt materiale utilizate de firele de incarcare in a filtra textele de intrare (arborii compilarii de la HTML la TXT).

4.      Panoul din partea stanga a UI-ului prezinta o vedere a arborescentei obiectelor sistemului de operare. In aceasta coloana vertebrala - o evolutie a sistemelor de fisier- apar resursele, procesele, utilizatorii si legaturile intre acestea. In zona 4 a arborescentei este expandat directorul HOME unde apar resursele utilizatorului curent care nu sunt montate sub alte noduri de sistem. In HOME remarcam firele de incarcare lansate de utilizator, firul editorului schematic care lucreaza in fundal, doua fisiere de legislatie deschise si un stream de memorie.

5.      Procesele de formare de arhive se desfasoara intr-o institutie a sistemului de operare numita scoala. Arborescenta SCHOOL reuneste intreg workflow-ul proceselor de codificare si este proprietarul resurselor de tipul cozilor de prelucrare, dictionarelor, firelor de arhivare. Prezente in arbore sunt si ramurile arborilor de derivare ai compilatorului de HTML necesar in conversii.

6.      La radacina arborelui sunt nodurile reprezentand nucleul metamorfotic al sistemului de operare si cel reprezentand sistemul extins al citoplasmei celulei morfice. Nodul radacina absolut al sistemului este invizibil in arbore, acesta fiind vizualizat prin intreg UI-ul insusi.

 

Procesul de codificare este in desfasurare si vom trece acum la a discuta unealta de urmarire si metodele sale specifice.

 

4           Tehnici de monitorizare

Ca orice monitorizare sa fie posibila, sistemul trebuie sa fie direct masurabil. Masurarea unui sistem real trebuie sa fie nedistructiva. Atomii spre exemplu nu sunt sisteme direct masurabile fiindca orice act de masurare va fi distructiv. Dispozitia electronilor in orbita nu poate fi observata ci doar dedusa indirect prin mijloace statistice. A interveni direct prin intermediul unei probe atomice ar insemna alterarea distructiva a configuratiei.

Nucleul sistemul de operare ofera nivelelor logice periferice doua mecanisme importante de interceptie: notificarea de Interlocking si notificarea de Checkpoint cu mai multe variatiuni.

4.1         Monitorizare prin interlocking (model nemarkovian)

Sistemul de interlocking al nucleului ANNA K5 este gestionarul conflictelor firelor de executie asupra resurselor sistemului. Pe scurt: firele iau in proprietate temporara resurse pe care le folosesc exclusiv si-apoi apoi le remit sistemului. Orice alt fir doritor de resurse deja folosite este blocat pana la eliberare cazand impreuna cu toate resursele sale in proprietatea actualului proprietar al resursei cerute. Aceste schimbari in proprietatea obiectelor sunt in principiu rapide si inobservabile. Firele si resursele laolalta formeaza varfurile unui graf care in marea majoritate a timpului este profund neconex. Operatiunile de interlocking provoaca legarea nodurilor in arbori. Dimensiunea unui asemenea arbore se numeste context de timp real. Contextul poate creste sa cuprinda mai multe resurse si fire si se reduce prin eliberarea de resurse. Largimea contextului este o dimensiune a interdependentelor fiziologice intr-un sistem, adica o masura a concurentei.

 

Monitorizarea sistemului de interlocking are o mare importanta datorita generalitatii metodei. Programele nu trebuie sa faca nimic special ca sa permita monitorizarea. Nu este nevoie ca starile sa fie predefinite, programele abundand oricum de obiecte numite ce pot fi considerate stari. Vom arata in sectiunile urmatoare cum analiza performantei (evolutiei) sistemelor pleaca de la vizualizarea sistemului de interlocking si poate fi rafinata printr-un sistem alternativ de borne (Checkpoints). Este demersul nostru actual in analiza performantei procesului de encodare EDICT.

 

Graful de interlocking este dificil de surprins. ANNA ii arata formarea si metamorfoza in Navigator in paralel cu Topologia generala. Navigatorul exprima toate cele trei paliere: topologie, morfologie, fiziologie simultan. Arborii de interlocking formati peste graful de interlocking nu pot fi descinsi decat in masura persistentei lor, monitorizarea lor prin browsing fiind deci impracticabila.

 

De remarcat este faptul ca starile de interlocking nu constituie o totalitate, dimpotriva, ele marcheaza capetele starilor reale ale unui program. Programul se gaseste mai rar in starea de interlocking decat in alte stari necunoscute de sistem. Graful de interlocking in sine nu intruneste astfel conditia de totalitate a starilor c//eruta de modelul markovian.

 

Este insa posibila proiectia grafului de interlocking intr-un alt graf complementar cu persistenta sporita unde arcele sa ramana pana la dispatritia din sistem a firelor sau resurselor, si care in unele conditii poate deveni markovian.

 

Inainte de a arata structura planului de proiectie sa vedem si monitorizarea prin borne-checkpoints.

4.2         Monitorizarea prin borne de cod (Checkpoints)

Borna (checkpoint) este un obiect numit pe care un program il creaza si il face cunoscut sistemului de operare pentru a fi ulterior folosit in operatii de monitorizare. In cursul sau, programul cheama o functie de sistem de monitorizare. Programul si sistemul de operare incheie astfel o conventie prin care programul se obliga sa se lase monitorizat in anumite privinte si la anumite puncte iar sistemul se obliga sa nu tulbure programul in restul timpului. Fiind garantul integritatii structurale globale si cel mai interesat in buna desfasurare a lucrurilor, sistemul de operare tine cont de conventie doar cu titlu consultativ, avand toata libertatea sa treaca la alta schema de monitorizare.

Programul, asadar, creaza si inregistreaza borne de stare in sistemul de operare, apoi cheama functia K5CHECKPOINT(borna). Sistemul proiecteaza atat firele programului cat si bornele in planul de analiza fiziologica si uneste prin arce firul de borna si bornele intre ele intr-un lant care reflecta succesiunea trecerilor de la o borna la alta. Sistemul poate astfel spune oricand in ce stare este un fir si un intreg proces.

 

4.3         Monitorizarea prin auto-trace

Functia de auto-trasare este una dintre cele mai avansate tehnici ale sistemului ANNA. Auto-trace inseamna cunoasterea tuturor prototipurilor functiilor sistemului si structurarea stivelor firelor de executie astfel incat in orice moment sa se poate spune ce functii au fost imbricate pentru a se ajunge in starea curenta. Starile unui asemenea sistem sunt toate apelurile de functii mergand mai departe chiar la nivel de instructiune. ANNA K5 foloseste auto-trace pentru a actualiza impresiunile pe stiva ale unor obiecte care au suferit metamorfoza structurala. Discutia sistemului de auto-trace depaseste cadrul lucrarii de fata.

 

4.4         Graful fiziologic

Sistemul de operare este o structura formata din noduri cabluri si procese. Fiecare obiect din sistem este legat la altele pe mai multe nivele de grafuri. Aspectul fiziologic al sistemului este dupa cum am vazut implementat prin graful de interlocking. Acesta este o structura foarte volatila in care arcele si nodurile apar si dispar.

 

Graful fiziologic de proiectie este un derivat prin specializare a unui graf topologic al sistemului de operare unde nodurile si liniile sunt extinse cu cateva atribute noi care sa permita inregistrarea starilor. Atributele acestor obiecte specifice planului fiziologic sunt din multimea {Count, Nest, LTime, Rate, ATime, Probability, STime} discutate in sectiunile urmatoare.

 

Morfismul ∏ de la categoria intreg sistemului de operare la categoria fiziologica este un endomorfism al sistemului de operare si este implementat de metodele Interlocked si Checkpoint ale nucleului discutate anterior.

 


        

 

Graful fiziologic ilustrat surprinde procesul de codificare luat ca studiu de caz, ca proiectie a unor fire si resurse din galaxia sistemului de operare, aflate in zonele accentuate cu verde din partea stanga a diagramei.

 

Graful a fost constituit automat prin metoda de proiectie ΐ de interlocking. Se remarca aparitia in planul de proiectie a pseudo-firelor Teacher, Archiver0 si Archiver1 la centrul grafului cu legaturi catre pseudo-resursele Entry, HTML, ABSTRACT, SCHOOL si Romanian Legal Archive. Resursa X:\Legi\1997-1999\....HTM este volatila, distrusa si recreata sub alt nume in cursul analizei. Arcele grafului sunt automat constituite de metoda ∏. Pe arcele grafului sunt afisate contoarele de trecere. Contoarele de trecere ale firelor (hexagon) si ale resurselor (balon) reprezinta numarul de vizite initiate de fir si respectiv primite de resursa. Ingrosat sunt arcele starii curente. Starea curenta a sistemului este multimea arcelor (fir,resursa) intre toate firele sistemului si sarile lor curente. Constatam ca un graf caruia ii apar si dispar stari si arce nu poate fi marcovian.

 

Pentru a cunoaste starea unui sistem este deci suficient sa stim pozitia acelor suveicii de proiectie.


 

 

5           Monitorul fiziologic

Componenta de diagnostic fiziologic este cea mai recenta dezvoltare in sistemului nostru de operare. Este un dispozitiv complex in a carui constructie au intrat cele mai inalte si mai radicale principii ale sistemului de operare ANNA K5:

1.      principiul metamorfozei structurale;

2.      principiul instrumentatiei virtuale;

3.      principiul firelor de executie metamorfotice;

4.      principiul subclasarii tipurilor nucleare;

5.      principiul interlockingului fir-resursa;

6.      principiul reprezentarii obiectelor (unui sistem prin prepusi in alt sistem).

Monitorul de performanta este deasemenea si o utilizare speciala a editorului schematic al sistemului de operare demonstrand utilitatea nucleului in a construi rapoarte. Un rezultat important este si acela ca obiectul principal numit Physiology are constructia unui lant ADN.

 

In figura urmatoare sistemul de operare este surprins in mijlocul unei operatii de compilare a unui dictionar legislativ potrivit cu studiul de caz ales in sectiunea  REF _Ref264436817 \r \h 3.

Sunt trei fire de executie, unul numit Teacher_0000 de incarcare a textului si doua fire de arhivare Archiver_0000 si Archiver_0001 corespunzand celor doua dictionare juridice unul cu si celalalt fara diacritice. Acest proces este de tip producator consumator cu coada de decuplare si trece prin 8 stari posibile: Produce-inceputul algoritmului de incarcare, Consume - inceputul algoritmului de arhivare, Filter - o stare a firului de incarcare asupra careia acesta revine, HtmlCompile este compilatorul de HTML folosit de incarcator in procesul de filtrare si extractie de text, Memory - este stare comuna in care firele cer sau returneaza memorie de sistem, Archive este starea in care arhivatorii bobineaza text pe dictionar, Queue este starea comuna in care firul de incarcare producator adauga job-uri filtrate in coada de asteptare si in care firul de asteptare extrage jobul din coada de asteptare, BuildRefs este o stare a arhivatorilor in care acestia actualizeaza o harta de crosreferinte ale fiecarui dictionar cu fiecare text adaugat.

In figura sunt marcate cu 1:9 componentele monitorului fiziologic descrise in cele ce urmeaza.

5.1         Lista resurselor

Lista clientilor si a resurselor disponibile monitorului fiziologic se incarca pe masura ce clientii acceseaza resurse si cheama monitorul prin conventiile de Interlocking sau Checkpoint discutate in sectiunea  REF _Ref264436853 \r \h 4.2. Nodurile din aceste liste sunt prepusi de al doilea grad ai obiectelor reale din sistem si urmeaza acestora in ce priveste durata de viata. Listle de resurse si clienti au rol de limitare prin selectie a efortului de monitorizare.

5.2         Lista clientilor

Folosim termenii de client si fir sau resursa si stare interschimbabil. Un fir este reprezentantul in sistem al unui client. Deasemenea, orice acces la o resursa poate fi considerata stare.

5.3         Lista algoritmilor

In lista de algoritmi se selecteaza/ deselecteaza prin dublu-click algoritmii ce urmeaza sa fie monitorizati. Iata solutia problemei enuntate la SSS privind stabilitatea structurilor monitorizate.

1.      Interlock este algoritmul care foloseste obiectele participante in interlocking fir-resursa pe post de stari. Acest algoritm generic a fost discutat in sectiunea  REF _Ref264436976 \r \h 4.1.

2.      Autotrace foloseste reflexia sistemului pentru definirea starilor. A se vedea sectiunea  REF _Ref264437002 \r \h 4.3.

3.      Algoritmul HostOs defineste starile FileOpen, FileAccess, CloseHandle, si Sleep pentru a da o indicatie fiziologica legata de iesirile pe care un proces le face in sistemul de operare gazda sub care ANNA K5 ruleaza. Toate apelurile de sistem sunt trecute printr-o palnie de monitorizare si ca dezvoltatori suntem permanent interesati de minimizarea dependentelor pe care nivelele superioare de logica le formeaza cu sistemul gazda.

4.      Algoritmul School este cel al studiului nostru de caz descris in sectiunea  REF _Ref264437027 \r \h 3 si defineste urmatoarele stari: {Produce, Filter, HtmlCompile, Memory, Queue, Consume, Queue, Memory, Filter, BuildRefs, Archive, Verify}. Firele de executie ale algorimului sunt de clasa "Teacher" sau "Archiver". Invatatorii scolii sunt firele de ridicare/compilare de documente si trec prin metoda Produce, iar arhivatorii au rolul de a codifica textele pe mosorul dictionarului - memoria comuna a intregii scoli, trecand prin metoda Archive. Cele doua functii au urmatorul pseudocod.

CAT_SCHOOL::Produce (...)

{

  ... initializarea tranzactiei ...

  K5CHECKPOINT(School,Produce,2)

  ... crearea unui nod in folderul Entry al scolii

  K5CHECKPOINT(School,Filter,2)

  ... prima filtrare a textului ...

  K5CHECKPOINT(School,HtmlCompile,2)

  ... compilare HTML cu producerea DOM-ului ...

  K5CHECKPOINT(School,Filter,2)

  ... "toaletarea" DOM-ului ...

  ... colectarea textului de pe DOM ...

  ... a doua filtrare a textului ...

  K5CHECKPOINT(School,Memory,2)

  ... crearea nodului final si distrugerea DOM-ului

  K5CHECKPOINT(School,Filter,2)

  ... a treia filtrare si normalizare a textului ...

  K5CHECKPOINT(School,Queue,2)

  ... tentativa blocanta de a depune nodul in QUEUE

  ... revenire la sistem si bucla catre intrare...

}

CAT_SCHOOL::Consume (...)

{

  K5CHECKPOINT(School,Consume,2)

  ... initializarea tranzactiei ...

  K5CHECKPOINT(School,Queue,2)

  ... tentativa blocanta de a lua din QUEUE

  K5CHECKPOINT(School,Memory,2)

  ... copierea textului si distrugerea nodului

  K5CHECKPOINT(School,Filter,2)

  ... filtrul de diacritice ...

  K5CHECKPOINT(School,BuildRefs,2)

  ... calculul legaturilor la alte documente.

  K5CHECKPOINT(School,Archive,2)

  ... arhivarea textului in dictionar ...

  K5CHECKPOINT(School,Verify,2)

  ... verificarea  integritatii codificarii

  ... revenire la inceput...

}

5.4         Graful fiziologic

 


Conceptul de endomorfism de proiectie a sistemului de operare a fost prezentata in sectiunea  REF _Ref264437063 \r \h 4. Reamintim ca graful fiziologic este G:(N,A) unde N este reuniunea F si S, unde F este multimea firelor (clientilor), S este multimea starilor (resurselor), iar A este reuniunea L si T unde L este multimea legaturilor client-stare (injectie) iar T este multimea arcelor de tranzitie intre stari.

 

Nodurile si arcele grafului sunt atributate cu urmatoarele campuri:

1.      count - contorul tuturor trecerilor (vizibil pe captura de mai sus)

2.      nest - indicator de recursiune prin stare. Schemele de monitorizare prin Interlocking ( REF _Ref264437071 \r \h 4.1) si AutoTrace ( REF _Ref264437078 \r \h 4.3) sunt recursive si deci ne-markoviene in sensul  ca un client trece recursiv prin aceeasi stare fara a fi iesit prealabil din ea - cazul general al algoritmilor.

3.      ltime - ultimul (last) interval de timp cheltuit de un fir in starea data sau la traversarea unui arc.

4.      rate - rata de trecere per intervalul de timp global configurat (vezi  REF _Ref264437143 \r \h 2).

5.      atime - timpul mediu de stationare pentru stari sau de trecere pentru arce.

6.      probability - probabilitatea de a fi in strea data sau de a trece pe arcul dat.

7.      stime - timpul acumulat in starea data

Cele trei arce (ace) apartinand multimii L reprezentate ingrosat (Teacher,Memory), (Archiver0,Queue) si (Archiver1,Queue) reprezinta multi-starea curenta a sistemului. Vezi  REF _Ref264437227 \r \h 4.

Drumul inclus in T al firelor de clasa Archiver este {Consume, Queue, Memory, Filter, BuildRefs, Archive} iar cel al firului de clasa Teacher este {Produce, Filter, HtmlCompile, Filter, Memory, Filter, Queue}. Se remarca faptul ca cele doua clase de client trec prin starile comune {Queue, Filter, Memory} si peste arcele comune corespunzatoare, lucru congruent cu codul procesului descris in pseudocod in sectiunea  REF _Ref264437245 \r \h 4.

5.5         Matricea grafului fiziologic


Se cunoaste echivalenta matrice-graf. In unele implementari grafurile sunt pastrate sub forma de matrice in altele precum a noastra graful este o structura de date complexa iar matricea se obtine prin traversarea grafului. Graful in sensul sistemului nostru de operare sun structuri multi-dimensionale mult mai complexe decat G:(V,A) din lumea academica. Grila grafului este un control eficient in a reuni detaliile numerice ale structurii.

Controlul arata produsul cartezian NxN al nodurilor grafului. Se disting 3 cadrane:

1.      zona diagonala a clientilor. Acestia nu au nici o legatura directa, sunt legati doar prin starile lor comune / resursele comune pe care le folosesc. Contoarele afisate in zona 1 privesc clientii si sunt in principiu valori totalizatoare.

2.      Zona legaturilor L ale relatiei intre clienti si resursele utilizate.

3.      Zona tranzitiilor intre stari dupa cum au fost deduse din comportamentul clientilor.

 

Coltul (4) de tabel serveste drept buton de schimbare a atributului vizualizat in grila in multimea {Count, Nest, LTime, Rate, ATime, Probability, STime, CNLRAP} discutate la SSS, unde CNLRAP este un mod in care grila afisaza condensat toate atributele grafului. Butonul acesta decide simultan atributul afisat pretutindeni in monitor: in schematic, in grila si in Bargraph.

 

Se remarca afisarea cu accent a 4 celule din grila cu urmatoarea semnificatie: clientul curent, arcul traversat, resursa catre care se duce clientul, tranzitia pe care clientul o face de la resursa precedenta. Acesta este un alt stil de vizualizor fiziologic mult mai rapid decat schematica grafului.

 

5.6         Graficul functiei monitorizate

Controlul de tip Plot sau Chart are doua moduri de functionare:

1.      Modul bara, in care controlul arata comparatia intre valorile clientilor per resursa. In ipostaza data, barele indica contorul de solicitare. Firele Archiver0 si Archiver1 sunt idempotente, si cum este si normal, au contoare de trecere pe la resurse aproximativ egale. Firul Teacher umple barele HtmlCompile, Filter si Produce, acestea fiindu-i proprii. Starile Queue si Memory sunt impartite inegal de cele trei fire dupa cum era de asteptat din modelul prezentat la SSS. Starea Filter este si ea comuna celor trei fire, dupa cum am aratat la SSS si SSS, insa procesul de codificare nu a intalnit pana la momentul capturii nici un document cu diacritice pe care vreun arhivator sa-l filtreze. Controlul arata stiva de valori pentru atributul curent al matricii grafului.

2.      Modul plot este cel in care controlul arata istoria ratei de servire pentru resursa selectata sau istoria solicitarii de servire pentru clientul selectat. Selectia se face prin click pe diagonala matricii grafului. O chestiune esentiala aici este ca rata nu poate fi calculata altfel decat pastrand o istorie a trecerilor. Unul dintre cele mai sofisticate mecanisme ale monitorului fiziologic este cel de bobinaj al istoriei evenimentelor dupa principii echivalente cu cel al arhivarii textelor pe dictionar, dar pe suportul finit si deci cu pierdere al unui bufer circular.

5.7         Bara de stare

Acesta este un control important pentru starea sistemului si afisaza o serie de indicatori de echilibru.

 

 

 

1.      Logs (x:y) este contorul trecerilor prin monitor. Nu toate cererile de monitorizare pot fi satisfacute. Cererile re-entrante de interlocking ale sistemului de desen grafic pe care monitorul insusi le emite vor fi ignorate. Valoarea x curent la 0 este nivelul de reentranta in monitor, iar y este numarul total de intrari in monitor. Panoul se inroseste in caz de dezechilibru nejustificat prin numarul de fire de executie.

2.      Frames (x:y) este un indicator de performanta a desenului grafic cu x-numarul total de randari ale grafului si y-rata de cadre desenate pe secunda, actualmente la 0 fiindca rulam in scop demonstrativ in mod pas-cu-pas.

3.      OS ClosureMonitor - este de importanta cruciala si arata echilibrul contoarelor de timp real ale nucleului. Sunt afisate diferenta intre Lock si Unlock asupra semafoarelor, intre FileOpen/FileClose, intre thread suspend si thread resume, etc, valori ale caror dezechilibru ar "comemora" un eveniment catastrofic in inima sistemului.

4.      Interlocks (x:y) este monitorul de cereri de interlocking asupra monitorului. Dupa cum am aratat in sectiunea SSS Interlockingul este nemarkovian prin faptul ca exista o multime de alte stari inafara celor monitorizate si ca strile sunt reentrante. Cererile de interlocking sunt emise doar de dispeceratul sistemului de operare ANNA K5 si vin pe perechi cu on si off adica notificari de intrare in stare si de iesire din stare. Campul x este nivelul de reentranta, y este totalizatorul cererilor de intrare. Inrosirea panoului indica un dezechilibru grav fie in dispecerat, fie in monitorul insusi.

5.      CheckPoints (x:y) este monitorul bornelor definite de algoritmii din sistem. A se vedea SSS pentru o discutie privind monitorizarea algoritmilor si SSS pentru un exemplu. Algoritmii sunt procese marcoviene in care starile sunt considerate a fi complete. Valoarea x este mereu 0 pentru ca utilizarea obisnuita a bornelor nu permite reentranta. Din nou, y este totalul cererilor.

6.      CallTraces (x:y) este monitorul mesajelor de auto-trace, sistem discutat in SSS.

7.      History buffer este indicatorul de umplere a arhivei istorice de evenimente pe care monitorul fiziologic o gestioneaza. Memoria istorica este in principiu pre-stabilita la 128KB si in experimentele facute pentru redactarea prezentei lucrari a fost o valoare suficienta pentru a retine cateva minute de rulare. Timpul afisat este diferenta de timp intre momentul prezent si prima inregistrare istorica. Arhiva istorica este necesara in calcularea ratelor si mediilor de timp.

5.8         Bara de unelte

In ordinea aparitiei butoanele au urmatoarea semnificatie: Play, Step, Clear, Refresh, Chart enable, Graph rotation, Chart Safe Mode, GraphMode. Se remarca in grup butoanele Play si Step care implementeaza capabilitatea de a rula intreg sistemul de operare in mod pas-cu-pas. Este de notat faptul ca "pasul" este acum o notiune foarte bine definita si structurata pe mai multe niveluri algoritmice.

6           Tranzitii pas cu pas prin monitor

Pentru demonstrarea aptitudinilor monitorului de performanta vom executa in cele ce urmeaza trei tranzitii in algoritmul de codificare EDICT5 in studiul de caz descris in sctiunea SSS, folosind modul pas-cu-pas.

6.1         Starea #1

Sistemul ajunge in multi-starea {(Teacher,Queue),(Archiver0,Queue),(Archiver1,Queue)} ca urmare a unei tranzitii facute de clientul Teacher din starea Filter. Informatia este reflectata in grila.

Semnificatia valorilor in grila si pe graf este Count, Nest, LastTime, Rate, AverageTime, Probability, toate discutate in SSS. Plotul din dreapta-jos discutat la (6) in sectiunea SSS arata istoria ratei de solicitare instantanee pentru resursa Queue si se invarte in jurul cifrei de 80 cu o semificatie mai putin intuitiva de arie pe un interval de timp de 1 minut. Pe graf sunt ultimii timpi de servire si de trecere T, rata R de servire, timpul mediu de servire, probabilitatile de trecere dintr-o stare intr-alta.

 

In aceasta stare s-a ajuns datorita competitiei tuturor firelor asupra cozii de lucrari care este gestionata in sistem producator-consumator. Din graful starilor se desprinde ca sistemul monitorizat va putea trece din Queue doar intr-una din starile Produce sau Memory.

 

6.2         Starea #2

In starea #2 se ajunge prin tranzitia (Archiver1,Queue,Memory) chestiune necunoscuta la pasul anterior dar predictibila avand in vedere ca probabilitatea de trecere a oricarui client din Queue in Produce are valoarea curenta de 4% iar cea de trecere din Queue in Memory era de 38 in strea anterioara si 35 acum odata ce drumul a fost parcurs.

Adancimea arhivei istorice a ajuns acum la 4.6 minute din care calculul ratei foloseste doar ultimul minut. Se observa in Plot ca rata instantanee la nivelul straii Queue a inceput sa distorsioneze din pricina rularii pas-cu-pas, astfel ca ratele vor fi inexacte pe masura ce tinem sistemul stopat.

 

Se citeste din grila ca in aceasta stare s-a ajuns in urma tranzitiei facute de Archiver1 din Queue catre Memory. Sistemul se poate indrepta cu firul curent de arhivare catre Filter sau BuildRefs, catre Memory - cu celalalt fir de arhivare, sau catre Produce sau Memory prin firul Teacher. Stim din algoritmul prezentat la SSS ca Arhivatorul nu sare din Memory in BuildRefs cata vreme abia vine din Queue, dar cunoasterea de acest gen implica memorarea starilor ceea ce este inafara modelului nostru (markovian).  Probabilitatea cea mai ridicata, dupa cum arata indicatorii de pe graf, este in continuare sa se execute o tranzitie din Queue in Memory.


 

 

6.3         Starea #3

Ajungem in starea #3 prin tranzitia (Teacher, Queue, Produce) care desminte predictia anterioara ca se va trece din Queue in Memory.

 

Teacher este obligat sa evolueze spre Filter, Archiver0 este obligat sa iasa din Queue si sa mearga spre Memory, iar Archiver1 poate "opta" intre Filter si BuildRefs. Nu se stie insa care dintre cele trei fire va fi dispecerizat la pasul urmator, iar in grila nu putem citi probabilitatile de rulare.


 

 

7           Analiza predictiva

Rezultatul final al analizei fiziologice si "ultima ratio" a modulului de monitorizare este calcularea vectorului de predictie. Trecand modul de vizualizare de la "faptic"la "predictiv" si ruland pas-cu-pas patru cadre, obtinem urmatoarele diagrame de stare, in care ne intereseaza incotro ne indreptam.

Venind cu Archiver1 din Memory in BuildRefs, pe drum spre Archive, Memory sau Filter.

Venind cu Teacher0 din Produce in Filter, pe drum spre Memory, Archive sau HtmlCompiler.

Cu Archiver1 din BuildRefs in Archive, pe drum spre Memory, HtmlCompile sau Consume

Cu Teacher din Filter in HtmlCompile, pe drum spre Memory, Consume sau Filter

Sitemul de monitorizare afisaza vectorul de predictie intre doua puncte speciale F (From) si T (To) unde F este legat cu arce directionale de la satrile  curente ale firelor, iar T este legat cu arce spre starile viitoare ale acestora. Nodurile F si T sunt gestionate grafic astfel incat sa "tinda"spre nodurile de care acestea sunt legate, efectul vizual fiind acela de dans in interiorul cercului orientat de la contextul curent catre contextul viitor.

 

Constituirea si orientarea in spatiu a vectorului de predictie nu are nici o legatura cu calculul probabilistic ci este un rezultat al metodei de poiectie descris in SSS. Procesul luat in studiu de caz este insa unul markovian, astfel ca putem merge un pas mai departe sa calculam probabilitatile de intrare in F si cele de iesire din T care ar indica cel mai probabil drum pe care sistemul il va face intre o stare curenta si una imediat viitoare. Coeficientii de probabilitate sunt actualizati pe graf la fiecare pas iar vectorul s-ar putea in viitor afisa ca un Z intre doar doua resurse.

 

8           Viitorul sistemului

Este posibil si necesar sa implementam sistemul de "replay" al evenimentelor istorice. Metoda va fi sa se ruleze monitorul in modul cel mai putin cronofag, iar grafica toata sa fie utilizata post-factum.

 

O extensie posibila si necesara cu un viitor in sine este analiza de comportament cu auto-clasificare. Se ruleaza un program qvasi-necunoscut in mod Interlocking si se remarca o anume utilizare a resurselor. Se compara aceste modele de utilizare si se aseaza clientii in clase de echivalenta. Se reduce corespunzator graful de proiectie, acum nemaifiind nevoie sa indicam toate legaturile din multimea L.

 

Hit Counter Created on 05/27/2009 06:33:56 AM, modified on 05/27/2009 06:33:56 AM

Home

Home | Feedback | Contents | Search

Send mail to webmaster@ProximaCentauri.ro with questions or comments about this web site.
All principles and artwork exposed on this site or by our software products is our intellectual property. 
Copyright © 2006 Proxima Centauri Romania SRL. Last modified: 05/27/09