Claypool

Courses

Publications

Students

Projects

Service

Downloads

Misc

Quality

 

There is an old network saying: ``Bandwidth problems can be cured with money. Latency problems are harder because the speed of light is fixed - you can't bribe God.'' David Clark, MIT.

So far we have explored the necessary network, disk, and CPU requirements to completely satisfy our user requirements. But when user requirements cannot be completely satisfied, there is often a tradeoff in system choices. For example, if more compression is applied, bandwidth requirements for network and disk are reduced, but the CPU may become overloaded with the added decompression cost. One quantitative trade-off measure may be in terms of the application quality.

We have identified three components that influence application quality. There may be others:

• Latency. The time it takes the server to start processing a 3D image until the time the client displays the 2D frame we call latency.
• Jitter. Distributed applications on packet-switched networks invariably have variable packet inter-arrival times, causing gaps in the stream playout [5]. We call these gaps jitter. Jitter can be reduced or eliminated by buffering ahead in the data stream. When a packet arrives late, the next frame is already in the data buffer and no gap appears in the playout stream. The buffer size must be carefully chosen. Too large a buffer, and latency becomes intolerable. Too small a buffer, and there is jitter. There have been several heuristics used to determine buffer size with audio [17], but [6] has shown that none of these heuristics can control playout quality under all packet arrival distributions. In addition, choosing the right data to buffer can be extremely difficult for some applications. For flying, buffering may be done along a well-known neural pathway in anticipation of the user following it. However, in the event that the user turns away from this pathway, the server would have to send additional data to re-establish the buffer.
• Data Reduction. In order to reduce latency and/or jitter, or to reduce processor loads, an application may voluntarily accept some data reduction. Such reduction can take many forms, from reduced color, to jumbo pixels and smaller images to dropped frames.

Kleinrock and Naylor suggest a quality metric for audio streams based on jitter and latency [11]. We define the quality of our application based on latency, jitter and data reduction. We form our quality metric by assigning units and relative weights to each component. Using each component as one axis, we create a 3-dimensional quality space. One configuration of an application lies at one point in this space. The quality of the application can be computed by taking the Euclidean distance of the point from the origin. By assigning a weight of ``1'' to the upper bound of acceptability along each axis, we can create an acceptable quality plane of all points that have a quality of 1; all points inside the curve (towards the origin) will have acceptable quality while points outside will not.

Our model does not support jitter predictions yet. Jitter is difficult to model in visualization domains because the data are non-linear. Users may move in different directions at any time, making buffering difficult. Thus, in creating our model for application quality we consider only latency and data reduction.

We chose an equal weighting of milliseconds of latency and Mbits/second of data reduction. We assume more than 250 milliseconds of latency to be unacceptable, a level of tolerability suggested by other applications [6]. We also assume fewer than 20 Mbits/second of data provides too little data to be useful, and more than 720 Mbits/second (30 frames/second and 24 bits of color) provides no more useful data. Our quality is the Euclidean distance from the origin normalized over 250 milliseconds and 700 Mbits/second.

Figure 10 depicts our measure of quality. The individual points are all SGI Indigo 2 clients with a different number of processors. In this figure, we have not assumed any specialized flying hardware. We assume that the servers will be able to provide the bandwidth requested by all the clients to simplify the computation.

 

 

Figure: Client Application Quality. A measure of quality for the client. The horizontal axis is the number of Mbits/second of data reduction received by the client. The vertical axis is the latency added by the client. The points are SGI Indigo 2's clients with different numbers of processors. The curve represents an acceptable level of quality; all points inside the curve will have acceptable quality while points outside will not. Note that the clients are not equipped with any special flying hardware.

Figure 11 depicts quality versus the number of clients for both flying with compression and without. Clients are assumed to be 20 processor Indigo 2's without specialized hardware. The server is assumed to be an SGI Indigo 2 workstation with specialized hardware (see Section 7). The arrows indicate points at which the server can no longer keep up with the bandwidth requests by the clients. At this point, application performance decreases, as depicted by the increasing quality values. Thus, for fewer than 4 clients, compression decreases client-side quality, mostly because of the latency increase from the clients decompressing the images. However, for 5 or more clients, compression increases application quality because the server can meet the bandwidth requirements of more clients.

 

 

Figure: Quality versus Clients. Clients are 100 processor SGI Indigo 2 workstations with no specialized hardware. The server is an SGI Indigo 2 workstation with specialized hardware (see Section 7). The arrows indicate points at which the server can no longer keep up with the bandwidth requests by the clients. At this point, perceived application performance decreases, as depicted by the increasing quality values.

Note that this graph depicts the quality tradeoffs with one particular system configuration. Different system configurations may have different quality tradeoffs.