Amoeba Distributing operating system

Agrata shukla 0127cs091001

IntroductionThe Amoeba operating system began as a research project in Vriji

universiteit in Amesterdem

The basic goal of amoeba is to provide user a single powerful time sharing systems while actually running their jobs on a collection of machines potentially distributed over several computing sites

The basic is to provide users with the illusion of single powerful time sharing system when infact the system is implemented on a collection of machines potentially distributed among several countries

History of Amoeba

The initial research done in Amsterdam led to the design and implementation of the Amoeba Distributed Operating System

It is used as a prototype and a vehicle for further research both at Vrije Universiteit and at the Center for Mathematics and Computer Science also in Amsterdam

The goal of this further research was to build a distributed system that is invisible to users

Main objectives of Amoeba

The basic design goals of Amoeba are

Distribution ndash Connecting together many machines

Parallelism ndash Allowing individual jobs to use multiple CPUs easily

Transparency ndash Having the collection of computers act like a single system

Performance ndash Achieving all of the above in an efficient manner

Amoeba System architecture

The hardware of an Amoeba system has three principal components all connected by a LAN

- An X-terminal or workstation running X-Windows for each user

- The processor pool (a rack of single-board computers)

- A certain number of dedicated servers (file server etc)

Each user has an X-terminal (or workstation running X-Windows) for talking to the system

Although it is technically possible to run user jobs on this machine that is not normally done as it is

the intention to have Amoeba programs use multiple processors in parallel to improve performance

The processor pool idea is based on the assumption that the ratio of processors to users is large

Processor pool model

Although using idle workstations adds a little computing power to the system it does not address a more fundamental issue

1048713What happens when it is feasible to provide 10 or 100 times as many CPUs as there are active users

1One solution as we saw is to give everyone a personal multiprocessor However this is a somewhat inefficient design

2An alternative approach is to construct aprocessor pool a rack full of CPUs in the machine room which can be dynamically allocated to users on demand

1048713Instead of giving users personal workstations in this model they are given high-performance graphics terminals

1048713Conceptually it is much closer to traditional timesharing than to the personal computer model although it is built with modem technology

Objects and capabilities

Amoeba is an object-based system The system can be viewed as a collection of objects on each of which there is a set of operations that can be performed

Associated with each object is a capability [8] a kind of ticket or key that allows the holder of the capability to perform some (not necessarily all) operations on that object A user process might

Each user process owns some collection of capabilities which together define the set of objects it may access and the type of operations he may perform on each

Thus capabilities provide a unified mechanism for naming accessing and protecting objects

From the userrsquos perspective the function of the operating system is to create an environment in which objects can be created and manipulated in a protected way

Remote procedure calls

The client has to place the capability operation code and parameters in the request buffer and on receiving the reply it has to unpack the results

The server has to check the capability extract the operation code and parameters from the request and call the appropriate procedure

Remote procedure call

The author of the handwritten stub uses several pieces

of derived information to do the job

1 The buffer is used only to receive information from the file server it is an output parameter and should not be sent to the server

2 The maximum length of the buffer is given in the nbytes parameter The actual length of

the buffer is the returned value if there is no error and zero otherwise

3 File1048713 cap is special it defines the service that must carry out the remote operation

4 The stub generator does not know what the serverrsquos operation code for read1048713 file is This

requires extra information But to be fair the human stub writer needs this extra information too

Threads

A process in Amoeba consists of one or more threads that run in parallel All the threads of a process share the same address space but each one has a dedicated portion of that address space for use as its private stack and each one has its own program counter

The RPC communication is actually between threads of a process not the process itself

The RPC creation sending receiving and decoding are all processed by the kernel There are library functions defined which give interfaces to the user program and allows for a seamless view of thread communication to the programmer

Servers

The Amoeba kernel as described above essentially handles communication and some process management and little else The kernel takes care of sending and receiving messagesscheduling processes and some low-level memory management Everything else is done by user processes

A process is created by executing the following steps

1 Get the process descriptor for the binary from the file system

2 Create a local segment or a file and initialize it to the initial environment of the new process

The environment consists of a set of named capabilities (a primitive directory as it

were) and the arguments to the process (in Unix terms argc and argv)

3 Modify the process descriptor to make the first segment the environment segment just

created

Send the process descriptor to the machine where it will be executed

Bullet server

The bullet server is an immutable file store with as principal operations read-file and create-file (For garbage collection purposes there is also a delete-file operation) When a process issues a read-file request the bullet server can transfer the entire file to the client in a single RPC unless it is larger than the maximum size (30000 bytes) in which case multiple RPCs are needed The client can then edit or otherwise modify the file locally When it is finished the client issues a create-file RPC to make a new version

The files are stored contiguously on disk and are cached in the file serverrsquos memory(currently 12 Mbytes) When a requested file is not available in this memory it is loaded from disk in a single large DMA operation and stored contiguously in the cache

In the create-file] operation one can request the reply before the file is written to disk (for speed) or afterwards (to know that it has been successfully written)

Directory server

The bullet server does not provide any naming services To access a file a process must provide the relevant capability Since working with 128-bit binary numbers is not convenient for people we have designed and implemented a directory server to manage names and capabilities

Using this capability the process can then access the file In UNIX terms when a file is opened the capability is retrieved from the directory server for use in subsequent read and write operations After the capability has been fetched from the directory server subsequent RPCs go directly to the server that manages the object The directory server is no longer involved

WIDE-AREA AMOEBA

Amoeba was designed with the idea that a collection of machines on a LAN would be able to communicate over a wide-area network with a similar collection of remote machines The key problem here is that wide-area networks are slow and unreliable and furthermore use protocols such as X25 TCPIP and OSI in any event not RPC

APPLICATIONS

Amoeba has been used to program a variety of applications In this section we will describe several of them including UNIX emulation parallel make traveling salesman and alpha-beta search

UNIX Emulation

One of the goals of Amoeba was to make it useful as a program development environment

For such an environment one needs editors compilers and numerous other standard

software It was decided that the easiest way to obtain this software was to emulate UNIX and

then to run UNIX and MINIX [25] compilers and other utilities on top of it

PERFORMANCE

1 Two user processes running on Amoeba

2 Two user processes running on Sun OS 403 but using the Amoeba primitives

3 Two user processes running on Sun OS 403 and using Sun RPC

The latter two were for comparison purposes only We ran tests for the local case (both

processes on the same machine) and for the remote case (each process on a separate machine

with communication over the Ethernet) In all cases communication was from process to process

all of which were running in user mode outside the kernel The measurments represent

the average values of 100000 trials and are highly reproducible

Memory and Process Management

Amoebarsquos memory model which is handled by the microkernel is very small and efficient A processrsquos address space contains segments mapped onto user-specified virtual addresses

These segments include but not limited to a textcode segment a data segment and a stack segment for mainthread process

When a process is executing all of its segments are in memory Amoeba does not utilize virtual memory or swapping so it can only run programs that do not exceed physical memory This does however keeps the management scheme simple and provides high performance

File System

One area of the system which we think has been eminently successful is the design of the file server and directory server We have separated out two distinct parts the bullet server which just handles storage and the directory server which handles naming and protection The bullet server design allows it to be extremely fast while the directory server design gives a flexible protection scheme and also supports file replication in a simple and easy to understand way The key element here is the fact that files are immutable so they can be replicated at will and copies regenerated if necessary

The entire replication process takes place in the background (lazy replication) and is entirely automatic thus not bothering the user at all We regard the file system as the most innovative part of the Amoeba 40 design combining high performance with reliability robustness and ease of use

Security

An intruder capable of tapping the network on which Amoeba runs can discover capabilities and do considerable damage In a production environment some form of link encryption is needed to guarantee better security Although some thought has been given to a security mechanism [26] it was not implemented in Amoeba 40

We intend to install both versions and investigate the effects on performance of the system We are researching the problems of authentication in very large systems spanning multiple organizations and national boundaries

Io scheduling

Input and output (memory disk) is handled by the microkernel threads To read a block from the disk a process does remote procedure calls to a disk IO thread in the kernel The calling process does not know that the server is actually a kernel thread because user thread interfaces are identical to kernel thread interfaces

As far as file IO goes having multiple threads within a process accentuates the distributed and parallel and computing model very well

Reasons to use Amoeba

The need to control several machines from one user process can be accomplished by a distributed operating system such as Amoeba

Another situation that could efficiently utilize a distributed system is any program that commonly requires large computations

A more practical reason to use the Amoeba operating system is to save money both by utilizing old hardware and by lessening the need topurchase expensive servers An additional reason to use Amoeba is that the source code for the operating system is available for free so you can make your own version of Amoeba to suit your needs

Reasons not to use Amoeba

Other clustered operating systems that operate in a similar fashion to Amoeba are more readily available and easier to use

This is due to the fact that the source code is available for each user to edit These reasons along with others make Amoeba a risky business venture

Conclusion

Overall the Amoeba distributed operating system is an interesting and unique idea It provides system administrators the power to distribute work over a variety of machines without inconveniencing the users Despite this and other useful features we predict that Amoeba will not ever become a widely used operating system However the knowledge gained by the development of and research about Amoeba has helped in the design of other distributed and clustered operating systems

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28

IntroductionThe Amoeba operating system began as a research project in Vriji

universiteit in Amesterdem

The basic goal of amoeba is to provide user a single powerful time sharing systems while actually running their jobs on a collection of machines potentially distributed over several computing sites

The basic is to provide users with the illusion of single powerful time sharing system when infact the system is implemented on a collection of machines potentially distributed among several countries

History of Amoeba

The initial research done in Amsterdam led to the design and implementation of the Amoeba Distributed Operating System

It is used as a prototype and a vehicle for further research both at Vrije Universiteit and at the Center for Mathematics and Computer Science also in Amsterdam

The goal of this further research was to build a distributed system that is invisible to users

Main objectives of Amoeba

The basic design goals of Amoeba are

Distribution ndash Connecting together many machines

Parallelism ndash Allowing individual jobs to use multiple CPUs easily

Transparency ndash Having the collection of computers act like a single system

Performance ndash Achieving all of the above in an efficient manner

Amoeba System architecture

The hardware of an Amoeba system has three principal components all connected by a LAN

- An X-terminal or workstation running X-Windows for each user

- The processor pool (a rack of single-board computers)

- A certain number of dedicated servers (file server etc)

Each user has an X-terminal (or workstation running X-Windows) for talking to the system

Although it is technically possible to run user jobs on this machine that is not normally done as it is

the intention to have Amoeba programs use multiple processors in parallel to improve performance

The processor pool idea is based on the assumption that the ratio of processors to users is large

Processor pool model

Although using idle workstations adds a little computing power to the system it does not address a more fundamental issue

1048713What happens when it is feasible to provide 10 or 100 times as many CPUs as there are active users

1One solution as we saw is to give everyone a personal multiprocessor However this is a somewhat inefficient design

2An alternative approach is to construct aprocessor pool a rack full of CPUs in the machine room which can be dynamically allocated to users on demand

1048713Instead of giving users personal workstations in this model they are given high-performance graphics terminals

1048713Conceptually it is much closer to traditional timesharing than to the personal computer model although it is built with modem technology

Objects and capabilities

Amoeba is an object-based system The system can be viewed as a collection of objects on each of which there is a set of operations that can be performed

Associated with each object is a capability [8] a kind of ticket or key that allows the holder of the capability to perform some (not necessarily all) operations on that object A user process might

Each user process owns some collection of capabilities which together define the set of objects it may access and the type of operations he may perform on each

Thus capabilities provide a unified mechanism for naming accessing and protecting objects

From the userrsquos perspective the function of the operating system is to create an environment in which objects can be created and manipulated in a protected way

Remote procedure calls

The client has to place the capability operation code and parameters in the request buffer and on receiving the reply it has to unpack the results

The server has to check the capability extract the operation code and parameters from the request and call the appropriate procedure

Remote procedure call

The author of the handwritten stub uses several pieces

of derived information to do the job

1 The buffer is used only to receive information from the file server it is an output parameter and should not be sent to the server

2 The maximum length of the buffer is given in the nbytes parameter The actual length of

the buffer is the returned value if there is no error and zero otherwise

3 File1048713 cap is special it defines the service that must carry out the remote operation

4 The stub generator does not know what the serverrsquos operation code for read1048713 file is This

requires extra information But to be fair the human stub writer needs this extra information too

Threads

A process in Amoeba consists of one or more threads that run in parallel All the threads of a process share the same address space but each one has a dedicated portion of that address space for use as its private stack and each one has its own program counter

The RPC communication is actually between threads of a process not the process itself

The RPC creation sending receiving and decoding are all processed by the kernel There are library functions defined which give interfaces to the user program and allows for a seamless view of thread communication to the programmer

Servers

The Amoeba kernel as described above essentially handles communication and some process management and little else The kernel takes care of sending and receiving messagesscheduling processes and some low-level memory management Everything else is done by user processes

A process is created by executing the following steps

1 Get the process descriptor for the binary from the file system

2 Create a local segment or a file and initialize it to the initial environment of the new process

The environment consists of a set of named capabilities (a primitive directory as it

were) and the arguments to the process (in Unix terms argc and argv)

3 Modify the process descriptor to make the first segment the environment segment just

created

Send the process descriptor to the machine where it will be executed

Bullet server

The bullet server is an immutable file store with as principal operations read-file and create-file (For garbage collection purposes there is also a delete-file operation) When a process issues a read-file request the bullet server can transfer the entire file to the client in a single RPC unless it is larger than the maximum size (30000 bytes) in which case multiple RPCs are needed The client can then edit or otherwise modify the file locally When it is finished the client issues a create-file RPC to make a new version

The files are stored contiguously on disk and are cached in the file serverrsquos memory(currently 12 Mbytes) When a requested file is not available in this memory it is loaded from disk in a single large DMA operation and stored contiguously in the cache

In the create-file] operation one can request the reply before the file is written to disk (for speed) or afterwards (to know that it has been successfully written)

Directory server

The bullet server does not provide any naming services To access a file a process must provide the relevant capability Since working with 128-bit binary numbers is not convenient for people we have designed and implemented a directory server to manage names and capabilities

Using this capability the process can then access the file In UNIX terms when a file is opened the capability is retrieved from the directory server for use in subsequent read and write operations After the capability has been fetched from the directory server subsequent RPCs go directly to the server that manages the object The directory server is no longer involved

