amoeba
DESCRIPTION
About amoeba osTRANSCRIPT
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
-