1.0 Introduction

FIGURE 1. Distributed Design System: the "Hollow Client" Approach.

In this new distributed environment, the means of achieving high performance for the user will change from those currently used for "centralized" uniprocessor systems, as the bottlenecks in the system will be different. The interaction between the client machine and its data will be across wide-area networks, as opposed to local networks or LANs, and the most frequent tasks performed locally on it will change. There are several aspects of the system that can be examined to improve performance:

• Improving the network bandwidth and latency:

  A problem that will be dealt with on a national or global scale.

• Determining the appropriate partition of tasks:

  Finding which processes to migrate to the client and which to keep on the servers for a given application is critical to performance, and it must be adaptable to the computing power of the client (and the servers), and the network bandwidth.

• Appropriate caching on the client's memory system:

  Data behavior and lifetimes on the client have to be examined to optimize the client's operating system caching policies, as well as memory system sizes and configurations.

• Appropriate communication protocols between the client and server sides:

  Applications must be written with the network in mind. The client side of the application must communicate with the server side in such a way that the dependence on the network bandwidth is minimized.

• Optimizing the execution of the hollow client's most frequent tasks:

  The set of operatoins to become most commonly executed on the client must be examined, and the client processor architecture can be optimized toward them.

In this project, we traced a number of graphical editing/displaying applications that represent some of tomorrow's interactive display/edit portions of distributed applications. We determined the number of instructions and execution time involved in completing each of these operations. Given our speculations about tomorrow's typical microprocessor architecture, we derived a lower bound on the rate of execution (MIPS) required for the hollow client. We also explored the dynamic instruction mixes and searched for special optimization features to which they might lend themselves. In addition, as many of these operations involve network access, we examined the conditions required to minimize the impact of the network, whereby the above MIPS lower bound is the dominant factor in the ability of the client processor to perform the common operations in real-time. We estimated the ranges of average transfer data sizes and tranfser (comunication) frequencies over the Net that would allow real-time response at the client, given sufficient client processor performance.

In the sections that follow, we describe the work on which we based our study, and the approach we took to find our results. We then provide validation for our methodology, present the results, followed by our conclusions and thoughts on future work to be done.

2.0 Related Work

Next, we explored the performance issues related to the World-Wide-Web[4], for it is seen as the medium through which the hollow client will interact with its applications and data, for its ubiquity, flexibility and allowance for platform independence. We have found that the bottleneck is in the Network bandwidth as expected. We also saw that an effective way in improving performance with a Web server is to limit simultaneous client requests, which supports our rejection of the X terminal. We also leanred that web server performance is highly sensitive to average file size transfered. In addition, a study on the HTTP network transfer protocol for the Web[5] showed us that its current version is inefficient, as it uses excessive network interaction for bring up a web page with images or other media in it. As a result, all indications were favoring the inclusion of any real-time functions of an application in the set of operations run locally on the hollow client.

3.0 Technical Approach

3.1 Finding the right computing resourses and tracing tools

To give our traces more generality, we traced our applications on multiple RISC workstations in our CAD group cluster: a dec alpha, two dec mips, sgi mips, and a sun sparc, see Appendix A for architecutural information on the machines. For the former three types of machines, we used Pixie, and for the Sun, a program called "ifreq" from Shade was the only one that gave the traces we needed.

3.2 Selecting the Hollow Client common operations to trace

1. Editing: drawing lines, placing objects, moving objects, poping up or closing windows, and 2-dimensional panning or zooming.

2. Immersive Navigating: panning/zooming (3D rendering) and animations.

3. Input/Output (Network Access): browsing documents and loading/saving of data.

3.3 Tracing the Hollow Client operations

3.3.1 Tracing graphical and 3D tools and the X server

3.3.2 Tracing network access and exploring the impact of the network

To characterize the impact of the network on those operations that involved network access, we wrote a small client/server program (pair of programs) that mimic what we see as a suitable data transfer protocol. Eventhough our traces from Mosaic gave us information on loading up data from the nework and displaying it, we were apprehensive about restricting our network access tracing to a tool that uses an old vesion of the HTTP protocol, which is supposedly wasteful in network traffic. We also wanted to define a region in which our average transfer data size used (representing html pages or java applet sizes), and average frequency of accessing the network allowed by the client processor to remain busy enough doing local processing and not waiting on the network, and hence working in the region where the MIPS lower bound on the processor is the govering factor in the feasibility of the client processor. We did so by using the client/server program to repeatedly send/receive a certain size file, using a range of file sizes, and adding a variable number of register-register instructions in between each network access. For each iteration, we measured the instruction count as well as the execution time.

3.3.3 Isolating the operations' trace information from the applications traced