WIDE-AREA AMOEBA

Amoeba was designed with the idea that a collection of machines on a LAN would be able to communicate over a wide-area network with a similar collection of remote machines The key problem here is that wide-area networks are slow and unreliable and furthermore use protocols such as X25 TCPIP and OSI in any event not RPC

APPLICATIONS

Amoeba has been used to program a variety of applications In this section we will describe several of them including UNIX emulation parallel make traveling salesman and alpha-beta search

UNIX Emulation

One of the goals of Amoeba was to make it useful as a program development environment

For such an environment one needs editors compilers and numerous other standard

software It was decided that the easiest way to obtain this software was to emulate UNIX and

then to run UNIX and MINIX [25] compilers and other utilities on top of it

PERFORMANCE

1 Two user processes running on Amoeba

2 Two user processes running on Sun OS 403 but using the Amoeba primitives

3 Two user processes running on Sun OS 403 and using Sun RPC

The latter two were for comparison purposes only We ran tests for the local case (both

processes on the same machine) and for the remote case (each process on a separate machine

with communication over the Ethernet) In all cases communication was from process to process

all of which were running in user mode outside the kernel The measurments represent

the average values of 100000 trials and are highly reproducible

Memory and Process Management

Amoebarsquos memory model which is handled by the microkernel is very small and efficient A processrsquos address space contains segments mapped onto user-specified virtual addresses

These segments include but not limited to a textcode segment a data segment and a stack segment for mainthread process

When a process is executing all of its segments are in memory Amoeba does not utilize virtual memory or swapping so it can only run programs that do not exceed physical memory This does however keeps the management scheme simple and provides high performance

File System

One area of the system which we think has been eminently successful is the design of the file server and directory server We have separated out two distinct parts the bullet server which just handles storage and the directory server which handles naming and protection The bullet server design allows it to be extremely fast while the directory server design gives a flexible protection scheme and also supports file replication in a simple and easy to understand way The key element here is the fact that files are immutable so they can be replicated at will and copies regenerated if necessary

The entire replication process takes place in the background (lazy replication) and is entirely automatic thus not bothering the user at all We regard the file system as the most innovative part of the Amoeba 40 design combining high performance with reliability robustness and ease of use

Security

An intruder capable of tapping the network on which Amoeba runs can discover capabilities and do considerable damage In a production environment some form of link encryption is needed to guarantee better security Although some thought has been given to a security mechanism [26] it was not implemented in Amoeba 40

We intend to install both versions and investigate the effects on performance of the system We are researching the problems of authentication in very large systems spanning multiple organizations and national boundaries

Io scheduling

Input and output (memory disk) is handled by the microkernel threads To read a block from the disk a process does remote procedure calls to a disk IO thread in the kernel The calling process does not know that the server is actually a kernel thread because user thread interfaces are identical to kernel thread interfaces

As far as file IO goes having multiple threads within a process accentuates the distributed and parallel and computing model very well

Reasons to use Amoeba

The need to control several machines from one user process can be accomplished by a distributed operating system such as Amoeba

Another situation that could efficiently utilize a distributed system is any program that commonly requires large computations

A more practical reason to use the Amoeba operating system is to save money both by utilizing old hardware and by lessening the need topurchase expensive servers An additional reason to use Amoeba is that the source code for the operating system is available for free so you can make your own version of Amoeba to suit your needs

Reasons not to use Amoeba

Other clustered operating systems that operate in a similar fashion to Amoeba are more readily available and easier to use

This is due to the fact that the source code is available for each user to edit These reasons along with others make Amoeba a risky business venture

Conclusion

Overall the Amoeba distributed operating system is an interesting and unique idea It provides system administrators the power to distribute work over a variety of machines without inconveniencing the users Despite this and other useful features we predict that Amoeba will not ever become a widely used operating system However the knowledge gained by the development of and research about Amoeba has helped in the design of other distributed and clustered operating systems

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28

History of Amoeba

The initial research done in Amsterdam led to the design and implementation of the Amoeba Distributed Operating System

It is used as a prototype and a vehicle for further research both at Vrije Universiteit and at the Center for Mathematics and Computer Science also in Amsterdam

The goal of this further research was to build a distributed system that is invisible to users

Main objectives of Amoeba

The basic design goals of Amoeba are

Distribution ndash Connecting together many machines

Parallelism ndash Allowing individual jobs to use multiple CPUs easily

Transparency ndash Having the collection of computers act like a single system

Performance ndash Achieving all of the above in an efficient manner

Amoeba System architecture

The hardware of an Amoeba system has three principal components all connected by a LAN

- An X-terminal or workstation running X-Windows for each user

- The processor pool (a rack of single-board computers)

- A certain number of dedicated servers (file server etc)

Each user has an X-terminal (or workstation running X-Windows) for talking to the system

Although it is technically possible to run user jobs on this machine that is not normally done as it is

the intention to have Amoeba programs use multiple processors in parallel to improve performance

The processor pool idea is based on the assumption that the ratio of processors to users is large

Processor pool model

Although using idle workstations adds a little computing power to the system it does not address a more fundamental issue

1048713What happens when it is feasible to provide 10 or 100 times as many CPUs as there are active users

1One solution as we saw is to give everyone a personal multiprocessor However this is a somewhat inefficient design

2An alternative approach is to construct aprocessor pool a rack full of CPUs in the machine room which can be dynamically allocated to users on demand

1048713Instead of giving users personal workstations in this model they are given high-performance graphics terminals

1048713Conceptually it is much closer to traditional timesharing than to the personal computer model although it is built with modem technology

Objects and capabilities

Amoeba is an object-based system The system can be viewed as a collection of objects on each of which there is a set of operations that can be performed

Associated with each object is a capability [8] a kind of ticket or key that allows the holder of the capability to perform some (not necessarily all) operations on that object A user process might

Each user process owns some collection of capabilities which together define the set of objects it may access and the type of operations he may perform on each

Thus capabilities provide a unified mechanism for naming accessing and protecting objects

From the userrsquos perspective the function of the operating system is to create an environment in which objects can be created and manipulated in a protected way

Remote procedure calls

The client has to place the capability operation code and parameters in the request buffer and on receiving the reply it has to unpack the results

The server has to check the capability extract the operation code and parameters from the request and call the appropriate procedure

Remote procedure call

The author of the handwritten stub uses several pieces

of derived information to do the job

1 The buffer is used only to receive information from the file server it is an output parameter and should not be sent to the server

2 The maximum length of the buffer is given in the nbytes parameter The actual length of

the buffer is the returned value if there is no error and zero otherwise

3 File1048713 cap is special it defines the service that must carry out the remote operation

4 The stub generator does not know what the serverrsquos operation code for read1048713 file is This

requires extra information But to be fair the human stub writer needs this extra information too

Threads

A process in Amoeba consists of one or more threads that run in parallel All the threads of a process share the same address space but each one has a dedicated portion of that address space for use as its private stack and each one has its own program counter

The RPC communication is actually between threads of a process not the process itself

The RPC creation sending receiving and decoding are all processed by the kernel There are library functions defined which give interfaces to the user program and allows for a seamless view of thread communication to the programmer

Servers

The Amoeba kernel as described above essentially handles communication and some process management and little else The kernel takes care of sending and receiving messagesscheduling processes and some low-level memory management Everything else is done by user processes

A process is created by executing the following steps

1 Get the process descriptor for the binary from the file system

2 Create a local segment or a file and initialize it to the initial environment of the new process

The environment consists of a set of named capabilities (a primitive directory as it

were) and the arguments to the process (in Unix terms argc and argv)

3 Modify the process descriptor to make the first segment the environment segment just

created

Send the process descriptor to the machine where it will be executed

Bullet server

The bullet server is an immutable file store with as principal operations read-file and create-file (For garbage collection purposes there is also a delete-file operation) When a process issues a read-file request the bullet server can transfer the entire file to the client in a single RPC unless it is larger than the maximum size (30000 bytes) in which case multiple RPCs are needed The client can then edit or otherwise modify the file locally When it is finished the client issues a create-file RPC to make a new version

The files are stored contiguously on disk and are cached in the file serverrsquos memory(currently 12 Mbytes) When a requested file is not available in this memory it is loaded from disk in a single large DMA operation and stored contiguously in the cache

In the create-file] operation one can request the reply before the file is written to disk (for speed) or afterwards (to know that it has been successfully written)

Directory server

The bullet server does not provide any naming services To access a file a process must provide the relevant capability Since working with 128-bit binary numbers is not convenient for people we have designed and implemented a directory server to manage names and capabilities

Using this capability the process can then access the file In UNIX terms when a file is opened the capability is retrieved from the directory server for use in subsequent read and write operations After the capability has been fetched from the directory server subsequent RPCs go directly to the server that manages the object The directory server is no longer involved

WIDE-AREA AMOEBA

Amoeba was designed with the idea that a collection of machines on a LAN would be able to communicate over a wide-area network with a similar collection of remote machines The key problem here is that wide-area networks are slow and unreliable and furthermore use protocols such as X25 TCPIP and OSI in any event not RPC

APPLICATIONS

Amoeba has been used to program a variety of applications In this section we will describe several of them including UNIX emulation parallel make traveling salesman and alpha-beta search

UNIX Emulation

One of the goals of Amoeba was to make it useful as a program development environment

For such an environment one needs editors compilers and numerous other standard

software It was decided that the easiest way to obtain this software was to emulate UNIX and

then to run UNIX and MINIX [25] compilers and other utilities on top of it

PERFORMANCE

1 Two user processes running on Amoeba

2 Two user processes running on Sun OS 403 but using the Amoeba primitives

3 Two user processes running on Sun OS 403 and using Sun RPC

The latter two were for comparison purposes only We ran tests for the local case (both

processes on the same machine) and for the remote case (each process on a separate machine

with communication over the Ethernet) In all cases communication was from process to process

all of which were running in user mode outside the kernel The measurments represent

the average values of 100000 trials and are highly reproducible

Memory and Process Management

Amoebarsquos memory model which is handled by the microkernel is very small and efficient A processrsquos address space contains segments mapped onto user-specified virtual addresses

These segments include but not limited to a textcode segment a data segment and a stack segment for mainthread process

When a process is executing all of its segments are in memory Amoeba does not utilize virtual memory or swapping so it can only run programs that do not exceed physical memory This does however keeps the management scheme simple and provides high performance

File System

One area of the system which we think has been eminently successful is the design of the file server and directory server We have separated out two distinct parts the bullet server which just handles storage and the directory server which handles naming and protection The bullet server design allows it to be extremely fast while the directory server design gives a flexible protection scheme and also supports file replication in a simple and easy to understand way The key element here is the fact that files are immutable so they can be replicated at will and copies regenerated if necessary

The entire replication process takes place in the background (lazy replication) and is entirely automatic thus not bothering the user at all We regard the file system as the most innovative part of the Amoeba 40 design combining high performance with reliability robustness and ease of use

Security

An intruder capable of tapping the network on which Amoeba runs can discover capabilities and do considerable damage In a production environment some form of link encryption is needed to guarantee better security Although some thought has been given to a security mechanism [26] it was not implemented in Amoeba 40

We intend to install both versions and investigate the effects on performance of the system We are researching the problems of authentication in very large systems spanning multiple organizations and national boundaries

Io scheduling

Input and output (memory disk) is handled by the microkernel threads To read a block from the disk a process does remote procedure calls to a disk IO thread in the kernel The calling process does not know that the server is actually a kernel thread because user thread interfaces are identical to kernel thread interfaces

As far as file IO goes having multiple threads within a process accentuates the distributed and parallel and computing model very well

Reasons to use Amoeba

The need to control several machines from one user process can be accomplished by a distributed operating system such as Amoeba

Another situation that could efficiently utilize a distributed system is any program that commonly requires large computations

A more practical reason to use the Amoeba operating system is to save money both by utilizing old hardware and by lessening the need topurchase expensive servers An additional reason to use Amoeba is that the source code for the operating system is available for free so you can make your own version of Amoeba to suit your needs

Reasons not to use Amoeba

Other clustered operating systems that operate in a similar fashion to Amoeba are more readily available and easier to use

This is due to the fact that the source code is available for each user to edit These reasons along with others make Amoeba a risky business venture

Conclusion

Overall the Amoeba distributed operating system is an interesting and unique idea It provides system administrators the power to distribute work over a variety of machines without inconveniencing the users Despite this and other useful features we predict that Amoeba will not ever become a widely used operating system However the knowledge gained by the development of and research about Amoeba has helped in the design of other distributed and clustered operating systems

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28

Main objectives of Amoeba

The basic design goals of Amoeba are

Distribution ndash Connecting together many machines

Parallelism ndash Allowing individual jobs to use multiple CPUs easily

Transparency ndash Having the collection of computers act like a single system

Performance ndash Achieving all of the above in an efficient manner

Amoeba System architecture

The hardware of an Amoeba system has three principal components all connected by a LAN

- An X-terminal or workstation running X-Windows for each user

- The processor pool (a rack of single-board computers)

- A certain number of dedicated servers (file server etc)

Each user has an X-terminal (or workstation running X-Windows) for talking to the system

Although it is technically possible to run user jobs on this machine that is not normally done as it is

the intention to have Amoeba programs use multiple processors in parallel to improve performance

The processor pool idea is based on the assumption that the ratio of processors to users is large

Processor pool model

Although using idle workstations adds a little computing power to the system it does not address a more fundamental issue

1048713What happens when it is feasible to provide 10 or 100 times as many CPUs as there are active users

1One solution as we saw is to give everyone a personal multiprocessor However this is a somewhat inefficient design

2An alternative approach is to construct aprocessor pool a rack full of CPUs in the machine room which can be dynamically allocated to users on demand

1048713Instead of giving users personal workstations in this model they are given high-performance graphics terminals

1048713Conceptually it is much closer to traditional timesharing than to the personal computer model although it is built with modem technology

Objects and capabilities

Amoeba is an object-based system The system can be viewed as a collection of objects on each of which there is a set of operations that can be performed

Associated with each object is a capability [8] a kind of ticket or key that allows the holder of the capability to perform some (not necessarily all) operations on that object A user process might

Each user process owns some collection of capabilities which together define the set of objects it may access and the type of operations he may perform on each

Thus capabilities provide a unified mechanism for naming accessing and protecting objects

From the userrsquos perspective the function of the operating system is to create an environment in which objects can be created and manipulated in a protected way

