P. Barham. Devices in a Multi-Service Operating System. PhD thesis, University of Cambridge Computer Laboratory, July 1996.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....further detail on the Nemesis Operating System developed at the University of Cambridge. The origins of Nemesis are discussed, along with the properties that make it suitable as a base for the Rcane architecture to be presented in Chapter 5. More information may be found in [Roscoe95, Leslie96, Barham96] 4.1 Overview In traditional operating systems, tasks such as network protocol processing, paging, and graphics rendering are performed either in a shared server or in the kernel unless this work is carefully scheduled and accounted for, it can cause Quality of Service interference ....

....incoming events (see Section 4.4) and then dispatch to a user level thread scheduler. This gives the application full control over how its allotted CPU time is used. The problem of accounting for time consumed by a graphics server has also been seen to occur with the X server on Unix systems [Barham96] Because Nemesis requires that applications perform their own work rather than relying on servers, it is possible to significantly regulate the total CPU load put on the system due to an application s activity. Furthermore, since far more of the activities accountable to an application take ....

[Article contains additional citation context not shown here]

Paul Barham. Devices in a Multi-Service Operating System. PhD Thesis 403, University of Cambridge Computer Laboratory, October 1996. (pp 48, 50, 51, 52, 78)

....system on which it runs can only handle a single SCSI interface card. In any case, since the CPU is in the data path for continuous media data transmission, it is expected that Calliope cannot send more than 7.5 MB s through a Pentium based PC. 2. 7 User Safe Disk Barham s User Safe Disk (USD) [10, 9] partitions the available disk bandwidth to a number of data streams that use the disk. Each stream requests a certain Quality of Service (QoS) from the disk, which, when the request succeeds, hands the disk bandwidth to the stream. The novel approach by Barham is that each application is given ....

....effects. Drives usually know which head angle corresponds to a track number and if the platters expand, this information needs to be updated by a re calibration. When the re calibration is done naively, such as is the case for the Digital RZ25, the measured disk performance can vary dramatically [10]. The RZ25 recalibrates every 30 seconds even when there is work to do. A Quantum Atlas II disk implements a smarter policy: the disk recalibrates whenever the disk has been idle for 30 seconds. This policy works well because, as is shown by Golding et al. 28] when a disk has been idle for some ....

[Article contains additional citation context not shown here]

Paul Ronald Barham. Devices in a Multi-Service Operating System. PhD thesis. Churchill College, University of Cambridge, July 1996.

....the use of small schedulers within the servers to reduce crosstalk, and gives client applications qualitative bounds on the jitter they experience from a service. Operating system servers which provide QoS in this way, particularly window systems, are currently being investigated within Nemesis [Barham95b]. 5.5.1 Performance Figure 5.5 shows the distribution of same machine null RPC times between two domains on an otherwise unloaded machine. Most calls take about 30s, which compares very favourably with those reported in [Chase93] for Mach (88s) and Opal (122s) on the same hardware. The calls ....

Paul Barham. Devices in a Multi-Service Operating System. PhD thesis, University of Cambridge Computer Laboratory, 1995. in preparation. (p 98)

....system designers, many other resources are also used, such as device drivers, I O buses, and peripherals. QoS guarantees must also be provided for these resources if crosstalk is to be avoided. 3 Nemesis attempts to apply the vertical structuring concept to operating system I O functions [Barham96] Conventional operating systems tend to o er applications a high level abstraction of devices. In Nemesis, this higher level functionality is distilled into shared libraries executed in the application domain. Only a minimal driver remains; just that necessary to implement protection and QoS ....

....which they have not been guaranteed any minimum QoS. Applications should be provided with guarantees for all the resources they use if they are to behave predictably on a loaded system. Since many soft real time applications are I O intensive, these guarantees must be extended to I O resources [Barham96] Two types of resource have been identi ed: real resources, such as CPUs, memory, disk drives, networks, frame bu ers etc. and virtual resources, such as servers, device drivers, and other operating system components. Virtual resources are created over the top of real resources by application ....

[Article contains additional citation context not shown here]

Paul Barham. Devices in a Multi-Service Operating System. Technical Report 403, University of Cambridge Computer Laboratory, September 1996. (pp 4, 25, 31)

....on a loaded system. Multimedia applications are frequently I O intensive. They exercise other system resources, such as operating system device drivers, workstation I O buses, and peripheral devices. The importance of providing QoS for these resources has only more recently become apparent [1, 2, 3]. 2 Nemesis I O Architecture QoS Crosstalk [4] is the effect observed when the performance of an application is adversely effected This work was supported by the EPSRC. by the behaviour of other applications. It can occur whenever two or more applications queue to make use of a resource for ....

