MD5 is an authentication algorithm proposed as the required implementation of the authentication option in IPv6. This paper presents an analysis of the speed at which MD5 can be implemented in software and hardware, and discusses whether its use interferes with high bandwidth networking. The analysis indicates that MD5 software currently runs at 85 Mbps on a 190 Mhz RISC architecture, a rate that cannot be improved more than 20-40%. Because MD5 processes the entire body of a packet, this data rate is insufficient for current high bandwidth networks, including HiPPI and FiberChannel. Further analysis indicates that a 300 Mhz custom VLSI CMOS hardware implementation of MD5 may run as fast as 256 Mbps. The hardware rate cannot support existing IPv4 data rates on high bandwidth links (800 Mbps HiPPI). The use of MD5 as the default required authentication algorithm in IPv6 should therefore be reconsidered, and an alternative should be proposed. This paper includes a brief description of the...

. Continuous media such as audio and video pose new challenges to all parts of multipurpose operating systems. We discuss issues related to CPU scheduling, memory allocation, system support and application environments and summarize some of the solutions proposed in the literature. Key words: Continuous media { Operating system enhancement { CPU scheduling { Network implementation 1 Introduction Operating systems play a crucial role in supporting multimedia applications. Here we investigate the problems that are introduced by multimedia and some approaches to their solution. General introductions to operating systems can be found in (Tanenbaum 1987; Peterson and Silberschatz 1983), with specic surveys of the UNIX operating system in (Lefer, McKusick, Karels, and Quarterman 1988; Bach 1986). Although only a combination of network and operating system design can guarantee performance, network issues seem to have required far more attention in the past. As higherspeed LANs touting integ...

... This paper analyzes several programs and pro-gramming techniques to understand the performance implications of different pointer sizes. Many (but not all) programs show small but definite performance consequences, primarily due to cache and paging effects.

The Profile Collection Toolkit (PCT) provides a novel generalized CPU profiling facility. PCT enables arbitrarily late profiling activation and arbitrarily early report generation. PCT usually requires no re-compilation, re-linking, or even restarting of programs. Profiling reports gracefully degrade with available debugging data. PCT uses

Performance can be a critical aspect of software quality; in some systems, poor performance can cause financial loss, physical damage, or even death. In such cases, it is imperative to identify system performance problems before deployment, preferably well before implementation. Unfortunately,

It is important to understand performance aspects of a computer system from the software architecture and its configurations. For a system that has various possible configurations, the performance analysis will become difficult. This thesis describes a compositional model-building approach which is useful when there are many possible configurations. This approach is based on assembling the sub models and is demonstrated in a network software router, CGNet.

Performance analysts profile their programs to find methods that are worth optimizing: the “hot ” methods. This paper shows that four commonly-used Java profilers (xprof, hprof, jprofile, and yourkit) often disagree on the identity of the hot methods. If two profilers disagree, at least one must be incorrect. Thus, there is a good chance that a profiler will mislead a performance analyst into wasting time optimizing a cold method with little or no performance improvement. This paper uses causality analysis to evaluate profilers and to gain insight into the source of their incorrectness. It shows that these profilers all violate a fundamental requirement for samplingbased profilers: to be correct, a sampling-based profiler must collect samples randomly. We show that a proof-of-concept profiler, which collects samples randomly, does not suffer from the above problems. Specifically, we show, using a number of case studies, that our profiler correctly identifies methods that are important to optimize; in some cases other profilers report that these methods are cold and thus not worth optimizing. C.4 [Measurement tech-