Remote procedure calls

The client has to place the capability operation code and parameters in the request buffer and on receiving the reply it has to unpack the results

The server has to check the capability extract the operation code and parameters from the request and call the appropriate procedure

Remote procedure call

The author of the handwritten stub uses several pieces

of derived information to do the job

1 The buffer is used only to receive information from the file server it is an output parameter and should not be sent to the server

2 The maximum length of the buffer is given in the nbytes parameter The actual length of

the buffer is the returned value if there is no error and zero otherwise

3 File1048713 cap is special it defines the service that must carry out the remote operation

4 The stub generator does not know what the serverrsquos operation code for read1048713 file is This

requires extra information But to be fair the human stub writer needs this extra information too

Threads

A process in Amoeba consists of one or more threads that run in parallel All the threads of a process share the same address space but each one has a dedicated portion of that address space for use as its private stack and each one has its own program counter

The RPC communication is actually between threads of a process not the process itself

The RPC creation sending receiving and decoding are all processed by the kernel There are library functions defined which give interfaces to the user program and allows for a seamless view of thread communication to the programmer

Servers

The Amoeba kernel as described above essentially handles communication and some process management and little else The kernel takes care of sending and receiving messagesscheduling processes and some low-level memory management Everything else is done by user processes

A process is created by executing the following steps

1 Get the process descriptor for the binary from the file system

2 Create a local segment or a file and initialize it to the initial environment of the new process

The environment consists of a set of named capabilities (a primitive directory as it

were) and the arguments to the process (in Unix terms argc and argv)

3 Modify the process descriptor to make the first segment the environment segment just

created

Send the process descriptor to the machine where it will be executed

Bullet server

The bullet server is an immutable file store with as principal operations read-file and create-file (For garbage collection purposes there is also a delete-file operation) When a process issues a read-file request the bullet server can transfer the entire file to the client in a single RPC unless it is larger than the maximum size (30000 bytes) in which case multiple RPCs are needed The client can then edit or otherwise modify the file locally When it is finished the client issues a create-file RPC to make a new version

The files are stored contiguously on disk and are cached in the file serverrsquos memory(currently 12 Mbytes) When a requested file is not available in this memory it is loaded from disk in a single large DMA operation and stored contiguously in the cache

In the create-file] operation one can request the reply before the file is written to disk (for speed) or afterwards (to know that it has been successfully written)

Directory server

The bullet server does not provide any naming services To access a file a process must provide the relevant capability Since working with 128-bit binary numbers is not convenient for people we have designed and implemented a directory server to manage names and capabilities

Using this capability the process can then access the file In UNIX terms when a file is opened the capability is retrieved from the directory server for use in subsequent read and write operations After the capability has been fetched from the directory server subsequent RPCs go directly to the server that manages the object The directory server is no longer involved

WIDE-AREA AMOEBA

Amoeba was designed with the idea that a collection of machines on a LAN would be able to communicate over a wide-area network with a similar collection of remote machines The key problem here is that wide-area networks are slow and unreliable and furthermore use protocols such as X25 TCPIP and OSI in any event not RPC

APPLICATIONS

Amoeba has been used to program a variety of applications In this section we will describe several of them including UNIX emulation parallel make traveling salesman and alpha-beta search

UNIX Emulation

One of the goals of Amoeba was to make it useful as a program development environment

For such an environment one needs editors compilers and numerous other standard

software It was decided that the easiest way to obtain this software was to emulate UNIX and

then to run UNIX and MINIX [25] compilers and other utilities on top of it

PERFORMANCE

1 Two user processes running on Amoeba

2 Two user processes running on Sun OS 403 but using the Amoeba primitives

3 Two user processes running on Sun OS 403 and using Sun RPC

The latter two were for comparison purposes only We ran tests for the local case (both

processes on the same machine) and for the remote case (each process on a separate machine

with communication over the Ethernet) In all cases communication was from process to process

all of which were running in user mode outside the kernel The measurments represent

the average values of 100000 trials and are highly reproducible

Memory and Process Management

Amoebarsquos memory model which is handled by the microkernel is very small and efficient A processrsquos address space contains segments mapped onto user-specified virtual addresses

These segments include but not limited to a textcode segment a data segment and a stack segment for mainthread process

When a process is executing all of its segments are in memory Amoeba does not utilize virtual memory or swapping so it can only run programs that do not exceed physical memory This does however keeps the management scheme simple and provides high performance

File System

One area of the system which we think has been eminently successful is the design of the file server and directory server We have separated out two distinct parts the bullet server which just handles storage and the directory server which handles naming and protection The bullet server design allows it to be extremely fast while the directory server design gives a flexible protection scheme and also supports file replication in a simple and easy to understand way The key element here is the fact that files are immutable so they can be replicated at will and copies regenerated if necessary

The entire replication process takes place in the background (lazy replication) and is entirely automatic thus not bothering the user at all We regard the file system as the most innovative part of the Amoeba 40 design combining high performance with reliability robustness and ease of use

Security

An intruder capable of tapping the network on which Amoeba runs can discover capabilities and do considerable damage In a production environment some form of link encryption is needed to guarantee better security Although some thought has been given to a security mechanism [26] it was not implemented in Amoeba 40

We intend to install both versions and investigate the effects on performance of the system We are researching the problems of authentication in very large systems spanning multiple organizations and national boundaries

Io scheduling

Input and output (memory disk) is handled by the microkernel threads To read a block from the disk a process does remote procedure calls to a disk IO thread in the kernel The calling process does not know that the server is actually a kernel thread because user thread interfaces are identical to kernel thread interfaces

As far as file IO goes having multiple threads within a process accentuates the distributed and parallel and computing model very well

Reasons to use Amoeba

The need to control several machines from one user process can be accomplished by a distributed operating system such as Amoeba

Another situation that could efficiently utilize a distributed system is any program that commonly requires large computations

A more practical reason to use the Amoeba operating system is to save money both by utilizing old hardware and by lessening the need topurchase expensive servers An additional reason to use Amoeba is that the source code for the operating system is available for free so you can make your own version of Amoeba to suit your needs

Reasons not to use Amoeba

Other clustered operating systems that operate in a similar fashion to Amoeba are more readily available and easier to use

This is due to the fact that the source code is available for each user to edit These reasons along with others make Amoeba a risky business venture

Conclusion

Overall the Amoeba distributed operating system is an interesting and unique idea It provides system administrators the power to distribute work over a variety of machines without inconveniencing the users Despite this and other useful features we predict that Amoeba will not ever become a widely used operating system However the knowledge gained by the development of and research about Amoeba has helped in the design of other distributed and clustered operating systems

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28

Amoeba System architecture

The hardware of an Amoeba system has three principal components all connected by a LAN

- An X-terminal or workstation running X-Windows for each user

- The processor pool (a rack of single-board computers)

- A certain number of dedicated servers (file server etc)

Each user has an X-terminal (or workstation running X-Windows) for talking to the system

Although it is technically possible to run user jobs on this machine that is not normally done as it is

the intention to have Amoeba programs use multiple processors in parallel to improve performance

The processor pool idea is based on the assumption that the ratio of processors to users is large

Processor pool model

Although using idle workstations adds a little computing power to the system it does not address a more fundamental issue

1048713What happens when it is feasible to provide 10 or 100 times as many CPUs as there are active users

1One solution as we saw is to give everyone a personal multiprocessor However this is a somewhat inefficient design

2An alternative approach is to construct aprocessor pool a rack full of CPUs in the machine room which can be dynamically allocated to users on demand

1048713Instead of giving users personal workstations in this model they are given high-performance graphics terminals

1048713Conceptually it is much closer to traditional timesharing than to the personal computer model although it is built with modem technology

Objects and capabilities

Amoeba is an object-based system The system can be viewed as a collection of objects on each of which there is a set of operations that can be performed

Associated with each object is a capability [8] a kind of ticket or key that allows the holder of the capability to perform some (not necessarily all) operations on that object A user process might

Each user process owns some collection of capabilities which together define the set of objects it may access and the type of operations he may perform on each

Thus capabilities provide a unified mechanism for naming accessing and protecting objects

From the userrsquos perspective the function of the operating system is to create an environment in which objects can be created and manipulated in a protected way

Remote procedure calls

The client has to place the capability operation code and parameters in the request buffer and on receiving the reply it has to unpack the results

The server has to check the capability extract the operation code and parameters from the request and call the appropriate procedure

Remote procedure call

The author of the handwritten stub uses several pieces

of derived information to do the job

1 The buffer is used only to receive information from the file server it is an output parameter and should not be sent to the server

2 The maximum length of the buffer is given in the nbytes parameter The actual length of

the buffer is the returned value if there is no error and zero otherwise

3 File1048713 cap is special it defines the service that must carry out the remote operation

4 The stub generator does not know what the serverrsquos operation code for read1048713 file is This

requires extra information But to be fair the human stub writer needs this extra information too

Threads

A process in Amoeba consists of one or more threads that run in parallel All the threads of a process share the same address space but each one has a dedicated portion of that address space for use as its private stack and each one has its own program counter

The RPC communication is actually between threads of a process not the process itself

The RPC creation sending receiving and decoding are all processed by the kernel There are library functions defined which give interfaces to the user program and allows for a seamless view of thread communication to the programmer

Servers

The Amoeba kernel as described above essentially handles communication and some process management and little else The kernel takes care of sending and receiving messagesscheduling processes and some low-level memory management Everything else is done by user processes

A process is created by executing the following steps

1 Get the process descriptor for the binary from the file system

2 Create a local segment or a file and initialize it to the initial environment of the new process

The environment consists of a set of named capabilities (a primitive directory as it

were) and the arguments to the process (in Unix terms argc and argv)

3 Modify the process descriptor to make the first segment the environment segment just

created

Send the process descriptor to the machine where it will be executed

Bullet server

The bullet server is an immutable file store with as principal operations read-file and create-file (For garbage collection purposes there is also a delete-file operation) When a process issues a read-file request the bullet server can transfer the entire file to the client in a single RPC unless it is larger than the maximum size (30000 bytes) in which case multiple RPCs are needed The client can then edit or otherwise modify the file locally When it is finished the client issues a create-file RPC to make a new version

The files are stored contiguously on disk and are cached in the file serverrsquos memory(currently 12 Mbytes) When a requested file is not available in this memory it is loaded from disk in a single large DMA operation and stored contiguously in the cache

In the create-file] operation one can request the reply before the file is written to disk (for speed) or afterwards (to know that it has been successfully written)

Directory server

The bullet server does not provide any naming services To access a file a process must provide the relevant capability Since working with 128-bit binary numbers is not convenient for people we have designed and implemented a directory server to manage names and capabilities

Using this capability the process can then access the file In UNIX terms when a file is opened the capability is retrieved from the directory server for use in subsequent read and write operations After the capability has been fetched from the directory server subsequent RPCs go directly to the server that manages the object The directory server is no longer involved

WIDE-AREA AMOEBA

Amoeba was designed with the idea that a collection of machines on a LAN would be able to communicate over a wide-area network with a similar collection of remote machines The key problem here is that wide-area networks are slow and unreliable and furthermore use protocols such as X25 TCPIP and OSI in any event not RPC

APPLICATIONS

Amoeba has been used to program a variety of applications In this section we will describe several of them including UNIX emulation parallel make traveling salesman and alpha-beta search

UNIX Emulation

One of the goals of Amoeba was to make it useful as a program development environment

For such an environment one needs editors compilers and numerous other standard

software It was decided that the easiest way to obtain this software was to emulate UNIX and

then to run UNIX and MINIX [25] compilers and other utilities on top of it

PERFORMANCE

1 Two user processes running on Amoeba

2 Two user processes running on Sun OS 403 but using the Amoeba primitives

3 Two user processes running on Sun OS 403 and using Sun RPC

The latter two were for comparison purposes only We ran tests for the local case (both

processes on the same machine) and for the remote case (each process on a separate machine

with communication over the Ethernet) In all cases communication was from process to process

all of which were running in user mode outside the kernel The measurments represent

the average values of 100000 trials and are highly reproducible

Memory and Process Management

Amoebarsquos memory model which is handled by the microkernel is very small and efficient A processrsquos address space contains segments mapped onto user-specified virtual addresses

These segments include but not limited to a textcode segment a data segment and a stack segment for mainthread process

When a process is executing all of its segments are in memory Amoeba does not utilize virtual memory or swapping so it can only run programs that do not exceed physical memory This does however keeps the management scheme simple and provides high performance

File System

One area of the system which we think has been eminently successful is the design of the file server and directory server We have separated out two distinct parts the bullet server which just handles storage and the directory server which handles naming and protection The bullet server design allows it to be extremely fast while the directory server design gives a flexible protection scheme and also supports file replication in a simple and easy to understand way The key element here is the fact that files are immutable so they can be replicated at will and copies regenerated if necessary

The entire replication process takes place in the background (lazy replication) and is entirely automatic thus not bothering the user at all We regard the file system as the most innovative part of the Amoeba 40 design combining high performance with reliability robustness and ease of use

Security

An intruder capable of tapping the network on which Amoeba runs can discover capabilities and do considerable damage In a production environment some form of link encryption is needed to guarantee better security Although some thought has been given to a security mechanism [26] it was not implemented in Amoeba 40

We intend to install both versions and investigate the effects on performance of the system We are researching the problems of authentication in very large systems spanning multiple organizations and national boundaries

Io scheduling

Input and output (memory disk) is handled by the microkernel threads To read a block from the disk a process does remote procedure calls to a disk IO thread in the kernel The calling process does not know that the server is actually a kernel thread because user thread interfaces are identical to kernel thread interfaces

As far as file IO goes having multiple threads within a process accentuates the distributed and parallel and computing model very well

Reasons to use Amoeba

The need to control several machines from one user process can be accomplished by a distributed operating system such as Amoeba

Another situation that could efficiently utilize a distributed system is any program that commonly requires large computations

A more practical reason to use the Amoeba operating system is to save money both by utilizing old hardware and by lessening the need topurchase expensive servers An additional reason to use Amoeba is that the source code for the operating system is available for free so you can make your own version of Amoeba to suit your needs

Reasons not to use Amoeba

Other clustered operating systems that operate in a similar fashion to Amoeba are more readily available and easier to use

This is due to the fact that the source code is available for each user to edit These reasons along with others make Amoeba a risky business venture