....within the application process domain. This avoids the need for resource transfer between clients and servers, and is often more efficient. Nemesis only uses shared servers where they are necessary e.g. to provide locking, or to ensure system integrity. Nemesis takes the same approach to I O [1]. Whereas conventional operating systems can spend considerable CPU time performing I O on behalf of applications, 1 Nemesis requires that applications do as much of their own I O processing as possible. For example, applications perform their own network protocol processing and X server style ....

Paul Barham. Devices in a multi-service operating system. Technical Report 403, University of Cambridge Computer Laboratory, September 1996.

....executed by the operating system on behalf of an application need not be executed in a different protection domain. Code that accesses and updates important shared data structures is usually executed infrequently and is usually associated with out of band operations like opening and closing a file [1]. Nemesis exploits this to move the majority of operating system functionality into the application 2 domain. The result is a vertically structured operating system (figure 2) This structure lends itself to more accurate accounting as each domain is billed not only for the execution of its own ....

....the fault. This may involve replacing a page currently in physical memory the method used to do this is entirely the responsibility of the stretch driver for a particular domain. 2. 4 Devices in Nemesis Nemesis device drivers minimise QoS crosstalk by separating the data and control paths [1]. Figure 4 shows the architecture for a device driver under Nemesis. Nemesis places additional demands on device drivers compared to those under traditional systems 3 : ffl Drivers do not hide the shared nature of the underlying physical resource but instead provide explicit control over the ....

[Article contains additional citation context not shown here]

Barham, P. R. Devices in a Multi-Service Operating System. Tech. Rep. 403, University of Cambridge, England, University of Cambridge, Computer Laboratory, New Museums Site, Pembroke Street, Cambridge CB2 3QG, England, October 1996.

....to that in [20] and [19] and may be skipped if already read. 2 be executed in a di erent protection domain. Code that accesses and updates important shared data structures is usually executed infrequently and is usually associated with out of band operations like opening and closing a le [1]. Nemesis exploits this to move the majority of operating system functionality into the application domain. The result is a vertically structured operating system ( gure 2) This structure lends itself to more accurate accounting as each domain is billed not only for the execution of its own ....

....the fault. This may involve replacing a page currently in physical memory the method used to do this is entirely the responsibility of the stretch driver for a particular domain. 2. 4 Devices in Nemesis Nemesis device drivers minimise QoS crosstalk by separating the data and control paths [1]. Figure 4 shows the architecture for a device driver under Nemesis. Nemesis places additional demands on device drivers compared to those under traditional systems 4 : Drivers do not hide the shared nature of the underlying physical resource but instead provide explicit control over the ....

[Article contains additional citation context not shown here]

Barham, P. R. Devices in a Multi-Service Operating System. Tech. Rep. 403, University of Cambridge, England, October 1996.

....executed by the operating system on behalf of an application need not be executed in a different protection domain. Code that accesses and updates important shared data structures is usually executed infrequently and is usually associated with out of band operations like opening and closing a file [1]. Nemesis exploits this to move the majority of operating system functionality into the application domain. The result is a vertically structured operating system (figure 1) This structure lends itself to more accurate accounting as each domain is billed not only for the execution of its own ....

....the fault. This may involve replacing a page currently in physical memory the method used to do this is entirely the responsibility of the stretch driver for a particular domain. 2. 4 Devices in Nemesis Nemesis device drivers minimise QoS crosstalk by separating the data and control paths [1]. Figure 3 shows the architecture for a device driver under Nemesis. Nemesis places additional demands on device drivers compared to those under traditional systems 5 : ffl Drivers do not hide the shared nature of the underlying physical resource but instead provide explicit control over the ....

[Article contains additional citation context not shown here]

Barham, P. R. Devices in a Multi-Service Operating System. Tech. Rep. 403, University of Cambridge, England, University of Cambridge, Computer Laboratory, New Museums Site, Pembroke Street, Cambridge CB2 3QG, England, October 1996.

....MSSA. This file system will provide a flexible service to applications, which will allow them to manipulate many file types in a simple and efficient way. 6. 1 Nemesis file system concepts In Nemesis, the disk is represented to clients by an abstraction known as the User Safe Disk (described in [2]) The basic idea behind the USD, as behind all Nemesis device drivers, is to provide a safe way for clients to transfer data directly to the device, without needing to go through a server. Incidentally, this approach is similar to that taken in many other file system projects, such those on ....

Paul Barham. Devices in a Multi-Service Operating System. PhD thesis, University of Cambridge Computer Laboratory, October 1996.

....some form will ensue. Clearly this can be improved; however it will suffice for the demonstration of Quality of Service Firewalling in Section 7.2. 6. 7 User Safe Backing Store The user safe backing store (USBS) is comprised of two parts: the swap filesystem (SFS) and the user safe disk (USD) [32]. The SFS is responsible for control operations such as allocation of an extent (a contiguous range of blocks) for use as a swap file, and the negotiation of Quality of Service parameters to the USD, which is responsible for scheduling data operations. This is illustrated in Figure 6. Disk ....