3.4 Evaluating the Hollow Client traces

3.4.1 Determining the lower bound on the hollow client performance

3.4.2 Comparing the hollow client typical instruction mix with that of typical RISC

4.0 Design Rationale

This lower bound for this future "network computer" can be estimated with sufficient accuracy by examining current tools run on current machines, because we believe RISC architecture will be the baseline for processor design in the near future which has a more standardized design than before and the next leap in architecture technology not forseen to take place anytime in the near future. Hence, using instruction counts from traces of today's machines directly to compute the execution rate of the hollow client is a good approximation, especially if multiple instruction set architectures are traced and normalized to a generic one.

Another design decision we made is the choice of tools we traced to mimic the hollow client's most frequently executed functions. It is obvious that the means of communication is getting to involve more than just plain text as a medium. With greater and cheaper computing power, more graphics and multi-media will be employed in design and communication. For that reason, we chose a number of tools that have graphics and 3D immersive capabilities. To add accuracy to the traces, we were able to instrument the X server and trace it along with the applications run on it, thus capturing the full set of operations we see as those executed locally on the client.

Finally, as we noticed that the time and instruction count involved with doing loads, saves, and other network interactions are highly dependent on the network transfer protocol, transfer data size, and frequency of network transfer. We believe we were able to overcome that variablility by defining the premises under which the network dependence is minimized. But also, by doing that, we discovered some interesting results about the performance of network access operations as transfer data size vary as well as the number of instructions inserted between each network access.

5.0 Technical Results and Analysis

5.1 Exploring the dynamic instruction mix of the common operations

5.1.1 Dynamic Instruction Frequencies

FIGURE 2. Dynamic instruction frequencies of editing and navigating operations.

FIGURE 3. Dynamic instruction frequencies of network access operations.

The instruction mixes we obtained are similar to a typical RISC instruction mix, which allows us to use a simple timing model for the hollow client to derive its performence requirements. For network access traces, we noticed that the performance is highly sensitive to the file transfer size, so we used only file sizes that have been confirmed to be small enough for real-time performance not to be effected by the network, as shown in our study in Section 5.2. We also made sure the sizes would be small enough to fit in all the machines' caches (worst case, 16KB), so as to minimize the effect of the memory system.

5.1.2 Minimum MIPS requirements to achieve real-time performance

FIGURE 4. Instruction count for each common operation type.

FIGURE 5. Execution time for each common operation type.

We can estimate the average CPI (clock cycles per instruction) of the hollow client with the following timing model: given the averages of instruction frequencies (F_i) in Figur 2 and Figure 3, along with our estimate of instruction latency (CPI_i)for each of the main instruction classes, the average CPI be calculated. Our knowledge of well-designed machines such as the MIPS R4400 or Alpha and of that of the textbook RISC processor gives us estimates for average CPI's for each instruction type. For integer ALU, we can assume a 2-4 way superscalar setting, which would result in an average latency of ~.65. Loads and Stores should take about 1 plus an overall estimate of miss penalty of about ~.3 clks. Branches will be very ewell predicted, with about 5% misprediction in worst case, and with very little miss penalty. The floating point unit, which seems necessary as part of a hollow client machine, if graphics are to be a regular part of the operations employed by users. A normal latency per fp operation is about 4 clks, but due to pipelining and since they come in clusters, a better estimate would about 3 clks. We will use the latencies in following table in the CPI equation below:

5.1.3 Instruction-level Parallelism

FIGURE 6. Percentage of loads followed by loads for each kind of common operations.

FIGURE 7. Average basic instruction block size for each kind of common operations.

FIGURE 8. Percentage of parallelizable ALU instructions for each kind of common operations.

Figure 6 shows us that we do have more Load instruction parallelsim on the hollow client than on the typical RISC machine, but an average rate of such an opportunity of 6-7% does not offset the increased cost in complexity of including an additional Load unit in the processor. We do however see that there is certainly more integer ALU parallelism, especially for 3D grahpics applications, and that will be a good optimization feature to consider. In fact, machines that will have emphasis on graphics and multi-media seem to be prime targets for the employment of a special set of integer instructions, called packed instructions, that perform on arrays of small integers in parallel (e.g. 8 8-bit integers) for tasks related to problems of finite size such as the monitor screen, a certain resolution of an image, etc.

5.2 Impact of the Network

5.2.1 Effect of Data Transfer Size on Performance of Network Access Operations

To achieve the goal, we measured the execution time and number of instructions executed to transfer different sizes of data on three machines(see Figure 9 and Figure 10).

FIGURE 9. Execution time (in ms) per file transfer for different file sizes (in bytes) on Dec Alpha, Sun Sparc, and Dec MIPS (in log-log scale).