Conclusion

Overall the Amoeba distributed operating system is an interesting and unique idea It provides system administrators the power to distribute work over a variety of machines without inconveniencing the users Despite this and other useful features we predict that Amoeba will not ever become a widely used operating system However the knowledge gained by the development of and research about Amoeba has helped in the design of other distributed and clustered operating systems

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28

Processor pool model

Although using idle workstations adds a little computing power to the system it does not address a more fundamental issue

1048713What happens when it is feasible to provide 10 or 100 times as many CPUs as there are active users

1One solution as we saw is to give everyone a personal multiprocessor However this is a somewhat inefficient design

2An alternative approach is to construct aprocessor pool a rack full of CPUs in the machine room which can be dynamically allocated to users on demand

1048713Instead of giving users personal workstations in this model they are given high-performance graphics terminals

1048713Conceptually it is much closer to traditional timesharing than to the personal computer model although it is built with modem technology

Objects and capabilities

Amoeba is an object-based system The system can be viewed as a collection of objects on each of which there is a set of operations that can be performed

Associated with each object is a capability [8] a kind of ticket or key that allows the holder of the capability to perform some (not necessarily all) operations on that object A user process might

Each user process owns some collection of capabilities which together define the set of objects it may access and the type of operations he may perform on each

Thus capabilities provide a unified mechanism for naming accessing and protecting objects

From the userrsquos perspective the function of the operating system is to create an environment in which objects can be created and manipulated in a protected way

Remote procedure calls

The client has to place the capability operation code and parameters in the request buffer and on receiving the reply it has to unpack the results

The server has to check the capability extract the operation code and parameters from the request and call the appropriate procedure

Remote procedure call

The author of the handwritten stub uses several pieces

of derived information to do the job

1 The buffer is used only to receive information from the file server it is an output parameter and should not be sent to the server

2 The maximum length of the buffer is given in the nbytes parameter The actual length of

the buffer is the returned value if there is no error and zero otherwise

3 File1048713 cap is special it defines the service that must carry out the remote operation

4 The stub generator does not know what the serverrsquos operation code for read1048713 file is This

requires extra information But to be fair the human stub writer needs this extra information too

Threads

A process in Amoeba consists of one or more threads that run in parallel All the threads of a process share the same address space but each one has a dedicated portion of that address space for use as its private stack and each one has its own program counter

The RPC communication is actually between threads of a process not the process itself

The RPC creation sending receiving and decoding are all processed by the kernel There are library functions defined which give interfaces to the user program and allows for a seamless view of thread communication to the programmer

Servers

The Amoeba kernel as described above essentially handles communication and some process management and little else The kernel takes care of sending and receiving messagesscheduling processes and some low-level memory management Everything else is done by user processes

A process is created by executing the following steps

1 Get the process descriptor for the binary from the file system

2 Create a local segment or a file and initialize it to the initial environment of the new process

The environment consists of a set of named capabilities (a primitive directory as it

were) and the arguments to the process (in Unix terms argc and argv)

3 Modify the process descriptor to make the first segment the environment segment just

created

Send the process descriptor to the machine where it will be executed

Bullet server

The bullet server is an immutable file store with as principal operations read-file and create-file (For garbage collection purposes there is also a delete-file operation) When a process issues a read-file request the bullet server can transfer the entire file to the client in a single RPC unless it is larger than the maximum size (30000 bytes) in which case multiple RPCs are needed The client can then edit or otherwise modify the file locally When it is finished the client issues a create-file RPC to make a new version

The files are stored contiguously on disk and are cached in the file serverrsquos memory(currently 12 Mbytes) When a requested file is not available in this memory it is loaded from disk in a single large DMA operation and stored contiguously in the cache

In the create-file] operation one can request the reply before the file is written to disk (for speed) or afterwards (to know that it has been successfully written)

Directory server

The bullet server does not provide any naming services To access a file a process must provide the relevant capability Since working with 128-bit binary numbers is not convenient for people we have designed and implemented a directory server to manage names and capabilities

Using this capability the process can then access the file In UNIX terms when a file is opened the capability is retrieved from the directory server for use in subsequent read and write operations After the capability has been fetched from the directory server subsequent RPCs go directly to the server that manages the object The directory server is no longer involved

WIDE-AREA AMOEBA

Amoeba was designed with the idea that a collection of machines on a LAN would be able to communicate over a wide-area network with a similar collection of remote machines The key problem here is that wide-area networks are slow and unreliable and furthermore use protocols such as X25 TCPIP and OSI in any event not RPC

APPLICATIONS

Amoeba has been used to program a variety of applications In this section we will describe several of them including UNIX emulation parallel make traveling salesman and alpha-beta search

UNIX Emulation

One of the goals of Amoeba was to make it useful as a program development environment

For such an environment one needs editors compilers and numerous other standard

software It was decided that the easiest way to obtain this software was to emulate UNIX and

then to run UNIX and MINIX [25] compilers and other utilities on top of it

PERFORMANCE

1 Two user processes running on Amoeba

2 Two user processes running on Sun OS 403 but using the Amoeba primitives

3 Two user processes running on Sun OS 403 and using Sun RPC

The latter two were for comparison purposes only We ran tests for the local case (both

processes on the same machine) and for the remote case (each process on a separate machine

with communication over the Ethernet) In all cases communication was from process to process

all of which were running in user mode outside the kernel The measurments represent

the average values of 100000 trials and are highly reproducible

Memory and Process Management

Amoebarsquos memory model which is handled by the microkernel is very small and efficient A processrsquos address space contains segments mapped onto user-specified virtual addresses

These segments include but not limited to a textcode segment a data segment and a stack segment for mainthread process

When a process is executing all of its segments are in memory Amoeba does not utilize virtual memory or swapping so it can only run programs that do not exceed physical memory This does however keeps the management scheme simple and provides high performance

File System

One area of the system which we think has been eminently successful is the design of the file server and directory server We have separated out two distinct parts the bullet server which just handles storage and the directory server which handles naming and protection The bullet server design allows it to be extremely fast while the directory server design gives a flexible protection scheme and also supports file replication in a simple and easy to understand way The key element here is the fact that files are immutable so they can be replicated at will and copies regenerated if necessary

The entire replication process takes place in the background (lazy replication) and is entirely automatic thus not bothering the user at all We regard the file system as the most innovative part of the Amoeba 40 design combining high performance with reliability robustness and ease of use

Security

An intruder capable of tapping the network on which Amoeba runs can discover capabilities and do considerable damage In a production environment some form of link encryption is needed to guarantee better security Although some thought has been given to a security mechanism [26] it was not implemented in Amoeba 40

We intend to install both versions and investigate the effects on performance of the system We are researching the problems of authentication in very large systems spanning multiple organizations and national boundaries

Io scheduling

Input and output (memory disk) is handled by the microkernel threads To read a block from the disk a process does remote procedure calls to a disk IO thread in the kernel The calling process does not know that the server is actually a kernel thread because user thread interfaces are identical to kernel thread interfaces

As far as file IO goes having multiple threads within a process accentuates the distributed and parallel and computing model very well

Reasons to use Amoeba

The need to control several machines from one user process can be accomplished by a distributed operating system such as Amoeba

Another situation that could efficiently utilize a distributed system is any program that commonly requires large computations

A more practical reason to use the Amoeba operating system is to save money both by utilizing old hardware and by lessening the need topurchase expensive servers An additional reason to use Amoeba is that the source code for the operating system is available for free so you can make your own version of Amoeba to suit your needs

Reasons not to use Amoeba

Other clustered operating systems that operate in a similar fashion to Amoeba are more readily available and easier to use

This is due to the fact that the source code is available for each user to edit These reasons along with others make Amoeba a risky business venture

Conclusion

Overall the Amoeba distributed operating system is an interesting and unique idea It provides system administrators the power to distribute work over a variety of machines without inconveniencing the users Despite this and other useful features we predict that Amoeba will not ever become a widely used operating system However the knowledge gained by the development of and research about Amoeba has helped in the design of other distributed and clustered operating systems

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28

Objects and capabilities

Amoeba is an object-based system The system can be viewed as a collection of objects on each of which there is a set of operations that can be performed

Associated with each object is a capability [8] a kind of ticket or key that allows the holder of the capability to perform some (not necessarily all) operations on that object A user process might

Each user process owns some collection of capabilities which together define the set of objects it may access and the type of operations he may perform on each

Thus capabilities provide a unified mechanism for naming accessing and protecting objects

From the userrsquos perspective the function of the operating system is to create an environment in which objects can be created and manipulated in a protected way

Remote procedure calls

The client has to place the capability operation code and parameters in the request buffer and on receiving the reply it has to unpack the results

The server has to check the capability extract the operation code and parameters from the request and call the appropriate procedure

Remote procedure call

The author of the handwritten stub uses several pieces

of derived information to do the job

1 The buffer is used only to receive information from the file server it is an output parameter and should not be sent to the server

2 The maximum length of the buffer is given in the nbytes parameter The actual length of

the buffer is the returned value if there is no error and zero otherwise

3 File1048713 cap is special it defines the service that must carry out the remote operation

4 The stub generator does not know what the serverrsquos operation code for read1048713 file is This

requires extra information But to be fair the human stub writer needs this extra information too

Threads

A process in Amoeba consists of one or more threads that run in parallel All the threads of a process share the same address space but each one has a dedicated portion of that address space for use as its private stack and each one has its own program counter

The RPC communication is actually between threads of a process not the process itself

The RPC creation sending receiving and decoding are all processed by the kernel There are library functions defined which give interfaces to the user program and allows for a seamless view of thread communication to the programmer

Servers

The Amoeba kernel as described above essentially handles communication and some process management and little else The kernel takes care of sending and receiving messagesscheduling processes and some low-level memory management Everything else is done by user processes

A process is created by executing the following steps

1 Get the process descriptor for the binary from the file system

2 Create a local segment or a file and initialize it to the initial environment of the new process

The environment consists of a set of named capabilities (a primitive directory as it

were) and the arguments to the process (in Unix terms argc and argv)

3 Modify the process descriptor to make the first segment the environment segment just

created

Send the process descriptor to the machine where it will be executed

Bullet server

The bullet server is an immutable file store with as principal operations read-file and create-file (For garbage collection purposes there is also a delete-file operation) When a process issues a read-file request the bullet server can transfer the entire file to the client in a single RPC unless it is larger than the maximum size (30000 bytes) in which case multiple RPCs are needed The client can then edit or otherwise modify the file locally When it is finished the client issues a create-file RPC to make a new version

The files are stored contiguously on disk and are cached in the file serverrsquos memory(currently 12 Mbytes) When a requested file is not available in this memory it is loaded from disk in a single large DMA operation and stored contiguously in the cache

In the create-file] operation one can request the reply before the file is written to disk (for speed) or afterwards (to know that it has been successfully written)

Directory server

The bullet server does not provide any naming services To access a file a process must provide the relevant capability Since working with 128-bit binary numbers is not convenient for people we have designed and implemented a directory server to manage names and capabilities

Using this capability the process can then access the file In UNIX terms when a file is opened the capability is retrieved from the directory server for use in subsequent read and write operations After the capability has been fetched from the directory server subsequent RPCs go directly to the server that manages the object The directory server is no longer involved

WIDE-AREA AMOEBA

Amoeba was designed with the idea that a collection of machines on a LAN would be able to communicate over a wide-area network with a similar collection of remote machines The key problem here is that wide-area networks are slow and unreliable and furthermore use protocols such as X25 TCPIP and OSI in any event not RPC

APPLICATIONS

Amoeba has been used to program a variety of applications In this section we will describe several of them including UNIX emulation parallel make traveling salesman and alpha-beta search

UNIX Emulation

One of the goals of Amoeba was to make it useful as a program development environment

For such an environment one needs editors compilers and numerous other standard

software It was decided that the easiest way to obtain this software was to emulate UNIX and

then to run UNIX and MINIX [25] compilers and other utilities on top of it

PERFORMANCE

1 Two user processes running on Amoeba

2 Two user processes running on Sun OS 403 but using the Amoeba primitives

3 Two user processes running on Sun OS 403 and using Sun RPC

The latter two were for comparison purposes only We ran tests for the local case (both

processes on the same machine) and for the remote case (each process on a separate machine

with communication over the Ethernet) In all cases communication was from process to process

all of which were running in user mode outside the kernel The measurments represent

the average values of 100000 trials and are highly reproducible

Memory and Process Management

Amoebarsquos memory model which is handled by the microkernel is very small and efficient A processrsquos address space contains segments mapped onto user-specified virtual addresses

These segments include but not limited to a textcode segment a data segment and a stack segment for mainthread process

When a process is executing all of its segments are in memory Amoeba does not utilize virtual memory or swapping so it can only run programs that do not exceed physical memory This does however keeps the management scheme simple and provides high performance

File System

One area of the system which we think has been eminently successful is the design of the file server and directory server We have separated out two distinct parts the bullet server which just handles storage and the directory server which handles naming and protection The bullet server design allows it to be extremely fast while the directory server design gives a flexible protection scheme and also supports file replication in a simple and easy to understand way The key element here is the fact that files are immutable so they can be replicated at will and copies regenerated if necessary

The entire replication process takes place in the background (lazy replication) and is entirely automatic thus not bothering the user at all We regard the file system as the most innovative part of the Amoeba 40 design combining high performance with reliability robustness and ease of use

Security

An intruder capable of tapping the network on which Amoeba runs can discover capabilities and do considerable damage In a production environment some form of link encryption is needed to guarantee better security Although some thought has been given to a security mechanism [26] it was not implemented in Amoeba 40

We intend to install both versions and investigate the effects on performance of the system We are researching the problems of authentication in very large systems spanning multiple organizations and national boundaries

Io scheduling

Input and output (memory disk) is handled by the microkernel threads To read a block from the disk a process does remote procedure calls to a disk IO thread in the kernel The calling process does not know that the server is actually a kernel thread because user thread interfaces are identical to kernel thread interfaces

As far as file IO goes having multiple threads within a process accentuates the distributed and parallel and computing model very well

Reasons to use Amoeba

The need to control several machines from one user process can be accomplished by a distributed operating system such as Amoeba

Another situation that could efficiently utilize a distributed system is any program that commonly requires large computations

A more practical reason to use the Amoeba operating system is to save money both by utilizing old hardware and by lessening the need topurchase expensive servers An additional reason to use Amoeba is that the source code for the operating system is available for free so you can make your own version of Amoeba to suit your needs

