Jobhandling in a network of distributed processors

(1)

Jobhandling in a network of distributed processors

Citation for published version (APA):

vd Eijnden, P. M. C. M., Dortmans, H. M. J. M., Kemper, J. P., & Stevens, M. P. J. (1982). Jobhandling in a network of distributed processors. (EUT report. E, Fac. of Electrical Engineering; Vol. 82-E-131). Technische Hogeschool Eindhoven.

Document status and date: Published: 01/01/1982 Document Version:

Publisher’s PDF, also known as Version of Record (includes final page, issue and volume numbers) Please check the document version of this publication:

• A submitted manuscript is the version of the article upon submission and before peer-review. There can be important differences between the submitted version and the official published version of record. People interested in the research are advised to contact the author for the final version of the publication, or visit the DOI to the publisher's website.

• The final author version and the galley proof are versions of the publication after peer review.

• The final published version features the final layout of the paper including the volume, issue and page numbers.

Link to publication

General rights

Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.

• Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain

• You may freely distribute the URL identifying the publication in the public portal.

If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, please follow below link for the End User Agreement:

www.tue.nl/taverne

Take down policy

If you believe that this document breaches copyright please contact us at: openaccess@tue.nl

providing details and we will investigate your claim.

(2)

Electrical Engineering

Jobhandling in a network of distributed processors. By

P.M.C.M. van den Eijnden H.M.J.M. Dortmans J.P. Kemper M.P.J. Stevens

EUT Report 82-E-131 ISBN 90-6144-131-5 ISSN 0167-9708 October 1982

(3)

EINDHOVEN UNIVERSITY OF TECHNOLOGY

Department of Electrical Engineering

Eindhoven The Netherlands

JOBHANDLING IN A NETWORK

OF DISTRIBUTED PROCESSORS

By

P.M.C.M. van den Eijnden H.M.J.M. Dortmans

J.P. Kemper M.P.J. Stevens

EUT Report 82-E-131

ISBN 90-6144-131-5

ISSN 0167-9708

Eindhoven October 1982

(4)

Jobhandling in a network of distributed processors / by

P.M.C.M. van den Eijnden ••• let al. , publ. of the] Department of electrical engineering, Eindhoven University of technology. Eindhoven : University of technology. Fig.

-(Eindhoven University of technology research reports, 82-E-131) Met lit. opg., reg.

ISBN 90-6144-131-5 ISSN 0167-9708

SISO 365.1 UDC 681.324 UGI 650 Trefw.: computernetwerken.

(5)

1. Introduction 2. Jobs and tasks

2.1 Syntactical rules 2.2 Two examples

2.3 Some remarks 3. Operators

3.1 Consequences of task distribution 3.2 New syntactical rules

3.3 Definition of operators 1 2 3 6 6 7 7 7 9

4. Structure of the communication network 13

4.1 Transport of job-, taskdescriptions and datapointers 13

4.2 Transport of data 14

5. The structure of the FIFU's and CIU's 5.1 Blockdisgram of a FIFU 5.2 Blockdiagram of a CIU 6. Conclusion 7. References 8. Figures 16 17 17 18 19 20

(6)

Abstract

This report describes the development of a completely distributed modular computersystem. The system is composed of processing units, which can perform specified tasks independently. Adding intelligence to peripheral devices, by means of microprocessors and buffer memories, provides for independent functioning of these peripherals. An intensive transport between the devices is required. The devices are therefore connected by means of a

non-blocking cnmmunication network, to gain full profit of their intelligence.

The intelligent devices are also connected to a central facility containing the Operating System. The Operating SY8tem is distributed over a number of cooperating modules. Esch Operating System module supports one intelligent device. The Operating System modules control the load among the devices and see to the correct proceSSing of jobs, presented by a user. Each is equipped with its own buffer

capacities and processing power. The network that interconnects the

Operating System modules has the same structure as that linking the devices. The Operating Sys tem mod ules are relativel y simple, because each intelligent device has the same characteristics, seen from the Operating System point of view.

Keywords: Distribution of functions Operating System

Job Control Matrix

Broadcasting Computer networks Computer arc hitec ture

Eijnden, P.M.C.M. van den, H.M.J.M. Dortmans, J.P. Kemper and M.P.J. Stevens JOBHANDLING IN A NETWORK OF DISTRIBUTED PROCESSORS.

Department of Electrical Engineering, Eindhoven UniverSity of Technology, 1982.

EUT Report 82-E-131 Address of the authors:

Digital Systems Group,

Department of Electrical Engineering,

Eindhoven University of Technology, P.O. Box 513,

5600 MB EINDHOVEN, The Netherlands

(7)

1. Introduction

In the past few years the prices and sizes of microprocessors and memories have decreased continuously. Now, in a cheap way, 1/0-devices can get their own intelligence. Such intelligent 1/0-devices are able of performing tasks completely on their OWn. This means that they are independent.

During a research project at the University of Technology of Eindhoven (Digital Systems Group) a completely distributed modular computersystem has been developed with such intelligent devices. Figure 1 shows the global structure, which formed the starting point for the development of our distributed system •

Devices with intelligence can be made universal. This means that, seen from the network, each device has the ssme characteristics. They can be addressed and controlled in the same way. The specific control signals for the devices are now generated by the unit itself. This considerably simplifies the Operating System because only one driver-routine is required to communicate with each intelligent device. The device dependent characteristics are moved from the