FIGURE 10. Number of instructions (in kilo) per file transfer for different file sizes (in bytes) on Dec Alpha, Sun Sparc, and Dec MIPS (in log-log scale).

From the figures, we see that for transfers up to file size ~150 bytes, the execution time and instruction count for each transfer is at its minimum, determined by the transmission protocol, not the transfer file size. After that point, both the execution time and instruction count increase linearly with the file size. We can see that given our 500ms limit on response time to execute a page load into a browser (or design query system) imposes a pure upper limit on data transfer size, at up to ~50KB, permissible by the hollow client to perform interactive updates. With current transfer protocols, it seems that a minimum execution latency (about 10K instructions/transfer) is required for any transfer up to around 150 bytes, in order to relieve the file transfer time from dominating the execution time of loading up, say, a web page.

5.2.2 Effect of Network Access Frequency on Network Access Performance

FIGURE 11. Execution time per iteration (in ms) for different file sizes (in bytes) and different number of instructions between file transfers (in kilo) on a Dec Alpha.

FIGURE 12. Execution time per iteration (in ms) for different file sizes (in bytes) and different number of instructions between file transfers (in kilo) on a Dec MIPS.

FIGURE 13. Execution time per iteration (in ms) for different file sizes (in bytes) and different number of instructions between file transfers (in kilo) on a Sun Sparc.

From the figures, we can see the flat region at the bottom of the curves indicate the bound an upper bound on the average file transfer size to use, along with a lower bound on the number of instructions to execute between network accesses to relieve the client of network dependence for performance. It seems that the size can of up to about 5Kbytes, and with at least 200K instructions, if the execution time per file transfer is to remain dominated by non-network activities (the local integer instructions) on the hollow client. When the data transfer size gets larger than the point, the network latency dominates the execution time even when the access frequency is high (large instruction block size). So, thee MIPS lower bound we have established on the local operations of the hollow client will only be an issue to consider if working under conditions similar to those in the lowest region in Figure 11.

6.0 Future Work

7.0 Summary

• Response time for such operations seems to govern the performance requirements on the client whenever the network or the memory system do not.

• Using a RISC architecture, with a target response time for the common interactive operations, similar to that of today's low-end workstation (Dec MIPS), the hollow client processor is required to have larger than 50 MIPS performance, assuming an ideal memory system and high-bandwidth network.

• A useful optimization on the client processor would be to exploit the additional (10-20%) parallelism of integer instructions seen on the common operations.

• The network bottleneck can be alleviated if the size and rate of network transfers are both limited, meaning having less than 5-10KB per transfer and more than 200K instructions between transfers.

8.0 Appendix A: Machines informaton

9.0 Appendix B: Dynamic Instruction Stream Measurements

10.0 References

[1] The WELD Distributed Design Intergration System: UC Berkeley CAD Group
Advisor: Prof. Richard Newton.
http://embedded.eecs.berkeley.edu/Respep/Research/dds

[2] Baker, Wendell, "WELD--The Hollow Client Approach": UC Berkeley CAD GRoup,
Advisor: Prof. Richard Newton.
http://www.eecs.berkeley.edu/~wbaker/arpa96/03-review/weld.html

[3] Socarras, A.E.; Cooper, R.S.; Stoneycypher, W.F. "Anatomy of an X terminal." IEEE Spectrum, March 1991, vol.28, (no.3):52-55.

[4] Slothouber, Louis P., "A Model of Web Server Performance"
http://louvx.biap.com/white-papers/performance/overview.html

[5] Spiller, Mark D., "HTTP vs. FTP", school project paper
http://www.eecs.berkeley.edu/~mds/java/http.html

[6] Architecture Tracing Tools
http://www.cs.Berkeley.edu/~xjiang/cs252TA.html

[7] Smith, Michael, "Tracing with Pixie", Center for Integrated Systems, Stanford Unversity.
http://http.cs.Berkeley.edu/~gnguyen/cs252/F94/pixie/pixie_manual.ps

[8] Sparc Architectural Simlulator "SimOS". CAD Group, Stanford university
http://powderkeg.Stanford.EDU:80/~herrod/SimOS

[9] Mittal, Alok, "Benchmarking for Graphics Applications", CS252 Project
Report. http://http.cs.Berkeley.edu/~alok/acad/cs252_project.html

[10]Edwards, Stephen,"States" FSM Editing tool, UC Berkeley CAD Group
http://ptolemy.eecs.berkeley.edu/~sedwards/research.html

[11]Shilman, Michael, "InteractND--a 3D VRML Browser", UC Berkeley CAD Group
http://www.eecs.berkeley.edu/~michaels/research/InteractND