Reasons not to use Amoeba

Other clustered operating systems that operate in a similar fashion to Amoeba are more readily available and easier to use

This is due to the fact that the source code is available for each user to edit These reasons along with others make Amoeba a risky business venture

Conclusion

Overall the Amoeba distributed operating system is an interesting and unique idea It provides system administrators the power to distribute work over a variety of machines without inconveniencing the users Despite this and other useful features we predict that Amoeba will not ever become a widely used operating system However the knowledge gained by the development of and research about Amoeba has helped in the design of other distributed and clustered operating systems

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28

Remote procedure calls

The client has to place the capability operation code and parameters in the request buffer and on receiving the reply it has to unpack the results

The server has to check the capability extract the operation code and parameters from the request and call the appropriate procedure

Remote procedure call

The author of the handwritten stub uses several pieces

of derived information to do the job

1 The buffer is used only to receive information from the file server it is an output parameter and should not be sent to the server

2 The maximum length of the buffer is given in the nbytes parameter The actual length of

the buffer is the returned value if there is no error and zero otherwise

3 File1048713 cap is special it defines the service that must carry out the remote operation

4 The stub generator does not know what the serverrsquos operation code for read1048713 file is This

requires extra information But to be fair the human stub writer needs this extra information too

Threads

A process in Amoeba consists of one or more threads that run in parallel All the threads of a process share the same address space but each one has a dedicated portion of that address space for use as its private stack and each one has its own program counter

The RPC communication is actually between threads of a process not the process itself

The RPC creation sending receiving and decoding are all processed by the kernel There are library functions defined which give interfaces to the user program and allows for a seamless view of thread communication to the programmer

Servers

The Amoeba kernel as described above essentially handles communication and some process management and little else The kernel takes care of sending and receiving messagesscheduling processes and some low-level memory management Everything else is done by user processes

A process is created by executing the following steps

1 Get the process descriptor for the binary from the file system

2 Create a local segment or a file and initialize it to the initial environment of the new process

The environment consists of a set of named capabilities (a primitive directory as it

were) and the arguments to the process (in Unix terms argc and argv)

3 Modify the process descriptor to make the first segment the environment segment just

created

Send the process descriptor to the machine where it will be executed

Bullet server

The bullet server is an immutable file store with as principal operations read-file and create-file (For garbage collection purposes there is also a delete-file operation) When a process issues a read-file request the bullet server can transfer the entire file to the client in a single RPC unless it is larger than the maximum size (30000 bytes) in which case multiple RPCs are needed The client can then edit or otherwise modify the file locally When it is finished the client issues a create-file RPC to make a new version

The files are stored contiguously on disk and are cached in the file serverrsquos memory(currently 12 Mbytes) When a requested file is not available in this memory it is loaded from disk in a single large DMA operation and stored contiguously in the cache

In the create-file] operation one can request the reply before the file is written to disk (for speed) or afterwards (to know that it has been successfully written)

Directory server

The bullet server does not provide any naming services To access a file a process must provide the relevant capability Since working with 128-bit binary numbers is not convenient for people we have designed and implemented a directory server to manage names and capabilities

Using this capability the process can then access the file In UNIX terms when a file is opened the capability is retrieved from the directory server for use in subsequent read and write operations After the capability has been fetched from the directory server subsequent RPCs go directly to the server that manages the object The directory server is no longer involved

WIDE-AREA AMOEBA

Amoeba was designed with the idea that a collection of machines on a LAN would be able to communicate over a wide-area network with a similar collection of remote machines The key problem here is that wide-area networks are slow and unreliable and furthermore use protocols such as X25 TCPIP and OSI in any event not RPC

APPLICATIONS

Amoeba has been used to program a variety of applications In this section we will describe several of them including UNIX emulation parallel make traveling salesman and alpha-beta search

UNIX Emulation

One of the goals of Amoeba was to make it useful as a program development environment

For such an environment one needs editors compilers and numerous other standard

software It was decided that the easiest way to obtain this software was to emulate UNIX and

then to run UNIX and MINIX [25] compilers and other utilities on top of it

PERFORMANCE

1 Two user processes running on Amoeba

2 Two user processes running on Sun OS 403 but using the Amoeba primitives

3 Two user processes running on Sun OS 403 and using Sun RPC

The latter two were for comparison purposes only We ran tests for the local case (both

processes on the same machine) and for the remote case (each process on a separate machine

with communication over the Ethernet) In all cases communication was from process to process

all of which were running in user mode outside the kernel The measurments represent

the average values of 100000 trials and are highly reproducible

Memory and Process Management

Amoebarsquos memory model which is handled by the microkernel is very small and efficient A processrsquos address space contains segments mapped onto user-specified virtual addresses

These segments include but not limited to a textcode segment a data segment and a stack segment for mainthread process

When a process is executing all of its segments are in memory Amoeba does not utilize virtual memory or swapping so it can only run programs that do not exceed physical memory This does however keeps the management scheme simple and provides high performance

File System

One area of the system which we think has been eminently successful is the design of the file server and directory server We have separated out two distinct parts the bullet server which just handles storage and the directory server which handles naming and protection The bullet server design allows it to be extremely fast while the directory server design gives a flexible protection scheme and also supports file replication in a simple and easy to understand way The key element here is the fact that files are immutable so they can be replicated at will and copies regenerated if necessary

The entire replication process takes place in the background (lazy replication) and is entirely automatic thus not bothering the user at all We regard the file system as the most innovative part of the Amoeba 40 design combining high performance with reliability robustness and ease of use

Security

An intruder capable of tapping the network on which Amoeba runs can discover capabilities and do considerable damage In a production environment some form of link encryption is needed to guarantee better security Although some thought has been given to a security mechanism [26] it was not implemented in Amoeba 40

We intend to install both versions and investigate the effects on performance of the system We are researching the problems of authentication in very large systems spanning multiple organizations and national boundaries

Io scheduling

Input and output (memory disk) is handled by the microkernel threads To read a block from the disk a process does remote procedure calls to a disk IO thread in the kernel The calling process does not know that the server is actually a kernel thread because user thread interfaces are identical to kernel thread interfaces

As far as file IO goes having multiple threads within a process accentuates the distributed and parallel and computing model very well

Reasons to use Amoeba

The need to control several machines from one user process can be accomplished by a distributed operating system such as Amoeba

Another situation that could efficiently utilize a distributed system is any program that commonly requires large computations

A more practical reason to use the Amoeba operating system is to save money both by utilizing old hardware and by lessening the need topurchase expensive servers An additional reason to use Amoeba is that the source code for the operating system is available for free so you can make your own version of Amoeba to suit your needs

Reasons not to use Amoeba

Other clustered operating systems that operate in a similar fashion to Amoeba are more readily available and easier to use

This is due to the fact that the source code is available for each user to edit These reasons along with others make Amoeba a risky business venture

Conclusion

Overall the Amoeba distributed operating system is an interesting and unique idea It provides system administrators the power to distribute work over a variety of machines without inconveniencing the users Despite this and other useful features we predict that Amoeba will not ever become a widely used operating system However the knowledge gained by the development of and research about Amoeba has helped in the design of other distributed and clustered operating systems

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28

Remote procedure call

The author of the handwritten stub uses several pieces

of derived information to do the job

1 The buffer is used only to receive information from the file server it is an output parameter and should not be sent to the server

2 The maximum length of the buffer is given in the nbytes parameter The actual length of

the buffer is the returned value if there is no error and zero otherwise

3 File1048713 cap is special it defines the service that must carry out the remote operation

4 The stub generator does not know what the serverrsquos operation code for read1048713 file is This

requires extra information But to be fair the human stub writer needs this extra information too

Threads

A process in Amoeba consists of one or more threads that run in parallel All the threads of a process share the same address space but each one has a dedicated portion of that address space for use as its private stack and each one has its own program counter

The RPC communication is actually between threads of a process not the process itself

The RPC creation sending receiving and decoding are all processed by the kernel There are library functions defined which give interfaces to the user program and allows for a seamless view of thread communication to the programmer

Servers

The Amoeba kernel as described above essentially handles communication and some process management and little else The kernel takes care of sending and receiving messagesscheduling processes and some low-level memory management Everything else is done by user processes

A process is created by executing the following steps

1 Get the process descriptor for the binary from the file system

2 Create a local segment or a file and initialize it to the initial environment of the new process

The environment consists of a set of named capabilities (a primitive directory as it

were) and the arguments to the process (in Unix terms argc and argv)

3 Modify the process descriptor to make the first segment the environment segment just

created

Send the process descriptor to the machine where it will be executed

Bullet server

The bullet server is an immutable file store with as principal operations read-file and create-file (For garbage collection purposes there is also a delete-file operation) When a process issues a read-file request the bullet server can transfer the entire file to the client in a single RPC unless it is larger than the maximum size (30000 bytes) in which case multiple RPCs are needed The client can then edit or otherwise modify the file locally When it is finished the client issues a create-file RPC to make a new version

The files are stored contiguously on disk and are cached in the file serverrsquos memory(currently 12 Mbytes) When a requested file is not available in this memory it is loaded from disk in a single large DMA operation and stored contiguously in the cache

In the create-file] operation one can request the reply before the file is written to disk (for speed) or afterwards (to know that it has been successfully written)

Directory server

The bullet server does not provide any naming services To access a file a process must provide the relevant capability Since working with 128-bit binary numbers is not convenient for people we have designed and implemented a directory server to manage names and capabilities

Using this capability the process can then access the file In UNIX terms when a file is opened the capability is retrieved from the directory server for use in subsequent read and write operations After the capability has been fetched from the directory server subsequent RPCs go directly to the server that manages the object The directory server is no longer involved

WIDE-AREA AMOEBA

Amoeba was designed with the idea that a collection of machines on a LAN would be able to communicate over a wide-area network with a similar collection of remote machines The key problem here is that wide-area networks are slow and unreliable and furthermore use protocols such as X25 TCPIP and OSI in any event not RPC

APPLICATIONS

Amoeba has been used to program a variety of applications In this section we will describe several of them including UNIX emulation parallel make traveling salesman and alpha-beta search

UNIX Emulation

One of the goals of Amoeba was to make it useful as a program development environment

For such an environment one needs editors compilers and numerous other standard

software It was decided that the easiest way to obtain this software was to emulate UNIX and

then to run UNIX and MINIX [25] compilers and other utilities on top of it

PERFORMANCE

1 Two user processes running on Amoeba

2 Two user processes running on Sun OS 403 but using the Amoeba primitives

3 Two user processes running on Sun OS 403 and using Sun RPC

The latter two were for comparison purposes only We ran tests for the local case (both

processes on the same machine) and for the remote case (each process on a separate machine

with communication over the Ethernet) In all cases communication was from process to process

all of which were running in user mode outside the kernel The measurments represent

the average values of 100000 trials and are highly reproducible

Memory and Process Management

Amoebarsquos memory model which is handled by the microkernel is very small and efficient A processrsquos address space contains segments mapped onto user-specified virtual addresses

These segments include but not limited to a textcode segment a data segment and a stack segment for mainthread process

When a process is executing all of its segments are in memory Amoeba does not utilize virtual memory or swapping so it can only run programs that do not exceed physical memory This does however keeps the management scheme simple and provides high performance

File System

One area of the system which we think has been eminently successful is the design of the file server and directory server We have separated out two distinct parts the bullet server which just handles storage and the directory server which handles naming and protection The bullet server design allows it to be extremely fast while the directory server design gives a flexible protection scheme and also supports file replication in a simple and easy to understand way The key element here is the fact that files are immutable so they can be replicated at will and copies regenerated if necessary

The entire replication process takes place in the background (lazy replication) and is entirely automatic thus not bothering the user at all We regard the file system as the most innovative part of the Amoeba 40 design combining high performance with reliability robustness and ease of use

Security

An intruder capable of tapping the network on which Amoeba runs can discover capabilities and do considerable damage In a production environment some form of link encryption is needed to guarantee better security Although some thought has been given to a security mechanism [26] it was not implemented in Amoeba 40

We intend to install both versions and investigate the effects on performance of the system We are researching the problems of authentication in very large systems spanning multiple organizations and national boundaries

Io scheduling

Input and output (memory disk) is handled by the microkernel threads To read a block from the disk a process does remote procedure calls to a disk IO thread in the kernel The calling process does not know that the server is actually a kernel thread because user thread interfaces are identical to kernel thread interfaces

As far as file IO goes having multiple threads within a process accentuates the distributed and parallel and computing model very well

Reasons to use Amoeba

The need to control several machines from one user process can be accomplished by a distributed operating system such as Amoeba

Another situation that could efficiently utilize a distributed system is any program that commonly requires large computations

A more practical reason to use the Amoeba operating system is to save money both by utilizing old hardware and by lessening the need topurchase expensive servers An additional reason to use Amoeba is that the source code for the operating system is available for free so you can make your own version of Amoeba to suit your needs

Reasons not to use Amoeba

Other clustered operating systems that operate in a similar fashion to Amoeba are more readily available and easier to use

This is due to the fact that the source code is available for each user to edit These reasons along with others make Amoeba a risky business venture

Conclusion

Overall the Amoeba distributed operating system is an interesting and unique idea It provides system administrators the power to distribute work over a variety of machines without inconveniencing the users Despite this and other useful features we predict that Amoeba will not ever become a widely used operating system However the knowledge gained by the development of and research about Amoeba has helped in the design of other distributed and clustered operating systems

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28

Threads

A process in Amoeba consists of one or more threads that run in parallel All the threads of a process share the same address space but each one has a dedicated portion of that address space for use as its private stack and each one has its own program counter

The RPC communication is actually between threads of a process not the process itself

The RPC creation sending receiving and decoding are all processed by the kernel There are library functions defined which give interfaces to the user program and allows for a seamless view of thread communication to the programmer

Servers

The Amoeba kernel as described above essentially handles communication and some process management and little else The kernel takes care of sending and receiving messagesscheduling processes and some low-level memory management Everything else is done by user processes

A process is created by executing the following steps

1 Get the process descriptor for the binary from the file system

2 Create a local segment or a file and initialize it to the initial environment of the new process

The environment consists of a set of named capabilities (a primitive directory as it

were) and the arguments to the process (in Unix terms argc and argv)

