Results 1 - 10
of
14
Eliminating receive livelock in an interrupt-driven kernel
- ACM Transactions on Computer Systems
, 1997
"... Most operating systems use interface interrupts to schedule network tasks. Interrupt-driven systems can provide low overhead and good latency at low of-fered load, but degrade significantly at higher arrival rates unless care is taken to prevent several pathologies. These are various forms of receiv ..."
Abstract
-
Cited by 241 (4 self)
- Add to MetaCart
Most operating systems use interface interrupts to schedule network tasks. Interrupt-driven systems can provide low overhead and good latency at low of-fered load, but degrade significantly at higher arrival rates unless care is taken to prevent several pathologies. These are various forms of receive livelock, in which the system spends all its time processing interrupts, to the exclusion of other neces-sary tasks. Under extreme conditions, no packets are delivered to the user application or the output of the system. To avoid livelock and related problems, an operat-ing system must schedule network interrupt handling as carefully as it schedules process execution. We modified an interrupt-driven networking implemen-tation to do so; this eliminates receive livelock without degrading other aspects of system performance. We present measurements demonstrating the success of our approach. 1.
NFS version 3: Design and implementation
- In Proceedings of the Summer 1994 USENIX Technical Conference
, 1994
"... This paper describes a new version of the Network File System (NFS) that supports access to files larger than 4GB and increases sequential write throughput sevenfold when compared to unaccelerated NFS Version 2. NFS Version 3 maintains the stateless server design and simple crash recovery of NFS Ver ..."
Abstract
-
Cited by 71 (0 self)
- Add to MetaCart
This paper describes a new version of the Network File System (NFS) that supports access to files larger than 4GB and increases sequential write throughput sevenfold when compared to unaccelerated NFS Version 2. NFS Version 3 maintains the stateless server design and simple crash recovery of NFS Version 2, and the philosophy of building a distributed file service from cooperating protocols. We describe the protocol and its implementation, and provide initial performance measurements. We then describe the implementation effort. Finally, we contrast this work with other distributed file systems and discuss future revisions of NFS. 1.
The NFS version 4 protocol
- In Proceedings of the 2nd International System Administration and Networking Conference (SANE 2000
, 2000
"... The Network File System (NFS) Version 4 is a new distributed file system similar to previous versions of NFS in its straightforward design, simplified error recovery, and independence of transport protocols and operating systems for file access in a heterogeneous network. Unlike earlier versions of ..."
Abstract
-
Cited by 42 (0 self)
- Add to MetaCart
The Network File System (NFS) Version 4 is a new distributed file system similar to previous versions of NFS in its straightforward design, simplified error recovery, and independence of transport protocols and operating systems for file access in a heterogeneous network. Unlike earlier versions of NFS, the new protocol integrates file locking, strong security, operation coalescing, and delegation capabilities to enhance client performance for narrow data sharing applications on high-bandwidth networks. Locking and delegation make NFS stateful, but simplicity of design is retained through well-defined recovery semantics in the face of client and server failures and network partitions. This paper describes the new features of the protocol, focusing on the security enhancements, integrated locking support, changes to fully support Windows file sharing semantics, support for high performance data sharing, and the design points that enhance performance on the Internet.
Improving Continuous-Media Playback Performance with In-Kernel Data Paths
- Proceedings of the IEEE International Conference on Multimedia Computing and Systems (ICMCS
, 1993
"... Continuous media playback suffers when a station 's operating system offers insufficient I/O throughput. Conventional I/O system structures support a memory--oriented read and write interface requiring the execution of user--level processes to facilitate playback, and can incur throughput degradatio ..."
Abstract
-
Cited by 31 (6 self)
- Add to MetaCart
Continuous media playback suffers when a station 's operating system offers insufficient I/O throughput. Conventional I/O system structures support a memory--oriented read and write interface requiring the execution of user--level processes to facilitate playback, and can incur throughput degradation due to unnecessary data copies. Our splice mechanism supports a peer--to--peer model of I/O where a requesting application can associate a data source with its corresponding data sink, allowing for system optimizations in the data path implementation. In an experiment designed to simulate remote video playback, we present measurements indicating that use of our techniques resulted in a 55% gain in throughput as compared with conventional systems. 1 Introduction Computer and networking technology are beginning to offer a digital alternative to current analog cable and broadcast systems. Transmission and display of continuous media information including video is presently achievable with c...
Not Quite NFS, Soft Cache Consistency for NFS
- In USENIX Association Conference Proceedings
, 1994
"... There are some constraints inherent in the NFS™ ∈ protocol that result in performance limitations for high performance workstation environments. This paper discusses an NFS-like protocol named Not Quite NFS (NQNFS), designed to address some of these limitations. This protocol provides full cache con ..."
Abstract
-
Cited by 23 (0 self)
- Add to MetaCart
There are some constraints inherent in the NFS™ ∈ protocol that result in performance limitations for high performance workstation environments. This paper discusses an NFS-like protocol named Not Quite NFS (NQNFS), designed to address some of these limitations. This protocol provides full cache consistency during normal operation, while permitting more effective client-side caching in an effort to improve performance. There are also a variety of minor protocol changes, in order to resolve various NFS issues. The emphasis is on observed performance of a preliminary implementation of the protocol, in order to show how well this design works and to suggest possible areas for further improvement. 1.
Use of Link-by-Link Flow Control in Maximizing ATM Network Performance: Simulation Results
, 1993
"... Simulations have been performed to verify the effectiveness of using link-by-link flow controlled virtual channels for maximizing ATM network performance. A simulator which accurately reflects the real hardware design of a flow controlled ATM switch is used. The switch is currently under joint devel ..."
Abstract
-
Cited by 15 (1 self)
- Add to MetaCart
Simulations have been performed to verify the effectiveness of using link-by-link flow controlled virtual channels for maximizing ATM network performance. A simulator which accurately reflects the real hardware design of a flow controlled ATM switch is used. The switch is currently under joint development by BNR and Harvard. The simulation results clearly demonstrate that the flow control mechanism is able to provide sufficiently rapid feedback to allow a network to adapt to load changes and maximize its performance. The simulations also show that, when compared to VCs using other traffic management approaches, flow controlled virtual circuits are efficient in terms of buffer usage and in point-to-multipoint multicast implementations. 1 Introduction A set of credit-based flow control schemes for implementing link-by-link flow controlled virtual channels has been proposed, in [5], for asynchronous transfer mode (ATM) networks [1, 3]. These three increasingly memory-efficient credit-ba...
Linux NFS Client Write Performance
, 2001
"... We introduce a simple sequential write benchmark and use it to improve Linux NFS client write performance. We reduce the latency of the write() system call, improve SMP write performance, and reduce kernel CPU processing during sequential writes. Cached write throughput to NFS files improves by more ..."
Abstract
-
Cited by 6 (0 self)
- Add to MetaCart
We introduce a simple sequential write benchmark and use it to improve Linux NFS client write performance. We reduce the latency of the write() system call, improve SMP write performance, and reduce kernel CPU processing during sequential writes. Cached write throughput to NFS files improves by more than a factor of three.
The 4.4BSD NFS Implementation
- Berkeley Software Distribution, University of California, Berkeley
, 1993
"... The 4.4BSD implementation of the Network File System (NFS) 1 is intended to interoperate with other NFS Version 2 Protocol (RFC1094) implementations but also allows use of an alternate protocol that is hoped to provide better performance in certain environments. This paper will informally discuss th ..."
Abstract
-
Cited by 3 (1 self)
- Add to MetaCart
The 4.4BSD implementation of the Network File System (NFS) 1 is intended to interoperate with other NFS Version 2 Protocol (RFC1094) implementations but also allows use of an alternate protocol that is hoped to provide better performance in certain environments. This paper will informally discuss these various protocol features and their use. There is a brief overview of the implementation followed by several sections on various problem areas related to NFS and some hints on how to deal with them. Not Quite NFS (NQNFS) is an NFS like protocol designed to maintain full cache consistency between clients in a crash tolerant manner. It is an adaptation of the NFS protocol such that the server supports both NFS and NQNFS clients while maintaining full consistency between the server and NQNFS clients. It borrows heavily from work done on Spritely-NFS [Srinivasan89], but uses Leases [Gray89] to avoid the need to recover server state information after a crash. 1. NFS Implementation The 4.4BSD implementation of NFS and the alternate protocol nicknamed Not Quite NFS (NQNFS) are kernel resident, but make use of a few system daemons. The kernel implementation does not use an RPC library, handling the RPC request and reply messages directly in mbuf data areas. NFS interfaces to
Adaptive Caching in a Distributed File System
, 1995
"... E ective le system caching reduces local disk accesses and remote le server accesses signi cantly. Traditional le systems use xed strategies to control caching. This thesis shows that a le system with adaptive caching achieves better performance than traditional le systems. Our le system implements ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
E ective le system caching reduces local disk accesses and remote le server accesses signi cantly. Traditional le systems use xed strategies to control caching. This thesis shows that a le system with adaptive caching achieves better performance than traditional le systems. Our le system implements multiple caching strategies and permits performance tuning through customized caching strategies. It adapts to the computing environment by selecting strategies suitable for the environment. It observes le accesses and uses the observed behaviors to anticipate and predict future behaviors. It adapts to di erent le access behaviors by modifying caching strategies. It does not depend on the application or the user for caching hints but will utilize hints when provided. Experiments with two large workloads having distinct le access characteristics show that adaptive le caching consistently outperforms non-adaptive caching. Adaptive le caching can reduce runtime by 36.6%, cache misses by 20.6%, and network load by 24.2%. In addition, this work also includes innovations in le system architecture. They include continuations for highly-concurrent asynchronous remote accesses, and zombies for e cient memory reclamation. iii To my parents iv Acknowledgements I wish to express my deepest gratitude to all those who have supported me through this e ort. I especially thank my advisors, Professor Roy Campbell and Professor Michael Condry, whose technical and nancial support made this thesis possible. Besides Roy and Michael, I thank the other members
Microsystems
, 1993
"... this document is to: . Specify the NFS version 3 protocol . Describe semantics of the protocol through annotation and description of intended implementation . Specify the MOUNT version 3 protocol . Briefly describe the changes between the NLM version 3 protocol and the NLM version 4 protocol. The no ..."
Abstract
- Add to MetaCart
this document is to: . Specify the NFS version 3 protocol . Describe semantics of the protocol through annotation and description of intended implementation . Specify the MOUNT version 3 protocol . Briefly describe the changes between the NLM version 3 protocol and the NLM version 4 protocol. The normative text is the description of the RPC procedures and arguments and results, which defines the over-thewire protocol, and the semantics of those procedures. The material describing implementation practice aids the understanding of the protocol specification and describes some possible implementation issues and solutions. It is not possible to describe all implementations and the UNIX