Operating System to the intelligent device.

Furthermore we have stated a few specific requirements for our system. The system may be composed of a large number of devices spread over a whole building or floor. The different devices should be connected by serial lines, to reduce the number of lines required. Between the devices data mUSt be transferred at a rate of several IIbits/sec. This gusrantees a high throughput. Malfunction of the hardware of one part of the system should not "destroy" the whole system. Different parts of the system therefore mUSt be galvanically separated.

From this bac kground we will finally want to find the answers to the following three questions.

1. What does sn intelligent device look like? 2. What does the intelligent network look like? 3. How do the different units work together?

It may be clesr that these questions can not be snswered immediately. Before the structure of the different units -in-telligent devices and network- of the system can be determined, it must be clear which functions each part of the system has to perform. However, only when the functions which sre really required in the system are known, functions can be assigned to the different units of the system. The total of these functions may be determined by traCing how the system should realise its tasks. Tasks are process orders, given by a user, to produce the desired results. For this purpose we will first examine what kind of orders a user really gives to the system and what their specific characteristics are. This gives us a direct indication to what processes are required for the completion of these orders. In this analysis we will use the concepts "job" and "tssk".

(8)

Thus a language is defined, based upon the global structure shown in figure 1. System functions are deduced from this language. The functions are assigned to different parts of the system. Finally the structure of the different system paTts is determined from these functions.

2. Jobs and tasks

A job forms a definition of an order for the system and generally is compo sed of control information and dats. Such a job is presented to the system by a user. It must be considered as a complete amount of work by this system. In a job a number of smaller orders, called tasks, may be distinguished. These tasks also form a complete amount of work, not for the system as a whole, but for sn intelligent device. Such an intelligent device can completely independent process a task from a job. Jobs and tasks may thus be defined as follows:

job:

the total of orders and data that a user presents as a whole to the system. It should be seen as a complete amount of work by the system.

task:

an order together with the data belonging to this order. A task is s complete smount of work for one intelligent device in the system.

An intelligent device can process a task completely on its own. Several tas ks from a job can be proces sed at the same time by distributing them among the intelligent devices. However this parallel processing is possible only for those tasks that are independent of each other. Other tasks, which are dependent of each other and must be proces sed in a fixed seq uence, also will be present. This, for example, is the case with tasks th'llt require data that ia

produced by execution of other tasks.

The system now has to recognize dependent and independent tasks in a job. This means that Some rules are required to define the way in which jobs and tasks must be constructed, so that an unambiguous interpretation becomes possible. These rules should be defined in such a way, that the dependent or independent nature of the tasks is given in the control information of the job. It must be possible to determine from the contol information alone, if tasks should be processed sequential or may be processed in parallel. This has the advantage that the control information and data of a job may be handled independently. For execution, tasks can be given to the d Hferen t in telligent devices, wi thout the data being immed iately present with the task. Only at the time the device wants to execute the task, the data should be available. We say that in the device a task must be "executable", before i t can be processed.

(9)

We now may define a number of requirements which these rules must meet. These requirements are:

1. Jobs and tasks must be constructed in a way that data and control information can be separated easily.

2. Parallel or sequential behaviour of tasks must be deduced easily from the control information.

3. The rules must be as simple as possible.

The first two requirements follow directly from the given analysis. The last requirement stems from the fact that a user wants to formulate jobs and tasks as simple as possible. Moreover, simple rules provide for an easy tool to define the system lsy-out and to analyse the operation of the system. In the next section the rules according to which jobs and tasks must be constructed, are defined. The formulation of these definitions is based upon the system organisation of figure I, because that is our main starting point. 2.1 Syntactical rules

In this paragraph the syntac.tical rules of our language are

listed. The rules are presented in the form of "Railroad Diagrams".

<job> <jobdescription> - - ; - -

[1

< u s e r d a t a f : J

1--1

w=J

L

<compound task> <Singular task> ---<jobname> , - - - , - : - <taskname> ---.:;:>~

(10)

- - - <j 0 b name> - , - - - . . : - <taa kname>

---=>::;.

:>

-,-<taskdescriPtion singular task>

J

~<taskdescriPtion

compound task> <taskdescription singular task>

---<taskname> - -(T<datapo~nterl>=r>

---<taskname>-- (T<datapo~nter2> J > <datafile> T<userdataflle> ~ <taskdataflle> <userdataflle> ---<datapointer 1 > - - <data>

(11)

---f

L

=:J

"datapoin ter2 > "jobname>

----<upper case letter>---~

---<upper case l e t t e r > - - - ,

----<lower case letter>---~

<datapoin ter 2

>

---r-

<datapointer 1

>

L

A

B C

z

<lower case letter>

a b c

(12)

2.2 Two examples

In this section the previously defined rules are clsrified by means of two examples. The first example deals with a job A, which has been loaded by a user. The structure of this job being as follows:

A G(x); [Dataflle xl

This job has only one task (G). The task therefore is a singular task. The data of this job consists of one dataflle (x), which was loaded by the user. This is a user datafile.

The jobdescription of this job is given by A : G(x). In this description G(x) is the taskdescription of the singular task G.

Our second example deals with a more complex job B. The structure of this job is as follows:

B : R(G(x),L(y»,I(j) ; [Datafile x, Datafile jl

In this job four tasks can be distinguished, namely R, G, L and I. The tasks G, L and I belong to the category of singular tasks. They may be executed in parallel, because they don't have to wait for other tasks to be completed. H, however, must wait until G and L have been completed. H is thus a compound task. The data of this job consists of five files. The datafiles x and j are loaded by the user and are thus user datafiles. The datafiles which are resident after execution of the tasks G and L and have to be processed further by D, belong to the category of task datafiles.

Datafile y which has to be processed by L forms a special case. Because it is not loaded by the user, it must already be resident in the system or must be generated by an external process. If the file is already resident in the system i t may have been generated by a task belonging to an earlier job, and thus may be a task datsfile. However, the file msy also be loaded by the user with. another job, in which case the file is a userdatafile.

The jobdescription of this job is thus given by B : D(G (x),L(y»,I(j). G(x), L(y) and I(j) all are taskdescriptions of Singular tasks. H (G (x) ,L(y» is the taskdescr!ption of the compound task H.

2.3 Some remarks

For simplicity tasks and datafiles in this description are denoted with upper-case and lower-case letters. By this simplified description the language is more abstract. This makes it easier to develop a system lay-out and provides for a better tool to analyse the operation of the system.

I t will no t astonish the reader that names like RUN and CUM PILE will be used in a real system, rather thsn upper case letters. Also filenames such as FILE 1 0 N DISK will be used in stead of lower case letter s.

(13)

3. 0 perators

Jobs and tasks, from which a job is composed, have been described in the previous chapter. A task is a complete amount of work for an intelligent device in the system. In the system a job therefore will be split in separate tasks. These tasks will be distributed among different intelligent devices. The processes which are neces sary to get through job sand tas ks will be denoted as

operators. However, before we can analyse the function of these

operstors, we first have to consider the consequences of splitting a job in separate tasks.

3.1 C onseguences of task distribution

Different parts of a job will be located at different places in the system, because tasks are distributed among devices. This conclusion not only holds for taaks, but is also spplicsble to the datafiles of a job. Tasks and datafiles will thus lead their own lives in the system. From the jobdescription it was immediately clear from which tasks a compound task depends. This dependency must still be recognizable after a job has been split in its composing tasks. A job is completed after sl1 its tasks have been completed. Tasks that have split off therefore must signal to the job when they have been completed.

This analysis shows that some new rules are required. These rules must describe tssks and dstafiles that have been split off from a job. They must meet the following requirements.

1. From the description for a waiting task, i t must be clear what tasks it is waiting for.

2. Tasks that generate data which are to be used by other tasks, must have references to these tasks.

3. From the description of a task it must be clear from which job the task originates.

4. A dataflle must contain a number, from which the system may determine, how many times the file is required ,before it msy be removed from the sys tem.

In the next section the new rules sre defined. Tssks and datafiles, resident in the system as independent parts, must be constructed according to these rules.

3.2 New syntactical rules

In this paragraph the syntactical rules which are required together with those defined in section 3.1, are listed. Again these rules are presented in the form of "Railroad Diagrams".

(14)

-<jobname> ~---~:- <taskname> - (l<dataf,ile>T)

'l<task,name>

~

-<jobname>

~---~:-<taskname>-

(1

<datapo, interl>T)--l

,Ck,name>

-<taskdescription suspended task>

- <jobname> ... - - - . - : -<taskname>- (l<datap,ointer3> T)--l

'1

<task,name> -<extended datafile> -<datafile>-- (--<number> - - )

---l

<datapointer3> 1<data p ointerl> ] <datapoin ter4 > <datapoin ter4 > -<datapointerl> - - *---~ <number>

o

1 2 3 n

(15)

3.3 Definition of operators

Operators are the processes that are necessary to complete jobs and tasks. The first operator (Fork) that is required, separates control information and data in s job. The second operator (Psrse) splits the control information in different taskdescriptions. Descriptions of executable tasks are joined with the data they must process, by a third operator, denoted as Join. The operator called

Execute provides for the real execution of a task. The last operator

(Substitute) will process tasks that are wsiting for others, until these have been completed. We will now discuss these different operators in more detail.

Fork:

This operator works on a job and separates dataflles and the jobdescription. In the next figure this is illustrated by means of a job A which has been loaded by the user and is now worked upon by Fork. (Datafiles are abbreviated as DF).

A:F(G (x),y,R(z,J(x),L(y»,z); [DFx,DFy,DFz)

1

Fork

~""

A:F (G (x),y, R (z,J(x) ,L(y»,z) DFx(2) DFy(2) DFz(2)

We see that as a result of this operation the jobdescription and extended dataflles are generated. The number in brackets indicates how many tasks will need the datafile. Thus when e.g. DFx is used twice i t may be removed from the system.

Parse:

This operator splits the jobdescription in descriptions of suspended- and executable tasks. The jobdescription of the previous example will be split as is illustrated in the next figure.

A: F (G (x),y,R (z ,J(x) ,L(y»,z)

1

Parse

/ \

A,F:G(x) A,R:J(x) A,R:L(y)

descriptions of exec utable tasks

A,F:H(z,j*,I*) A:F(g*,y,h*,z) descriptions of

(16)

Join:

This operator links a description of an executable task and the datafiles, which are mentioned in this description. The result of this action will be an executable task. In our example this operation will be exec uted three times.

ExeC! ute: DFx(2} A,F:G(x}

~

/

Join

/

~

DFx (l) A, F: G (D Fx) D Fx (l ) A,H:J(x}

~

/

Join

/

~

DFx(O} A,H:J(DFx} D Fy (2) A,H:L(y}

~

/

Join

/

~

DFy (1) A,H:L(DFy}

I t is evident that it does not matter whether DFx is first linked to G(x} or J(x}.

After a datafile and a description of an executable task are jOined, the number mentioned in brackets after the datafile will be decreased by 1. If the result becomes 0, the datafile will be removed.

Exec ution of a task is provided for by this operator. If

the task is to output data to the user (e.g. printer) both task and data are eliminated from the system sfter completion. If the task generates data that must be used by another task from the same job, a datapointer will also be generated, which must be substituted in descriptions of suspended tasks. The taak itself will be removed from

(17)

Sub stltute:

the system sfter completion. I f the tssk is to save data on a disk, the task will be removed from the system after completion. No datapointer will be generated in this case. In our example we get:

A,F:G(DFx)

!

Execute

/

\

DFg(l) g A,H:J(DFx)

!

Execute

/

\

DFj(l) j A,H:L(DFy)

!

Execute

/

\

DF1(1) 1

From the presence of tasknames before the If;", Execute can recognise, i f a datapointer has. to be generated after execution of the task. If no tasknames are mentioned no datapointer is needed. Furthermore i f tasknames are present, their number indicates how many times the generated file is needed.

This operator substitutes descriptions of sus pended description of a suspended example we now see:

generated datapointers in taaks. The result is a or executable task. In our

(18)

j A,F:H(z,j*,l*)

\

_{Sub stitute}

/

1

A,F:H(z,j,l*) 1 A,F:H(z,j,l*)

\

_Substitute

/

1

A,F:H(z,j,l) g A:F(g*,y,h*,z)

\

_Substitute

/

1

A:F(g,y,h* ,z)

After execution of H the generated pointer h may be substituted in the description of F. When F finally has been executed, the job is completed.

The function of the operators is summarised in figure 2. The example that has been discussed in separate parts, is· as a whole illustrated in figure 3.

If we now think of the fact that the processes, which belong to the defined operators, may be executed in different units of the system, it will be clear that transport of taskdescriptions, datapointers and datafiles is neces sary. This trans port will effect the taskdescriptions. Logical references, for example, will be expanded or substituted by physical addresses. These addresses refer to the place where datafiles and j ob-, taskdescriptions are resident.

(19)

4. Structure of the communication network

Our system is built using intelligent devices, which are interconnected by means of an intelligent network (see figure 1). A device that is part of the system may be any kind of device from the computer world. For example peripherals like a Cardreader, High Speed Reader, Printer, Punch, Plotter, Disks etc are devices, as well as complete computer systems. A device can perform the functions for what it has been designed. A Cardreader must be capable of reading cards, nothing else. A Printer must print dsts. However, in our system some intelligence and storage capacity will be added to these peripherals, because we wsnt them to be capable of performing the tasks on their own. An intelligent device will be called FIFU, which is the abbreviation for Fully Independent Functional Unit.

The different processes, that belong to the operators (Fork, Parse, Join, Execute and Substitute) may, as is stated at the end of section 4.3, be executed in different units. From this it is clear that two different forms of transport are required in the system, viz:

1. Transport of j obdescriptions, taskdescriptions and datapointers.

2. Transport of dataflles.

More generally we could say that the first form of transport is related to short messages, while the second form affects long messages. For each form of transport a separate network has been designed, because the nature of the transports is different. At a

first glance both networks are completely independent, but the choice of the datacommunication network implies thst the two networks may be coupled.

4.1 Transport of lob-, taskdescriptions and datapointers

The transport of short messages is the fir-st form of transport we meet in our system. A job that has been loaded into the system, must be distributed over the system, after i t has been split up in separste tasks. Suspended tasks must wait until the correct datapointers can be substituted. This splitting of jobdescriptions and spreading of taskdescriptions over the different units of the system, as well as the substitution of datapointers, are typical processes that don't belong to the functions of a FIFU. They should be handled by an Operating System (O.S.). All units that receive jobs from users, pass the jobdescriptions to the O.S. This 0.5. splits jobdescriptions and distrib utes descriptions of sus pended tas ks to other FIFU' s.

Datapointers which are generated after execution of tasks are passed to the O.S. This O.S. then substitutes these datapointers in descriptions of suspended tasks. We thus find next three processes in the O.S.:

(20)

1. Splitting jobdescriptions (Parse)

2. Substitution of datapointers (Substitute)

3. Distribution of descriptions of executable tasks (Distribute)

The earlier defined processes Fork, Join and Execute are handled by the FIFU's.

One could think of a central O.S. to which all FIFU's can be connected. This structure easily becomes a bottleneck in the system, because all command s assemble there and are spread from there. Therefore i t is better to distribute the 0.5. and give every FIFU-i its

own O.S.-i. The resulting structure is shown in figure 4. Now the bottleneck has been removed, but another problem has come instead. Distribution of the 0.5. calls for a communication network, which connects the different O.S.'s. "What should the O.S.-communication network look like?"

From literature many configurations, each with its own advantages and disadvantages, are known. E.g. ring line, shared memory, completely interconnected, etc.

Only a few configurations can be used, because distribution of the O.S.'s gives the best results if two arbitrary O.S,'s can communicate with each other without disturbing others, When there are n O.S,'s, there must be a possibility to make at least n/2 simultaneous connections (full duplex). The networkconfigurations thst csn accomplish this are:

a. completely interconnected b. matrix

c. matrix-like structure with broadcasting

A completely interconnected system asks for many connection wires. A matrix has the advantage that only a few lines are needed. But on the other hand it has the disadvantage that switching of connections is required. Especially with transport of short.messages this leads to an enormous overhead.

The configuration of c. fits best to our problems. Every O.S.-i has its own channel-i on which i t may freely trsnsmit, It also can listen to the transmitting chsnnels of all other O.S.'s. In figure 5. this is shown. The O.S.'s should be placed on short geographical distances from each other because of the n receiving lines of an 0.5. All O.S.'s will be placed centrally and the separation of units and central module will be between the FIFU's and the O.S.'s.

4.2 Transport of dsta

In contrast to the transport of job-, taskdescriptions and datapointers, transport of data is something which the FIFU's must be capable of themselves. A FIFU that has received a taskdescription of

(21)

an executable task, by way of its 0.5., has to collect the dataflles that are referred to by the datapointers. We want that two arbitrary FIFU's can communicate with each other, without disturbing other units. This means that a number of connections may be active simultaneously. For a non-blocking system we demsnd for the possibility of at least n/2-fu11 duplex connections in a system with n FIFU's. Because FIFU's may be placed on large distances and because

datatransport involves long messages, we choose the matrix structure

as base for the datacommunication network.

We may look upon a matrix as a unit consisting of row- and

column-lines, which may be connected by closing the switches which are placed at the crossing points of the lines. A FIFU can transmit dats on its columnline and receive data from its rowline, by connecting this line with one of the columnlines. Closing a switch, connects two FIFU's. For a full-duplex connection two switches must be closed. For example when l wants to exchange data with FIFU-n, switches (l,n) and (FIFU-n,l) must be closed. The structure of the matrix is shown in figure 6. It seems that only a central structure applies for the matrix. However by "pulling out" the switches of one row and looking upon them as a separate unit, one can think of the matrix being distributed over various FIFU's. Figure 7 illustrates thi s idea.

Signals with which switches can be closed or opened are denoted with "CONTROL". Further study of this distributed matrix reveals that in fact we hsve got broadcasting. FIFU-i may freely transmit on channel-i and can "lchannel-isten" to all other channels by selectchannel-ing the approprchannel-iate switch. This is why the organization structure of the O.S.-communication net"ork was called a matrix-like structure with broad casting.

4.3 Control of the switches in the matrix

The choice of the matrix implies that a Switch Controller is needed to close and open the switches. By a "Request", a FIFU asks this controller, to realize a connection in the matrix. For this controlling one could design a separate controller. This controller has a distributed configuration just like the Operating System. But in fact the functions of this controller do not differ from those found in the Operating System. Therefore these functions are added to the Operating System. Thus both networks are coupled together. Figure 8 shows the configuration of our total system. The blocks denoted as CIU (Command Interface Unit) perform the functions, belonging to the Operating System, as well as those concerning the control of the switches. The blocks which are marked with dotted lines are called Data Interface Units (DIU).

Figure 9 gives a more general blockdiagram. The n-matrix columnlines are deno ted as DTF (Data Trans port Fac ility). The lines which fa rm the connection between the CIU's are denoted as CTF (Command Trans port Facility).

(22)

5. The structure of the FIFU's and

cru's

In this chapter the blockdiagrams of the FIFU's and CIU's are derived. This is accomplished by means of the functions which these parts must perform. In our preceding analysis, different functions have already been assigned to these blocks. The transports which a block has to deal with are also evident from this analysis. The following table lists the functions and transports of all system parts. Transport of command s refers to the transportation of jobdescriptlons, taskdescriptions, datapointers and requests for

connections in the datamatrix.

SYSTEMPART FUNCTIONS TRANSPORTS

EXECUTE

FORK COMMANDS

FIFU JOIN DATA

BUFFERING of datafiles PARSE SUBSTITUTE DISTR IB UT ION of descriptions of

CIU executable tasks COMMANDS

BUFFERING of descriptions of suspended tasks SW ITCH CONTRO L REALISATION OF

DIU PHYSICAL CONNEC- DATA

TIONS

REALISATION OF

DTF PHYSICAL CONNEC- DATA

TIONS BETWEEN DIU's

REALISATION OF

CTF PHYSICAL CONNEC- COMMANDS

TIONS BETWEEN CIU's

Table 1. Functions and transports of all system parts

(23)

The structure of the different parts may now eaaily be determined. Only FIFU's and CIU's are discussed here. The structure of DIU's, DTF and CTF is clear from figures 8 and 9.

5.1 Blockdiagram of a FIFU

From the different functions a FIFU should perform, we decide that a FIFU should be devided in four major parts, viz:

1. Device

2. Device Co n troller

3. Buffer Memories

4. Communication Controllers

The function Execute is resident in the device. The device executes a task belonging to a job, or reads a job presented by a user. The device controller controla the operation of the device. The functions Fork ng to a job, or reads a job presented by a user. The device controller controls the operation of the device. The functions Fork dependent I/O.

Data- and command-communications are performed by two separate controllers. The data communication controller controls the data-exchange with other FIFU's. The command communication controller controls the exchange of commands with the CIU and activates the data communication controller. Direc t Memory Ac ces a (D MA) facilities are required in the communication controllers, because data is transferred at a rate of several Mbits/sec. An intelligent DMA controller, e.g. Intel's 8089 I/O-processor, can handle these high datarates and has enough processing power. Both controllers should be equipped with an I/O processor, parallel to serial and serial to parallel converters, control store and circuitry for galvsnic separation between the FIFU and the channels.

Two buffer memories guarantee an independent operation of the three controllers. Buffering of datafiles is handled by the data buffer memory.

The resulting blockdiagram of a FIFU is shown in figure 10. 5.2 Blockdiagram of a CIU

From the different functions that a CIU must perform, we decide that this unit consist of four parts, viz:

1. Command Procesaor 2. Buffer Memories

3. Communication Controllers

The command processor processes messages, coming from other ClU"s or the FIFU. This command procesaor should contain a microprocessor (e.g. 8086), control store, data store and special I/O to control the

(24)

Two separate communication controllers are required. The command communication controller handles the communication with the FIFU and is identical to the command communication controller of this FIFU. The command transport controller handles the command-exchange with other CIU's.

Here also two buffer memories are placed between the command processor and the communication controllers. These buffers guarantee independent operation of the processor and the controllers. The blockdiagram of s CIU is shown in figure 11. Comparing this figure with figure 10. reveals thst the structures of a CIU and FIFU closely resemble each other. One could think of the controlled DIU as being the device of the CIU.

6. Conclusion

Starting from a logical approach, by means of jobs and tasks, a system configuration for a distributed system has been designed. Modularity and flexibility together with a simple Operating System are the most important features. This report only showed the theoretical solution to our problem. However, implementation in hsrd-and software is feasible.

Use of Intel's 8089 I/O-processors for the communication controllers (Command communication controller. data communication controller and command transport controller) and 8086 processors for the command processing parts (Device controller and Command Processor) allows for an easy hard ware solution. The diffetent units (FIFU's) of which ··the system is composed all behave equally to the exchange (CIU's and DIU's). The only difference.between them is at the side of the device. This feature together with the structural plan of the distributed Operating System makes the software re1ativUy simple and straightforward.

(25)

7. References

(1) Haendel, P.A.C. van

NONBLOCKING INTERNAL COMMUNICATION COMMUNICATION EXCHANGE FOR A PROCESSORSYSTEM (in Dutch).

M.Sc. Thesis. Digital Systems Group, Department of Electrical Engineering, Eindhoven University of Technology, 1975.

(2) Helvoort, A.G.M. van

INPUT-OUTPUT COMMUNICATION SYSTEM FOR A PROCESSORSYSTEM (in Dutch) .

(3) Engbersen, A.P.J.

DESIGN OF A NON-BLOCKING COMMUNICATION NETWORK FOR A COMPUTER SYSTEM (in Dutch).

(4) Dortmans, H.M.J.M.

SYSTEM ORGANIZATION FOR THE INTERNAL COMMUNICATION IN A COMPUTER (in Dutch).

M.Sc. Thesis. Digital Systems Group, Department of Electrical

Engineering, Eindhoven University of Technology, 1978.

(5) Stevens, M.P.J. and A.M.G. Claessen

A UNIVERSAL HIGH SPEED MICROPROGRAMMABLE I/O-CONTROLLER. In: MICROCOMPUTER ARCHITECTURES. Proc. 3rd EUROMICRO Symp.

on Microprocessing and Microprogramming, Amsterdam, 3-6 Oct.

1977. Ed. by J.-D. Nicoud et al.

Amsterdam: North-Holland, 1977. P. 250-257. (6) Cypser, R.J.

COMMUNICATIONS ARCHITECTURE FOR DISTRIBUTED SYSTEMS.

Reading, Mass.: Addison-Wesley, 1978. Systems programming series

(7) FLOW CONTROL IN COMPUTER NETWORKS. Proc. Int. Symp.,

Versailles, 12-14 Febr. 1979. Ed. by J.-L. Grange and M. Gien. Amsterdam: North-Holland, 1979.

(8) Weitzman, C.

DISTRIBUTED MICRO/MINICOMPUTER SYSTEMS: Structure, implementation,

and application.

(26)

(27)

I

\

intelligent

device

intelligent

network

---

-/ / /

Figure 1. Global System configuration

I

/

I

(28)

JOB ~ EXTENDED DATAFILES - - - FORK ________

~

JOBDESCRIPTION JOBDESCRIPTION - - - _ .. PARSE DESCRIPTIONS OF / SUSPENDED TASKS

~

DESCRIPTIONS OF EXECUTABLE TASKS

TASK DESCRIPTION TASKDESCRIPTION

SUSPENDED TASK ~ / SUSPENDED TASK

~ SUBSTITUTE ' "

DATAPOINTERS --- \ . 'fASKDESCRIPTION eXECUTABLE TASK

EXECUTABLE TASK ~

TASKDE5CRIPTION / EXTENDED DATAFILES

~JOIN~

EXTENDED DATAFILES / EXECUTABLE TASK EXECUTABLE TASK EXTENDED DATAFILES - - - -... EXECUTE

<

DATAPOINTERS

.c

OUTPUT)

(29)

Jut " JOIN ~

•

A,r,C(OFr. A.H,JICFx) ~

•

£,u:::u'n: txtcUT[

I

\

I

'.

OfC:I III

•

DFj (I)

1

A,rLG(JI) ,)',IiL~,J(.) ,Lty)) , l )

•

p'\RSe

~

________

~J-~

________

~.

__

~,

A,H,J'r.) A,II,LI),) A,f;H(:.;-,1") A:)('J·,y,r.6_,1)

J;)I:I ~ A,HILIOry)

•

!';XE:'-IT;.:

/

\,. DYl (1) SU8STI"':'<JT£ I ________________________________________________________________ -C'O.'C'"I\L~,j,l) ';')1:' I A,f,Hlotl,uFJ,OF1I j t:lC£CUT£ / ~ ~rn \ I J 1'. I

I

eXECUTe

/

\

on iii

Figure 3. processing of a job

N

(30)

I

/

I

/

I

\

"-\

\

"-...

FIFU

1 o

S-1

OS

communication

network

"- / '

--

-

----

-

- -

-/ ; '

---

.--....

CI

Cot:;;

en

_c:

•

Cot

I

/

I I

/

I /

/

. / /

Figure 4. Organization structure for a completely distributed

(31)

FIFU

1 F IF U

2

I

FIFU

n

I 2 n

I

OS-l

,

I

,

I

,

I

_,

OS -2

,

I

"-"-

,

I

_I

I

_I

I

_I

I

_I

I

_I

I

_I

I

_I

I

_I

I

OS-"

,

I

"-I

I

broadcast

I

L _ _ _ _ _ _ _ _ _

channels-l

(32)

FIFU

1 F IFU

2 I

I

FIFU

n

r-,---

1 2

- - - l

n

I

, - - - -~-

- --

_. -. ---

--

--"

-

--

-

-,_ ..

-I

I , I

\" \"

\"

I

L _ _ _ (1,1) (1.2) (1.n) f--- - - f----

- - - -

;-I

I

_,

\"

I

(2.1) (2,2) (2,n)

I

_\'\

\"

I

(n. 1) (n,2) (n,n)

L ___

_{- - -}

_f I

-Figure 6. Lay-out of the matrix

I

-1

I

.-I

I

_J

I

(33)

FIFU

1 FIFU

2 I

I

FI FU

n

...

1 - - - 1

I

1 2 " 1

I

J

. I

I

(1,2) (1,1' I

I

...

(1.n) ...

I

icontro,

I

J

_-I

I

(2,11

~

I.

I

~

I

control

I

1

I

.I

I

(11,1)

(11,2),....--

r--L

1-~

I

icontrol

I

, \ \ \

,

\ \ \

,

\

,

\

,

_,

\ \ \ \

column

I

L

lines

~

(34)

,

FIFU

1 I

I

FIFU

n

~

,---I

DIU

I

,----:

1 I

_I

I

(1,1' ___

-I

.--

T

I

1(I,~ I

I

(1,n' ...

,

I

-

T

I

L __

_-~

I

1 I

I

CIU

,

L

T

I

DIU

_n

I

I---~

I

~ ...

!

I

~

I

(o,n' ...

!

I

-

I

L __

_ --.J

I

~

1 CIU

I

_n

I

L _

1 2 " 1 2

,

\ \ \ \ \ \ _, \ \

_,

\ \

,

\ \

,

\ \ \

"

- - I

I

\ \ \

,

\

I

column broadcast

l

_lines _channelsJ

(35)

DIU

1 FIFU

V

1 CIU

1

4

I

DIU

2 -

-FIFU

V

FIFU

l>

2 CIU

n

2 command transport facITity

Figure 9. General blockdiagram of the total system

DIU

n

CIU

n

• ,

)

N

'"

(36)

I

d

e

v

i

C

e

---,

1

data

I

IA

~11.

_IA

_{J \}

I

buffer

d

I' II'

_memory

,

"

data

I

e

comm.

_r--

I V

IL

11.

control.

_I

i

status

c

! '4

"

I

e

•

~

I

! ~

...

c

I

0 _I

1'4 II'

_n

I

t

'0;

""

r

_I

0

A

...

I

_status

I

_I"

II'

com-

I

e

mand

r--r

1..1

"

command

1.4.

~

comm.

I

buffer

control.

_I

IV

--v

_memory

_I'

--v

I

1

I

L - - - -

- -

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

J

Figure 10. B10ckdiagram of a FIFU

/'"

r

-I

I

_...

_DIU

I

con trol

I

1

I

~

CIU

I

1 I

I

_ I _ _ _ _ _

...,

o

(37)

I

IA

'"

command

A

• _I

_I

I

buffer

com-o 0

c

•

r

_memory

~

v

mand

1 I

,

0 _transp.

!

I

ClF

m

..

_\

I

_m

status

_.I

control.

_• t

I

a

I"

r I

_I

I

d

n

~ ~

I

_I

I

A I _{' - - -}

-r -

--I

---....,

I

r

-I

DIU

contro

P

_I

~

I

_r

I

,-

-I

0

_-.;

_;..

I

_e

c

,A

..

I

_I

I

s

status

s

~ r

com-I

I

₀

mand

r"'"

/

...

FIFU

I

r

A

"

command

_buffer

..

control.

comm.

I

_I

I

~ r

_memory

...

v

I

L _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

J

_{L _ _ _ _ _}

(38)

Reports: _{EUT Reports arc a continuation of TH-Reports.} 116) Vennel, W.

THE CIRCULAR HALL PLATE: Approximation of the geometrical correction

factor for small contacts.

TH-Report 81-E-116. 1981. ISBN 90-6144-116-1 117) Fabian. K.

"'iiEslGN' AND IMPLEMENTATION Of A

A MUL!1MASTER 'SUS iNTERFACE.

TH-Report 81-E-117. 1981. ISBN

CENTRAL INSTRUCTION PROCESSOR WITH

90-6144-117-X

t18) Wana Yen ?ing

ENCODING MOVING PICTURE BY USI~G ADAPTIVE STRAIGHT LINE APPROXIMATION.

EUT Report 81-E-118. 1981. ISBN 90-6144-118-8

119) Heijnen. C.J .H.t H.A. Jansen, J.F.G.J. Olijslagers and W. ~

FABRICATION OF PLANAR SEMICONDUCTOR DIODES. AN EDUCATIONAL LABORATORY

EXPERIMENT. 120)

121 )

EUT Report 81-£-119. 1981. ISBN 90-6144-119-6. Piecha. J.

DE$ciITPTION AND IMPLEMENTATION OF A SINGLE SOARD COMPUTER FOR INDUSTRIAL CONTROL.

EUT Report 81-[-120. 1981. ISBN 90-6144-120-X ~I J.L.C. and C.H.H. ~

DIRECT MEASUREMENT OF BLOOD PRESSURE BY LIQUID-FILLED CATHETER MANOMETER SYSTEMS.

EUT Report 81-[-121. 1981. ISBN 90-6144-121-8 122) Ponol1larenko. ~I.F.

lNFORMATION THEORY AND IDENTifICATION.

EUT Report 81-1':-122. 1981. {SBN 90-6144-122-6 123) Ponomarenko. M.F.

INFORMATION MEASURES AND THEIR APPLlCATIONS TO IDENT IFICATlON

(a bibliography).

EUT Report 81-£-12). 1981. ISBN 90-6144-123-4 124) Borghi. C.A .• A. Veefkind and J.M. ~

EFFECT OF RADIATION AND NON-MAXWELLIAN ELEcTRON DISTRIBUTION ON

RELl\XATION PROCESSES IN AN Ai'HM:>SPHERl.C CESIUM SEEDED ARGON PLASMA.

EUT Report 82-£-124. 1982. ISBN 90-6144-124-2 125) Saranummi, N.

DETECTION OF TRENDS IN LONG TERM RECORDINGS OF CARDIOVASCULAR SIGNALS.

EUT Report 82-E-125. 1982. ISBN 90-6144-125-0 126) Kroliko .... ski, A.

MoDEL STRUCTURE SELECTION I:-.r LINEAR SYSTEM IDENTrFTCATTflN: Survey

uf fficthuds ""itlt emplta:;is on the i.nformation thenry <lPT'Toach. EtJ'f Report g}-E-126. 1982. ISBN 90-6144-126-9

Eindhoven University of Technology Research Reports (ISSN 0167-9708)

(127) Damen, A.A.H., P.M.J. Varl den Hof al'ld A.K. HajJasin~ki

THE PAGE MATRIX: An excellt:!nt tool for noise filtering of ~ark<lV

parameters, order testing and realization.

EDT Report 82-E-127. 19B2. ISBN 90-6144-127-7 (128) Nicola, V.F.

HARKOVL\N MODELS OF 1\ TRANSACTIONAL SYSTEM SUPPORTED 8Y CHECKPOINTING AND RECOVERY STRATEGIES. Part]: A model ',.Iith stilte-dependent parameters.

EUT Report 82-E-]28. 1982. IS8N 90-td44-128-5 (129) Nicola, V.F.

MARKOVIAN MODELS OF II TRANSACTIONAL SYSTEM SUPPORTED BY CIIECKP()I~'TING

AND RECOVERY STRATEGIES. Part 2: A ilIodel .... ith a specified number of completed transactions bel1.h!~l\ checkpoints.

EUT Report 82-E-]29. 1982. ISBN 90-6144-129-) l13v) Lemmcns, W.J.M.

(131)

THE PAP P~PROCESSOR: A precompiler for a language for concurrent processing on a multiprocessor system.

EUT Report 82-E-130. 1982. ISBN 90-6144-130-7

Eijnden, P.M,C.M. van den, H.M.J.M. Dortmans, J.P. Kemper and

M.P.J. Stevens

JOBHANO~ A NETWORK OF DISTRIBUTED PROCESSORS. EUT iG:!port 82-E-131. 1982. ISBN 90-6144-131-5