3 Modify the process descriptor to make the first segment the environment segment just

created

Send the process descriptor to the machine where it will be executed

Bullet server

The bullet server is an immutable file store with as principal operations read-file and create-file (For garbage collection purposes there is also a delete-file operation) When a process issues a read-file request the bullet server can transfer the entire file to the client in a single RPC unless it is larger than the maximum size (30000 bytes) in which case multiple RPCs are needed The client can then edit or otherwise modify the file locally When it is finished the client issues a create-file RPC to make a new version

The files are stored contiguously on disk and are cached in the file serverrsquos memory(currently 12 Mbytes) When a requested file is not available in this memory it is loaded from disk in a single large DMA operation and stored contiguously in the cache

In the create-file] operation one can request the reply before the file is written to disk (for speed) or afterwards (to know that it has been successfully written)

Directory server

The bullet server does not provide any naming services To access a file a process must provide the relevant capability Since working with 128-bit binary numbers is not convenient for people we have designed and implemented a directory server to manage names and capabilities

Using this capability the process can then access the file In UNIX terms when a file is opened the capability is retrieved from the directory server for use in subsequent read and write operations After the capability has been fetched from the directory server subsequent RPCs go directly to the server that manages the object The directory server is no longer involved

WIDE-AREA AMOEBA

Amoeba was designed with the idea that a collection of machines on a LAN would be able to communicate over a wide-area network with a similar collection of remote machines The key problem here is that wide-area networks are slow and unreliable and furthermore use protocols such as X25 TCPIP and OSI in any event not RPC

APPLICATIONS

Amoeba has been used to program a variety of applications In this section we will describe several of them including UNIX emulation parallel make traveling salesman and alpha-beta search

UNIX Emulation

One of the goals of Amoeba was to make it useful as a program development environment

For such an environment one needs editors compilers and numerous other standard

software It was decided that the easiest way to obtain this software was to emulate UNIX and

then to run UNIX and MINIX [25] compilers and other utilities on top of it

PERFORMANCE

1 Two user processes running on Amoeba

2 Two user processes running on Sun OS 403 but using the Amoeba primitives

3 Two user processes running on Sun OS 403 and using Sun RPC

The latter two were for comparison purposes only We ran tests for the local case (both

processes on the same machine) and for the remote case (each process on a separate machine

with communication over the Ethernet) In all cases communication was from process to process

all of which were running in user mode outside the kernel The measurments represent

the average values of 100000 trials and are highly reproducible

Memory and Process Management

Amoebarsquos memory model which is handled by the microkernel is very small and efficient A processrsquos address space contains segments mapped onto user-specified virtual addresses

These segments include but not limited to a textcode segment a data segment and a stack segment for mainthread process

When a process is executing all of its segments are in memory Amoeba does not utilize virtual memory or swapping so it can only run programs that do not exceed physical memory This does however keeps the management scheme simple and provides high performance

File System

One area of the system which we think has been eminently successful is the design of the file server and directory server We have separated out two distinct parts the bullet server which just handles storage and the directory server which handles naming and protection The bullet server design allows it to be extremely fast while the directory server design gives a flexible protection scheme and also supports file replication in a simple and easy to understand way The key element here is the fact that files are immutable so they can be replicated at will and copies regenerated if necessary

The entire replication process takes place in the background (lazy replication) and is entirely automatic thus not bothering the user at all We regard the file system as the most innovative part of the Amoeba 40 design combining high performance with reliability robustness and ease of use

Security

An intruder capable of tapping the network on which Amoeba runs can discover capabilities and do considerable damage In a production environment some form of link encryption is needed to guarantee better security Although some thought has been given to a security mechanism [26] it was not implemented in Amoeba 40

We intend to install both versions and investigate the effects on performance of the system We are researching the problems of authentication in very large systems spanning multiple organizations and national boundaries

Io scheduling

Input and output (memory disk) is handled by the microkernel threads To read a block from the disk a process does remote procedure calls to a disk IO thread in the kernel The calling process does not know that the server is actually a kernel thread because user thread interfaces are identical to kernel thread interfaces

As far as file IO goes having multiple threads within a process accentuates the distributed and parallel and computing model very well

Reasons to use Amoeba

The need to control several machines from one user process can be accomplished by a distributed operating system such as Amoeba

Another situation that could efficiently utilize a distributed system is any program that commonly requires large computations

A more practical reason to use the Amoeba operating system is to save money both by utilizing old hardware and by lessening the need topurchase expensive servers An additional reason to use Amoeba is that the source code for the operating system is available for free so you can make your own version of Amoeba to suit your needs

Reasons not to use Amoeba

Other clustered operating systems that operate in a similar fashion to Amoeba are more readily available and easier to use

This is due to the fact that the source code is available for each user to edit These reasons along with others make Amoeba a risky business venture

Conclusion

Overall the Amoeba distributed operating system is an interesting and unique idea It provides system administrators the power to distribute work over a variety of machines without inconveniencing the users Despite this and other useful features we predict that Amoeba will not ever become a widely used operating system However the knowledge gained by the development of and research about Amoeba has helped in the design of other distributed and clustered operating systems

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28

Servers

The Amoeba kernel as described above essentially handles communication and some process management and little else The kernel takes care of sending and receiving messagesscheduling processes and some low-level memory management Everything else is done by user processes

A process is created by executing the following steps

1 Get the process descriptor for the binary from the file system

2 Create a local segment or a file and initialize it to the initial environment of the new process

The environment consists of a set of named capabilities (a primitive directory as it

were) and the arguments to the process (in Unix terms argc and argv)

3 Modify the process descriptor to make the first segment the environment segment just

created

Send the process descriptor to the machine where it will be executed

Bullet server

The bullet server is an immutable file store with as principal operations read-file and create-file (For garbage collection purposes there is also a delete-file operation) When a process issues a read-file request the bullet server can transfer the entire file to the client in a single RPC unless it is larger than the maximum size (30000 bytes) in which case multiple RPCs are needed The client can then edit or otherwise modify the file locally When it is finished the client issues a create-file RPC to make a new version

The files are stored contiguously on disk and are cached in the file serverrsquos memory(currently 12 Mbytes) When a requested file is not available in this memory it is loaded from disk in a single large DMA operation and stored contiguously in the cache

In the create-file] operation one can request the reply before the file is written to disk (for speed) or afterwards (to know that it has been successfully written)

Directory server

The bullet server does not provide any naming services To access a file a process must provide the relevant capability Since working with 128-bit binary numbers is not convenient for people we have designed and implemented a directory server to manage names and capabilities

Using this capability the process can then access the file In UNIX terms when a file is opened the capability is retrieved from the directory server for use in subsequent read and write operations After the capability has been fetched from the directory server subsequent RPCs go directly to the server that manages the object The directory server is no longer involved

WIDE-AREA AMOEBA

Amoeba was designed with the idea that a collection of machines on a LAN would be able to communicate over a wide-area network with a similar collection of remote machines The key problem here is that wide-area networks are slow and unreliable and furthermore use protocols such as X25 TCPIP and OSI in any event not RPC

APPLICATIONS

Amoeba has been used to program a variety of applications In this section we will describe several of them including UNIX emulation parallel make traveling salesman and alpha-beta search

UNIX Emulation

One of the goals of Amoeba was to make it useful as a program development environment

For such an environment one needs editors compilers and numerous other standard

software It was decided that the easiest way to obtain this software was to emulate UNIX and

then to run UNIX and MINIX [25] compilers and other utilities on top of it

PERFORMANCE

1 Two user processes running on Amoeba

2 Two user processes running on Sun OS 403 but using the Amoeba primitives

3 Two user processes running on Sun OS 403 and using Sun RPC

The latter two were for comparison purposes only We ran tests for the local case (both

processes on the same machine) and for the remote case (each process on a separate machine

with communication over the Ethernet) In all cases communication was from process to process

all of which were running in user mode outside the kernel The measurments represent

the average values of 100000 trials and are highly reproducible

Memory and Process Management

Amoebarsquos memory model which is handled by the microkernel is very small and efficient A processrsquos address space contains segments mapped onto user-specified virtual addresses

These segments include but not limited to a textcode segment a data segment and a stack segment for mainthread process

When a process is executing all of its segments are in memory Amoeba does not utilize virtual memory or swapping so it can only run programs that do not exceed physical memory This does however keeps the management scheme simple and provides high performance

File System

One area of the system which we think has been eminently successful is the design of the file server and directory server We have separated out two distinct parts the bullet server which just handles storage and the directory server which handles naming and protection The bullet server design allows it to be extremely fast while the directory server design gives a flexible protection scheme and also supports file replication in a simple and easy to understand way The key element here is the fact that files are immutable so they can be replicated at will and copies regenerated if necessary

The entire replication process takes place in the background (lazy replication) and is entirely automatic thus not bothering the user at all We regard the file system as the most innovative part of the Amoeba 40 design combining high performance with reliability robustness and ease of use

Security

An intruder capable of tapping the network on which Amoeba runs can discover capabilities and do considerable damage In a production environment some form of link encryption is needed to guarantee better security Although some thought has been given to a security mechanism [26] it was not implemented in Amoeba 40

We intend to install both versions and investigate the effects on performance of the system We are researching the problems of authentication in very large systems spanning multiple organizations and national boundaries

Io scheduling

Input and output (memory disk) is handled by the microkernel threads To read a block from the disk a process does remote procedure calls to a disk IO thread in the kernel The calling process does not know that the server is actually a kernel thread because user thread interfaces are identical to kernel thread interfaces

As far as file IO goes having multiple threads within a process accentuates the distributed and parallel and computing model very well

Reasons to use Amoeba

The need to control several machines from one user process can be accomplished by a distributed operating system such as Amoeba

Another situation that could efficiently utilize a distributed system is any program that commonly requires large computations

A more practical reason to use the Amoeba operating system is to save money both by utilizing old hardware and by lessening the need topurchase expensive servers An additional reason to use Amoeba is that the source code for the operating system is available for free so you can make your own version of Amoeba to suit your needs

Reasons not to use Amoeba

Other clustered operating systems that operate in a similar fashion to Amoeba are more readily available and easier to use

This is due to the fact that the source code is available for each user to edit These reasons along with others make Amoeba a risky business venture

Conclusion

Overall the Amoeba distributed operating system is an interesting and unique idea It provides system administrators the power to distribute work over a variety of machines without inconveniencing the users Despite this and other useful features we predict that Amoeba will not ever become a widely used operating system However the knowledge gained by the development of and research about Amoeba has helped in the design of other distributed and clustered operating systems

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28

Bullet server

The bullet server is an immutable file store with as principal operations read-file and create-file (For garbage collection purposes there is also a delete-file operation) When a process issues a read-file request the bullet server can transfer the entire file to the client in a single RPC unless it is larger than the maximum size (30000 bytes) in which case multiple RPCs are needed The client can then edit or otherwise modify the file locally When it is finished the client issues a create-file RPC to make a new version

The files are stored contiguously on disk and are cached in the file serverrsquos memory(currently 12 Mbytes) When a requested file is not available in this memory it is loaded from disk in a single large DMA operation and stored contiguously in the cache

In the create-file] operation one can request the reply before the file is written to disk (for speed) or afterwards (to know that it has been successfully written)

Directory server

The bullet server does not provide any naming services To access a file a process must provide the relevant capability Since working with 128-bit binary numbers is not convenient for people we have designed and implemented a directory server to manage names and capabilities

Using this capability the process can then access the file In UNIX terms when a file is opened the capability is retrieved from the directory server for use in subsequent read and write operations After the capability has been fetched from the directory server subsequent RPCs go directly to the server that manages the object The directory server is no longer involved

WIDE-AREA AMOEBA

Amoeba was designed with the idea that a collection of machines on a LAN would be able to communicate over a wide-area network with a similar collection of remote machines The key problem here is that wide-area networks are slow and unreliable and furthermore use protocols such as X25 TCPIP and OSI in any event not RPC

APPLICATIONS

Amoeba has been used to program a variety of applications In this section we will describe several of them including UNIX emulation parallel make traveling salesman and alpha-beta search

UNIX Emulation

One of the goals of Amoeba was to make it useful as a program development environment

For such an environment one needs editors compilers and numerous other standard

software It was decided that the easiest way to obtain this software was to emulate UNIX and

then to run UNIX and MINIX [25] compilers and other utilities on top of it

PERFORMANCE

1 Two user processes running on Amoeba

2 Two user processes running on Sun OS 403 but using the Amoeba primitives

3 Two user processes running on Sun OS 403 and using Sun RPC

The latter two were for comparison purposes only We ran tests for the local case (both

processes on the same machine) and for the remote case (each process on a separate machine

with communication over the Ethernet) In all cases communication was from process to process

all of which were running in user mode outside the kernel The measurments represent

the average values of 100000 trials and are highly reproducible

Memory and Process Management

Amoebarsquos memory model which is handled by the microkernel is very small and efficient A processrsquos address space contains segments mapped onto user-specified virtual addresses

These segments include but not limited to a textcode segment a data segment and a stack segment for mainthread process

When a process is executing all of its segments are in memory Amoeba does not utilize virtual memory or swapping so it can only run programs that do not exceed physical memory This does however keeps the management scheme simple and provides high performance

File System

One area of the system which we think has been eminently successful is the design of the file server and directory server We have separated out two distinct parts the bullet server which just handles storage and the directory server which handles naming and protection The bullet server design allows it to be extremely fast while the directory server design gives a flexible protection scheme and also supports file replication in a simple and easy to understand way The key element here is the fact that files are immutable so they can be replicated at will and copies regenerated if necessary

The entire replication process takes place in the background (lazy replication) and is entirely automatic thus not bothering the user at all We regard the file system as the most innovative part of the Amoeba 40 design combining high performance with reliability robustness and ease of use

Security

An intruder capable of tapping the network on which Amoeba runs can discover capabilities and do considerable damage In a production environment some form of link encryption is needed to guarantee better security Although some thought has been given to a security mechanism [26] it was not implemented in Amoeba 40

We intend to install both versions and investigate the effects on performance of the system We are researching the problems of authentication in very large systems spanning multiple organizations and national boundaries

Io scheduling

Input and output (memory disk) is handled by the microkernel threads To read a block from the disk a process does remote procedure calls to a disk IO thread in the kernel The calling process does not know that the server is actually a kernel thread because user thread interfaces are identical to kernel thread interfaces

As far as file IO goes having multiple threads within a process accentuates the distributed and parallel and computing model very well

Reasons to use Amoeba

The need to control several machines from one user process can be accomplished by a distributed operating system such as Amoeba

Another situation that could efficiently utilize a distributed system is any program that commonly requires large computations

A more practical reason to use the Amoeba operating system is to save money both by utilizing old hardware and by lessening the need topurchase expensive servers An additional reason to use Amoeba is that the source code for the operating system is available for free so you can make your own version of Amoeba to suit your needs

Reasons not to use Amoeba

Other clustered operating systems that operate in a similar fashion to Amoeba are more readily available and easier to use

This is due to the fact that the source code is available for each user to edit These reasons along with others make Amoeba a risky business venture

Conclusion

Overall the Amoeba distributed operating system is an interesting and unique idea It provides system administrators the power to distribute work over a variety of machines without inconveniencing the users Despite this and other useful features we predict that Amoeba will not ever become a widely used operating system However the knowledge gained by the development of and research about Amoeba has helped in the design of other distributed and clustered operating systems

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28

Directory server

The bullet server does not provide any naming services To access a file a process must provide the relevant capability Since working with 128-bit binary numbers is not convenient for people we have designed and implemented a directory server to manage names and capabilities

Using this capability the process can then access the file In UNIX terms when a file is opened the capability is retrieved from the directory server for use in subsequent read and write operations After the capability has been fetched from the directory server subsequent RPCs go directly to the server that manages the object The directory server is no longer involved

WIDE-AREA AMOEBA

Amoeba was designed with the idea that a collection of machines on a LAN would be able to communicate over a wide-area network with a similar collection of remote machines The key problem here is that wide-area networks are slow and unreliable and furthermore use protocols such as X25 TCPIP and OSI in any event not RPC

APPLICATIONS

Amoeba has been used to program a variety of applications In this section we will describe several of them including UNIX emulation parallel make traveling salesman and alpha-beta search

UNIX Emulation

One of the goals of Amoeba was to make it useful as a program development environment

For such an environment one needs editors compilers and numerous other standard

software It was decided that the easiest way to obtain this software was to emulate UNIX and

then to run UNIX and MINIX [25] compilers and other utilities on top of it

PERFORMANCE

1 Two user processes running on Amoeba

2 Two user processes running on Sun OS 403 but using the Amoeba primitives

3 Two user processes running on Sun OS 403 and using Sun RPC

The latter two were for comparison purposes only We ran tests for the local case (both

processes on the same machine) and for the remote case (each process on a separate machine

with communication over the Ethernet) In all cases communication was from process to process

all of which were running in user mode outside the kernel The measurments represent

the average values of 100000 trials and are highly reproducible

Memory and Process Management

Amoebarsquos memory model which is handled by the microkernel is very small and efficient A processrsquos address space contains segments mapped onto user-specified virtual addresses

These segments include but not limited to a textcode segment a data segment and a stack segment for mainthread process

When a process is executing all of its segments are in memory Amoeba does not utilize virtual memory or swapping so it can only run programs that do not exceed physical memory This does however keeps the management scheme simple and provides high performance

File System

One area of the system which we think has been eminently successful is the design of the file server and directory server We have separated out two distinct parts the bullet server which just handles storage and the directory server which handles naming and protection The bullet server design allows it to be extremely fast while the directory server design gives a flexible protection scheme and also supports file replication in a simple and easy to understand way The key element here is the fact that files are immutable so they can be replicated at will and copies regenerated if necessary

The entire replication process takes place in the background (lazy replication) and is entirely automatic thus not bothering the user at all We regard the file system as the most innovative part of the Amoeba 40 design combining high performance with reliability robustness and ease of use

Security

An intruder capable of tapping the network on which Amoeba runs can discover capabilities and do considerable damage In a production environment some form of link encryption is needed to guarantee better security Although some thought has been given to a security mechanism [26] it was not implemented in Amoeba 40

We intend to install both versions and investigate the effects on performance of the system We are researching the problems of authentication in very large systems spanning multiple organizations and national boundaries

Io scheduling

Input and output (memory disk) is handled by the microkernel threads To read a block from the disk a process does remote procedure calls to a disk IO thread in the kernel The calling process does not know that the server is actually a kernel thread because user thread interfaces are identical to kernel thread interfaces

As far as file IO goes having multiple threads within a process accentuates the distributed and parallel and computing model very well

Reasons to use Amoeba

The need to control several machines from one user process can be accomplished by a distributed operating system such as Amoeba

Another situation that could efficiently utilize a distributed system is any program that commonly requires large computations

A more practical reason to use the Amoeba operating system is to save money both by utilizing old hardware and by lessening the need topurchase expensive servers An additional reason to use Amoeba is that the source code for the operating system is available for free so you can make your own version of Amoeba to suit your needs

Reasons not to use Amoeba

Other clustered operating systems that operate in a similar fashion to Amoeba are more readily available and easier to use

This is due to the fact that the source code is available for each user to edit These reasons along with others make Amoeba a risky business venture

Conclusion

Overall the Amoeba distributed operating system is an interesting and unique idea It provides system administrators the power to distribute work over a variety of machines without inconveniencing the users Despite this and other useful features we predict that Amoeba will not ever become a widely used operating system However the knowledge gained by the development of and research about Amoeba has helped in the design of other distributed and clustered operating systems

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28

WIDE-AREA AMOEBA

Amoeba was designed with the idea that a collection of machines on a LAN would be able to communicate over a wide-area network with a similar collection of remote machines The key problem here is that wide-area networks are slow and unreliable and furthermore use protocols such as X25 TCPIP and OSI in any event not RPC

APPLICATIONS

Amoeba has been used to program a variety of applications In this section we will describe several of them including UNIX emulation parallel make traveling salesman and alpha-beta search

UNIX Emulation

One of the goals of Amoeba was to make it useful as a program development environment

For such an environment one needs editors compilers and numerous other standard

software It was decided that the easiest way to obtain this software was to emulate UNIX and

then to run UNIX and MINIX [25] compilers and other utilities on top of it

PERFORMANCE

1 Two user processes running on Amoeba

2 Two user processes running on Sun OS 403 but using the Amoeba primitives

3 Two user processes running on Sun OS 403 and using Sun RPC

The latter two were for comparison purposes only We ran tests for the local case (both

processes on the same machine) and for the remote case (each process on a separate machine

with communication over the Ethernet) In all cases communication was from process to process

all of which were running in user mode outside the kernel The measurments represent

the average values of 100000 trials and are highly reproducible

Memory and Process Management

Amoebarsquos memory model which is handled by the microkernel is very small and efficient A processrsquos address space contains segments mapped onto user-specified virtual addresses

These segments include but not limited to a textcode segment a data segment and a stack segment for mainthread process

When a process is executing all of its segments are in memory Amoeba does not utilize virtual memory or swapping so it can only run programs that do not exceed physical memory This does however keeps the management scheme simple and provides high performance

File System

One area of the system which we think has been eminently successful is the design of the file server and directory server We have separated out two distinct parts the bullet server which just handles storage and the directory server which handles naming and protection The bullet server design allows it to be extremely fast while the directory server design gives a flexible protection scheme and also supports file replication in a simple and easy to understand way The key element here is the fact that files are immutable so they can be replicated at will and copies regenerated if necessary

The entire replication process takes place in the background (lazy replication) and is entirely automatic thus not bothering the user at all We regard the file system as the most innovative part of the Amoeba 40 design combining high performance with reliability robustness and ease of use

Security

An intruder capable of tapping the network on which Amoeba runs can discover capabilities and do considerable damage In a production environment some form of link encryption is needed to guarantee better security Although some thought has been given to a security mechanism [26] it was not implemented in Amoeba 40

We intend to install both versions and investigate the effects on performance of the system We are researching the problems of authentication in very large systems spanning multiple organizations and national boundaries

Io scheduling

Input and output (memory disk) is handled by the microkernel threads To read a block from the disk a process does remote procedure calls to a disk IO thread in the kernel The calling process does not know that the server is actually a kernel thread because user thread interfaces are identical to kernel thread interfaces

As far as file IO goes having multiple threads within a process accentuates the distributed and parallel and computing model very well

Reasons to use Amoeba

The need to control several machines from one user process can be accomplished by a distributed operating system such as Amoeba

Another situation that could efficiently utilize a distributed system is any program that commonly requires large computations

A more practical reason to use the Amoeba operating system is to save money both by utilizing old hardware and by lessening the need topurchase expensive servers An additional reason to use Amoeba is that the source code for the operating system is available for free so you can make your own version of Amoeba to suit your needs

Reasons not to use Amoeba

Other clustered operating systems that operate in a similar fashion to Amoeba are more readily available and easier to use

This is due to the fact that the source code is available for each user to edit These reasons along with others make Amoeba a risky business venture

Conclusion

Overall the Amoeba distributed operating system is an interesting and unique idea It provides system administrators the power to distribute work over a variety of machines without inconveniencing the users Despite this and other useful features we predict that Amoeba will not ever become a widely used operating system However the knowledge gained by the development of and research about Amoeba has helped in the design of other distributed and clustered operating systems

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28

APPLICATIONS

Amoeba has been used to program a variety of applications In this section we will describe several of them including UNIX emulation parallel make traveling salesman and alpha-beta search

UNIX Emulation

One of the goals of Amoeba was to make it useful as a program development environment

For such an environment one needs editors compilers and numerous other standard

software It was decided that the easiest way to obtain this software was to emulate UNIX and

then to run UNIX and MINIX [25] compilers and other utilities on top of it

PERFORMANCE

1 Two user processes running on Amoeba

2 Two user processes running on Sun OS 403 but using the Amoeba primitives

3 Two user processes running on Sun OS 403 and using Sun RPC

The latter two were for comparison purposes only We ran tests for the local case (both

processes on the same machine) and for the remote case (each process on a separate machine

with communication over the Ethernet) In all cases communication was from process to process

all of which were running in user mode outside the kernel The measurments represent

the average values of 100000 trials and are highly reproducible

Memory and Process Management

Amoebarsquos memory model which is handled by the microkernel is very small and efficient A processrsquos address space contains segments mapped onto user-specified virtual addresses

These segments include but not limited to a textcode segment a data segment and a stack segment for mainthread process

When a process is executing all of its segments are in memory Amoeba does not utilize virtual memory or swapping so it can only run programs that do not exceed physical memory This does however keeps the management scheme simple and provides high performance

File System

One area of the system which we think has been eminently successful is the design of the file server and directory server We have separated out two distinct parts the bullet server which just handles storage and the directory server which handles naming and protection The bullet server design allows it to be extremely fast while the directory server design gives a flexible protection scheme and also supports file replication in a simple and easy to understand way The key element here is the fact that files are immutable so they can be replicated at will and copies regenerated if necessary

The entire replication process takes place in the background (lazy replication) and is entirely automatic thus not bothering the user at all We regard the file system as the most innovative part of the Amoeba 40 design combining high performance with reliability robustness and ease of use

Security

An intruder capable of tapping the network on which Amoeba runs can discover capabilities and do considerable damage In a production environment some form of link encryption is needed to guarantee better security Although some thought has been given to a security mechanism [26] it was not implemented in Amoeba 40

We intend to install both versions and investigate the effects on performance of the system We are researching the problems of authentication in very large systems spanning multiple organizations and national boundaries

Io scheduling

Input and output (memory disk) is handled by the microkernel threads To read a block from the disk a process does remote procedure calls to a disk IO thread in the kernel The calling process does not know that the server is actually a kernel thread because user thread interfaces are identical to kernel thread interfaces

As far as file IO goes having multiple threads within a process accentuates the distributed and parallel and computing model very well

Reasons to use Amoeba

The need to control several machines from one user process can be accomplished by a distributed operating system such as Amoeba

Another situation that could efficiently utilize a distributed system is any program that commonly requires large computations

A more practical reason to use the Amoeba operating system is to save money both by utilizing old hardware and by lessening the need topurchase expensive servers An additional reason to use Amoeba is that the source code for the operating system is available for free so you can make your own version of Amoeba to suit your needs

Reasons not to use Amoeba

Other clustered operating systems that operate in a similar fashion to Amoeba are more readily available and easier to use

This is due to the fact that the source code is available for each user to edit These reasons along with others make Amoeba a risky business venture

Conclusion

Overall the Amoeba distributed operating system is an interesting and unique idea It provides system administrators the power to distribute work over a variety of machines without inconveniencing the users Despite this and other useful features we predict that Amoeba will not ever become a widely used operating system However the knowledge gained by the development of and research about Amoeba has helped in the design of other distributed and clustered operating systems

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28

UNIX Emulation

One of the goals of Amoeba was to make it useful as a program development environment

For such an environment one needs editors compilers and numerous other standard

software It was decided that the easiest way to obtain this software was to emulate UNIX and

then to run UNIX and MINIX [25] compilers and other utilities on top of it

PERFORMANCE

1 Two user processes running on Amoeba

2 Two user processes running on Sun OS 403 but using the Amoeba primitives

3 Two user processes running on Sun OS 403 and using Sun RPC

The latter two were for comparison purposes only We ran tests for the local case (both

processes on the same machine) and for the remote case (each process on a separate machine

with communication over the Ethernet) In all cases communication was from process to process

all of which were running in user mode outside the kernel The measurments represent

the average values of 100000 trials and are highly reproducible

Memory and Process Management

Amoebarsquos memory model which is handled by the microkernel is very small and efficient A processrsquos address space contains segments mapped onto user-specified virtual addresses

These segments include but not limited to a textcode segment a data segment and a stack segment for mainthread process

When a process is executing all of its segments are in memory Amoeba does not utilize virtual memory or swapping so it can only run programs that do not exceed physical memory This does however keeps the management scheme simple and provides high performance

File System

One area of the system which we think has been eminently successful is the design of the file server and directory server We have separated out two distinct parts the bullet server which just handles storage and the directory server which handles naming and protection The bullet server design allows it to be extremely fast while the directory server design gives a flexible protection scheme and also supports file replication in a simple and easy to understand way The key element here is the fact that files are immutable so they can be replicated at will and copies regenerated if necessary

The entire replication process takes place in the background (lazy replication) and is entirely automatic thus not bothering the user at all We regard the file system as the most innovative part of the Amoeba 40 design combining high performance with reliability robustness and ease of use

Security

An intruder capable of tapping the network on which Amoeba runs can discover capabilities and do considerable damage In a production environment some form of link encryption is needed to guarantee better security Although some thought has been given to a security mechanism [26] it was not implemented in Amoeba 40

We intend to install both versions and investigate the effects on performance of the system We are researching the problems of authentication in very large systems spanning multiple organizations and national boundaries

Io scheduling

Input and output (memory disk) is handled by the microkernel threads To read a block from the disk a process does remote procedure calls to a disk IO thread in the kernel The calling process does not know that the server is actually a kernel thread because user thread interfaces are identical to kernel thread interfaces

As far as file IO goes having multiple threads within a process accentuates the distributed and parallel and computing model very well

Reasons to use Amoeba

The need to control several machines from one user process can be accomplished by a distributed operating system such as Amoeba

Another situation that could efficiently utilize a distributed system is any program that commonly requires large computations

A more practical reason to use the Amoeba operating system is to save money both by utilizing old hardware and by lessening the need topurchase expensive servers An additional reason to use Amoeba is that the source code for the operating system is available for free so you can make your own version of Amoeba to suit your needs

Reasons not to use Amoeba

Other clustered operating systems that operate in a similar fashion to Amoeba are more readily available and easier to use

This is due to the fact that the source code is available for each user to edit These reasons along with others make Amoeba a risky business venture

Conclusion

Overall the Amoeba distributed operating system is an interesting and unique idea It provides system administrators the power to distribute work over a variety of machines without inconveniencing the users Despite this and other useful features we predict that Amoeba will not ever become a widely used operating system However the knowledge gained by the development of and research about Amoeba has helped in the design of other distributed and clustered operating systems

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28

PERFORMANCE

1 Two user processes running on Amoeba

2 Two user processes running on Sun OS 403 but using the Amoeba primitives

3 Two user processes running on Sun OS 403 and using Sun RPC

The latter two were for comparison purposes only We ran tests for the local case (both

processes on the same machine) and for the remote case (each process on a separate machine

with communication over the Ethernet) In all cases communication was from process to process

all of which were running in user mode outside the kernel The measurments represent

the average values of 100000 trials and are highly reproducible

Memory and Process Management

Amoebarsquos memory model which is handled by the microkernel is very small and efficient A processrsquos address space contains segments mapped onto user-specified virtual addresses

These segments include but not limited to a textcode segment a data segment and a stack segment for mainthread process

When a process is executing all of its segments are in memory Amoeba does not utilize virtual memory or swapping so it can only run programs that do not exceed physical memory This does however keeps the management scheme simple and provides high performance

File System

One area of the system which we think has been eminently successful is the design of the file server and directory server We have separated out two distinct parts the bullet server which just handles storage and the directory server which handles naming and protection The bullet server design allows it to be extremely fast while the directory server design gives a flexible protection scheme and also supports file replication in a simple and easy to understand way The key element here is the fact that files are immutable so they can be replicated at will and copies regenerated if necessary

The entire replication process takes place in the background (lazy replication) and is entirely automatic thus not bothering the user at all We regard the file system as the most innovative part of the Amoeba 40 design combining high performance with reliability robustness and ease of use

Security

An intruder capable of tapping the network on which Amoeba runs can discover capabilities and do considerable damage In a production environment some form of link encryption is needed to guarantee better security Although some thought has been given to a security mechanism [26] it was not implemented in Amoeba 40

We intend to install both versions and investigate the effects on performance of the system We are researching the problems of authentication in very large systems spanning multiple organizations and national boundaries

Io scheduling

Input and output (memory disk) is handled by the microkernel threads To read a block from the disk a process does remote procedure calls to a disk IO thread in the kernel The calling process does not know that the server is actually a kernel thread because user thread interfaces are identical to kernel thread interfaces

As far as file IO goes having multiple threads within a process accentuates the distributed and parallel and computing model very well

Reasons to use Amoeba

The need to control several machines from one user process can be accomplished by a distributed operating system such as Amoeba

Another situation that could efficiently utilize a distributed system is any program that commonly requires large computations

A more practical reason to use the Amoeba operating system is to save money both by utilizing old hardware and by lessening the need topurchase expensive servers An additional reason to use Amoeba is that the source code for the operating system is available for free so you can make your own version of Amoeba to suit your needs

Reasons not to use Amoeba

Other clustered operating systems that operate in a similar fashion to Amoeba are more readily available and easier to use

This is due to the fact that the source code is available for each user to edit These reasons along with others make Amoeba a risky business venture

Conclusion

Overall the Amoeba distributed operating system is an interesting and unique idea It provides system administrators the power to distribute work over a variety of machines without inconveniencing the users Despite this and other useful features we predict that Amoeba will not ever become a widely used operating system However the knowledge gained by the development of and research about Amoeba has helped in the design of other distributed and clustered operating systems

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28

Memory and Process Management

Amoebarsquos memory model which is handled by the microkernel is very small and efficient A processrsquos address space contains segments mapped onto user-specified virtual addresses

These segments include but not limited to a textcode segment a data segment and a stack segment for mainthread process

When a process is executing all of its segments are in memory Amoeba does not utilize virtual memory or swapping so it can only run programs that do not exceed physical memory This does however keeps the management scheme simple and provides high performance

File System

One area of the system which we think has been eminently successful is the design of the file server and directory server We have separated out two distinct parts the bullet server which just handles storage and the directory server which handles naming and protection The bullet server design allows it to be extremely fast while the directory server design gives a flexible protection scheme and also supports file replication in a simple and easy to understand way The key element here is the fact that files are immutable so they can be replicated at will and copies regenerated if necessary

The entire replication process takes place in the background (lazy replication) and is entirely automatic thus not bothering the user at all We regard the file system as the most innovative part of the Amoeba 40 design combining high performance with reliability robustness and ease of use

Security

An intruder capable of tapping the network on which Amoeba runs can discover capabilities and do considerable damage In a production environment some form of link encryption is needed to guarantee better security Although some thought has been given to a security mechanism [26] it was not implemented in Amoeba 40

We intend to install both versions and investigate the effects on performance of the system We are researching the problems of authentication in very large systems spanning multiple organizations and national boundaries

Io scheduling

Input and output (memory disk) is handled by the microkernel threads To read a block from the disk a process does remote procedure calls to a disk IO thread in the kernel The calling process does not know that the server is actually a kernel thread because user thread interfaces are identical to kernel thread interfaces

As far as file IO goes having multiple threads within a process accentuates the distributed and parallel and computing model very well

Reasons to use Amoeba

The need to control several machines from one user process can be accomplished by a distributed operating system such as Amoeba

Another situation that could efficiently utilize a distributed system is any program that commonly requires large computations

A more practical reason to use the Amoeba operating system is to save money both by utilizing old hardware and by lessening the need topurchase expensive servers An additional reason to use Amoeba is that the source code for the operating system is available for free so you can make your own version of Amoeba to suit your needs

Reasons not to use Amoeba

Other clustered operating systems that operate in a similar fashion to Amoeba are more readily available and easier to use

This is due to the fact that the source code is available for each user to edit These reasons along with others make Amoeba a risky business venture

Conclusion

Overall the Amoeba distributed operating system is an interesting and unique idea It provides system administrators the power to distribute work over a variety of machines without inconveniencing the users Despite this and other useful features we predict that Amoeba will not ever become a widely used operating system However the knowledge gained by the development of and research about Amoeba has helped in the design of other distributed and clustered operating systems

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28

File System

One area of the system which we think has been eminently successful is the design of the file server and directory server We have separated out two distinct parts the bullet server which just handles storage and the directory server which handles naming and protection The bullet server design allows it to be extremely fast while the directory server design gives a flexible protection scheme and also supports file replication in a simple and easy to understand way The key element here is the fact that files are immutable so they can be replicated at will and copies regenerated if necessary

The entire replication process takes place in the background (lazy replication) and is entirely automatic thus not bothering the user at all We regard the file system as the most innovative part of the Amoeba 40 design combining high performance with reliability robustness and ease of use

Security

An intruder capable of tapping the network on which Amoeba runs can discover capabilities and do considerable damage In a production environment some form of link encryption is needed to guarantee better security Although some thought has been given to a security mechanism [26] it was not implemented in Amoeba 40

We intend to install both versions and investigate the effects on performance of the system We are researching the problems of authentication in very large systems spanning multiple organizations and national boundaries

Io scheduling

Input and output (memory disk) is handled by the microkernel threads To read a block from the disk a process does remote procedure calls to a disk IO thread in the kernel The calling process does not know that the server is actually a kernel thread because user thread interfaces are identical to kernel thread interfaces

As far as file IO goes having multiple threads within a process accentuates the distributed and parallel and computing model very well

Reasons to use Amoeba

The need to control several machines from one user process can be accomplished by a distributed operating system such as Amoeba

Another situation that could efficiently utilize a distributed system is any program that commonly requires large computations

A more practical reason to use the Amoeba operating system is to save money both by utilizing old hardware and by lessening the need topurchase expensive servers An additional reason to use Amoeba is that the source code for the operating system is available for free so you can make your own version of Amoeba to suit your needs

Reasons not to use Amoeba

Other clustered operating systems that operate in a similar fashion to Amoeba are more readily available and easier to use

This is due to the fact that the source code is available for each user to edit These reasons along with others make Amoeba a risky business venture

Conclusion

Overall the Amoeba distributed operating system is an interesting and unique idea It provides system administrators the power to distribute work over a variety of machines without inconveniencing the users Despite this and other useful features we predict that Amoeba will not ever become a widely used operating system However the knowledge gained by the development of and research about Amoeba has helped in the design of other distributed and clustered operating systems

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28

Security

An intruder capable of tapping the network on which Amoeba runs can discover capabilities and do considerable damage In a production environment some form of link encryption is needed to guarantee better security Although some thought has been given to a security mechanism [26] it was not implemented in Amoeba 40

We intend to install both versions and investigate the effects on performance of the system We are researching the problems of authentication in very large systems spanning multiple organizations and national boundaries

Io scheduling

Input and output (memory disk) is handled by the microkernel threads To read a block from the disk a process does remote procedure calls to a disk IO thread in the kernel The calling process does not know that the server is actually a kernel thread because user thread interfaces are identical to kernel thread interfaces

As far as file IO goes having multiple threads within a process accentuates the distributed and parallel and computing model very well

Reasons to use Amoeba

The need to control several machines from one user process can be accomplished by a distributed operating system such as Amoeba

Another situation that could efficiently utilize a distributed system is any program that commonly requires large computations

A more practical reason to use the Amoeba operating system is to save money both by utilizing old hardware and by lessening the need topurchase expensive servers An additional reason to use Amoeba is that the source code for the operating system is available for free so you can make your own version of Amoeba to suit your needs

Reasons not to use Amoeba

Other clustered operating systems that operate in a similar fashion to Amoeba are more readily available and easier to use

This is due to the fact that the source code is available for each user to edit These reasons along with others make Amoeba a risky business venture

Conclusion

Overall the Amoeba distributed operating system is an interesting and unique idea It provides system administrators the power to distribute work over a variety of machines without inconveniencing the users Despite this and other useful features we predict that Amoeba will not ever become a widely used operating system However the knowledge gained by the development of and research about Amoeba has helped in the design of other distributed and clustered operating systems

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28

Io scheduling

Input and output (memory disk) is handled by the microkernel threads To read a block from the disk a process does remote procedure calls to a disk IO thread in the kernel The calling process does not know that the server is actually a kernel thread because user thread interfaces are identical to kernel thread interfaces

As far as file IO goes having multiple threads within a process accentuates the distributed and parallel and computing model very well

Reasons to use Amoeba

The need to control several machines from one user process can be accomplished by a distributed operating system such as Amoeba

Another situation that could efficiently utilize a distributed system is any program that commonly requires large computations

A more practical reason to use the Amoeba operating system is to save money both by utilizing old hardware and by lessening the need topurchase expensive servers An additional reason to use Amoeba is that the source code for the operating system is available for free so you can make your own version of Amoeba to suit your needs

Reasons not to use Amoeba

Other clustered operating systems that operate in a similar fashion to Amoeba are more readily available and easier to use

This is due to the fact that the source code is available for each user to edit These reasons along with others make Amoeba a risky business venture

Conclusion

Overall the Amoeba distributed operating system is an interesting and unique idea It provides system administrators the power to distribute work over a variety of machines without inconveniencing the users Despite this and other useful features we predict that Amoeba will not ever become a widely used operating system However the knowledge gained by the development of and research about Amoeba has helped in the design of other distributed and clustered operating systems

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28

Reasons to use Amoeba

The need to control several machines from one user process can be accomplished by a distributed operating system such as Amoeba

Another situation that could efficiently utilize a distributed system is any program that commonly requires large computations

A more practical reason to use the Amoeba operating system is to save money both by utilizing old hardware and by lessening the need topurchase expensive servers An additional reason to use Amoeba is that the source code for the operating system is available for free so you can make your own version of Amoeba to suit your needs

Reasons not to use Amoeba

Other clustered operating systems that operate in a similar fashion to Amoeba are more readily available and easier to use

This is due to the fact that the source code is available for each user to edit These reasons along with others make Amoeba a risky business venture

Conclusion

Overall the Amoeba distributed operating system is an interesting and unique idea It provides system administrators the power to distribute work over a variety of machines without inconveniencing the users Despite this and other useful features we predict that Amoeba will not ever become a widely used operating system However the knowledge gained by the development of and research about Amoeba has helped in the design of other distributed and clustered operating systems

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28

Reasons not to use Amoeba

Other clustered operating systems that operate in a similar fashion to Amoeba are more readily available and easier to use

This is due to the fact that the source code is available for each user to edit These reasons along with others make Amoeba a risky business venture

Conclusion

Overall the Amoeba distributed operating system is an interesting and unique idea It provides system administrators the power to distribute work over a variety of machines without inconveniencing the users Despite this and other useful features we predict that Amoeba will not ever become a widely used operating system However the knowledge gained by the development of and research about Amoeba has helped in the design of other distributed and clustered operating systems

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28

Conclusion

Overall the Amoeba distributed operating system is an interesting and unique idea It provides system administrators the power to distribute work over a variety of machines without inconveniencing the users Despite this and other useful features we predict that Amoeba will not ever become a widely used operating system However the knowledge gained by the development of and research about Amoeba has helped in the design of other distributed and clustered operating systems

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28