P. Barham. Devices in a Multi-Service Operating System. PhD thesis, University of Cambridge Computer Laboratory, July 1996.

....and the stretch driver returns Success. Clearly this can be improved; however it will suffice for the demonstration of Quality of Service Firewalling . 6. 7 User Safe Backing Store The user safe backing store (USBS) is comprised of two parts: the swap filesystem (SFS) and the user safe disk (USD)[34]. The SFS is responsible for control operations such as allocation of an extent (a contiguous range of blocks) for use as a swap file, and the negotiation quality of service parameters to the USD. The USD itself is responsible for scheduling data operations. This is illustrated in Figure 6. Disk ....

Paul Barham. Devices in a Multi-Service Operating System. PhD thesis, University of Cambridge Computer Laboratory, July 1996. Available as Technical Report no. 403.

....A variety of deliverables of the Pegasus II project constitute ports of Nemesis, or developments of Nemesis, but the project has also to deliver a variety of things that are, in Nemesis parlance, applications. Nemesis is moving out of the laboratory Chapters 1 and 2 derive (respectively) from [Barham 96] and [Roscoe 95b] Other chapters have been written specifically for the purposes of this document. Comments, either pointing out problems or correcting errors, will be welcomed by the editors. Such comments should be posted to the newsgroup nemesis.misc 3 , or mailed direct to one of the ....

....The kernel therefore schedules threads rather than processes. Whilst this reduces the functionality required in applications and usually results in more efficient processor context switches, the necessary thread scheduling policy decisions must also be migrated into the kernel. As pointed out in [Barham 96] this is highly undesirable. Attempts to allow applications to communicate thread scheduling policy to the kernel scheduler [Coulson 93, Coulson 95] lead to increased complexity of the kernel and the possibility for uncooperative applications to misrepresent their needs to the operating system ....

[Article contains additional citation context not shown here]

Paul R. Barham. Devices in a Multi-Service Operating System. PhD thesis, University of Cambridge Computer Laboratory, July 1996. Available as Technical Report No. 403. (pp iv, 9, 12)

....of each of these operating systems take on renewed relevance when QoS is the most important consideration. 2 Device Drivers Under Nemesis Nemesis provides QoS guarantees for I O using a non orthodox approach to device abstraction which completely separates the control and data path functions [6]. A fundamental requirement for effective provision of Quality of Service is that there is some form of connection against which to account I O resources. All device drivers under Nemesis are therefore connection oriented i.e. clients send a stream of requests to the driver on a ....

....drives is usually characterised by a handful of parameters related to the mechanical timings of the device, e.g. seek and rotation times. Although these figures are typically the only information provided with a drive, they are a dramatic over simplification of the actual behaviour of the device [6]. The average seek and access times given in the drive specifications are sometimes of little use when trying to estimate the cost of a transaction since modern drive controllers are optimised for certain common access patterns. When these assumptions fail the results are costly. Another ....

Paul R. Barham. Devices in a Multi-Service Operating System. PhD thesis, University of Cambridge Computer Laboratory, July 1996. Available as Technical Report No. 403.

....the data to its eventual destination. Some protocols have sufficiently simple (de)multiplexing that it is reasonable to make use of such support directly in the hardware. Obvious examples include basic AAL5 access over either the U Net modified Fore Systems ATM interface, or the Nemesis ATMWorks [2] driver. 4 Less obvious examples are the Autonet One Buffer Queue Index (BQI) scheme for TCP connections [15] or the Ipsilon scheme for allocating ATM circuits to IP flows [12] In such schemes the security information referred to above is assumed to have been transmitted to the peer during ....

....driver for non selfselecting interfaces causes CPU time not to be attributed to the application but to the device driver. We now describe a scheme for averting this problem. 3.5.1. Call Priv. Nemesis has a concept called a call priv (originally developed for the windowing system and described in [2]) This is best thought of as a pseudo opcode that its name is similar to the Alpha processor s call pal is not accidental. A call priv is a trap into trusted code provided by a device driver which allows some operation to take place in the privileged protection domain of the callee, but on ....

P. R. Barham. Devices in a Multi-Service Operating System. Technical Report 403, University of Cambridge Computer Laboratory, October 1996. Ph.D. Dissertation.

No context found.

P. Barham. Devices in a Multi-Service Operating System. PhD thesis, University of Cambridge Computer Laboratory, July 1996.

No context found.

P. R. Barham; \Devices in a MultiService Operating System", Ph.D. Thesis, University of Cambridge (July 1996).

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC