This chapter explains the overall architecture of OpenGL Vizserver 3.x, how to measure and monitor OpenGL Vizserver performance, and how to estimate the network bandwidth required by OpenGL Vizserver. The following topics are covered:
Tuning generally implies matching the system capacity and your workload to get a better performance from your system. You can change the system hardware or software to match the workload or you can reduce the workload to match the system.
So why do we need tuning? Many answers are possible, but they can be summarized as follows:
Isolate and understand performance behavior
Use resources more efficiently
Understand performance bottlenecks
Get a better performance
There are many components that you can tune, depending on your needs on the system. This chapter discusses the tuning issues on OpenGL Vizserver only.
To extract top performance from a system, it is important to understand the architecture of the system. The next section describes the architecture of the OpenGL Vizserver system.
The overall diagram of OpenGL Vizserver is shown in Figure 3-1.
The following steps describe how the OpenGL Vizserver components work from the point that a user connects to OpenGL Vizserver to the point that the user logs out of the OpenGL Vizserver server after running the application under OpenGL Vizserver.
For detailed instructions on how to use the OpenGL Vizserver client GUI, see the OpenGL Vizserver User's Guide.
OpenGL Vizserver provides two types of sessions: single-user sessions and collaborative sessions. Single-user sessions involve one client user using graphics pipes on the OpenGL Vizserver server. Collaborative sessions allow multiple distant users, one of them being a master and the rest of them being nonmasters, to display and interact with the same application in real time.
The following steps describe running a single session:
The server manager (vsserver) is started as a daemon and listens for client's incoming connections.
The OpenGL Vizserver client program (vizserver) calls the server with a hostname.
vsserver replies.
vizserver sends the authentication data (usually user's login name and password).
vssserver dynamically loads an authentication module and verifies the user.
If the user is authenticated to vsserver, the Start Session, Join Session, and Log out buttons in the client GUI (vizserver) become active.
The user presses the Start Session button and chooses a Single-User session type in a Session Start window. The user chooses other initial configuration options if necessary.
vsserver allocates the requested number of graphics pipes and launches a session process.
vssession initializes the allocated graphics pipes and calls a session script.
vizserver presents an OpenGL Vizserver Session Control window and an OpenGL Vizserver Console window to the user.
The user launches applications on the OpenGL Vizserver Console window displayed on the client. The component libvsx.so is loaded by the applications and handles some X11, GL, and GLX calls by overriding them.
vssession captures the images rendered by the applications, compresses the images, and transmits them to the remote client.
The user presses the Stop Session button to end the session after running applications.
The user presses the Log out button to log out from the OpenGL Vizserver server.
There are two types of collaborative sessions: local and remote. A local collaborative session is a session that involves a local client on the server running an X server and multiple remote clients to work together on the same application. A remote collaborative session is a session that involves a remote client starting a session and multiple remote clients working together on the same application. Whoever starts a session becomes the master of the session. In local collaborative sessions, only the local client can start a session.
The following steps describe running a collaborative session. Steps 1 to 6 are the same as running a single-user session:
The server manager (vsserver) is started as a daemon and listens for client's incoming connections.
The OpenGL Vizserver client program (vizserver) calls the server with a hostname.
vsserver replies.
vizserver sends the authentication data (usually user's login name and password).
vssserver dynamically loads an authentication module and verifies the user.
If the user is authenticated to vsserver, the Start Session, Join Session, and Log out buttons in the client GUI (vizserver) become active.
The user presses the Start Session button and chooses a Collaboration session type and types the session's name in a Session Start window. The user who starts the session becomes the master of the session.
vsserver distinguishes whether the session is local or remote and allocates the requested number of graphics pipes for a remote collaborative session and launches a session process. For a local collaborative session, vsserver just uses the number of graphics pipes that are already allocated to a currently running X server.
vssession initializes the allocated graphics pipes and calls a session script. For local collaborative sessions, vssession does not initialize the graphics pipe.
vizserver presents an OpenGL Vizserver Session Control window and an OpenGL Vizserver Console window to the master.
The master launches applications on the OpenGL Vizserver Console window or waits for the other users to join the session. When the applications are launched, libvsx.so is loaded and handles some X11, GL, and GLX calls by overriding them.
vssession captures the images rendered by the applications, compresses the images, and transmits them to all the clients in the session. For local collaborative sessions, vssession does not compress the images and sends them to the local client, that is, the master.
To join the session, a user completes steps 1 through 6 and then presses the Join Session button and fills in the Session Name field in a Session Join window.
vsserver sends the message to the master of the requested session to ask whether or not the master accepts the request.
If the request is approved by the master, vsserver sends the message to vssession to accept the user (nonmaster) joining and also notifies all the clients that participated in the session that a new user has joined.
The nonmaster presses the Leave Session button to leave the session and the session continues. If the master leaves the session, the session is stopped.
Each user presses the Log out button to log out from the OpenGL Vizserver server.
OpenGL Vizserver consists of client-side components and server-side components.
Client Process (vizserver):
Basic GUI for the user.
Initiates a connection to a server.
Reads the compressed image from the server and decompresses it using a decompression module.
Displays the decompressed images.
Server manager (vsserver):
A daemon process running on the server.
Keeps configuration parameters and provides them to other components in the system.
Waits for an initial connection from clients.
Responsible for launching vssession after user's authentication.
Allocates the number of graphics pipes the user requests.
Responsible for handling different types of sessions and joining in collaborative sessions.
Session manager (vssession):
Captures the images rendered by the application.
Compresses the images using a compression module.
Transmits them to remote clients.
Receives keyboard or mouse events from clients and transfers them to the application.
libvsx.so:
Transparent interface library.
Loaded by the application and overrides some X11, GL, and GLX calls.
Keeps track of the application windows' creation and destroys and notifies vsssession, which keeps track of the application window.
Catches glFlush(), glFinish(), and glXSwapBuffers() to make vssession grab the framebuffer contents.
vsconfig:
A GUI for the OpenGL Vizserver server's configuration.
Starts and stops the vsserver process.
vsadmin:
A simple command-line administration tool for checking and managing active client connections.
Reservation web interface:
Performance monitoring module:
There are different tuning objectives, depending on your situation and various tuning options.
Since OpenGL Vizserver reads the framebuffer images and sends them to the client, there are several important factors that affect the OpenGL Vizserver performance.
Capturing framebuffer image
Compressing the image
Transmitting the image to the client
Decompressing the compressed image at the client side
So OpenGL Vizserver tuning objectives are the following:
Maximum network bandwidth
Maximum frame readback rate
Minimum frame drop rate
Minimum network latency
These objectives allow the user in a remote client to feel that the application is running locally on a huge, powerful graphics machine.
It is important to understand how your system is configured and what the system capacity is, such as number of CPUs, memory size, number of graphics pipes, and so on, when you measure the application or system performance.
Not all applications require the same amount of system resources. So, determine the application that you use most and how many applications will be used at the same time. Also, determine the acceptable response time for interactive users.
If an application oversaturates most of the system resources and shows a poor performance while not running on OpenGL Vizserver, there will be no performance improvement running it with OpenGL Vizserver. Measure the application performance locally and try to get a better performance from the application itself first before running it with OpenGL Vizserver.
SGI provides a collection of monitoring tools that can be used with applications: top, sar, osview, gr_osview, timex, Performance Co-Pilot (PCP), and so on. Each monitoring tool provides different performance metrics and features. So, it is also important to choose the right tools for monitoring your application.
When measuring the application performance, you can launch the application and the monitoring tools together or use cron to get the performance data over a period of time.
The timex utility is good at determining the source of the problem. It reports how a particular application is using its CPU processing time. The following will show real, user, and system time spent executing your application:
timex your_application |
When used with the -s option, timex reports total system activity that occurred during the execution interval of your application.
The osview and gr_osview utilities dynamically display various parts of the operating system's activity data. If you have a graphics workstation, you can use gr_osview. You can configure gr_osview to display several different types of information about your system's current status.
The sar utility reports the system's activity by category and essentially the same information as osview, but it also represents a snapshot of the system status. This utility is useful for monitoring system usage over a period of time to determine bottlenecks and system resource limitations.
sar [options] [interval] [samples] |
It has options that allow sampling of a different category, such as CPU utilization (-u option) or graphics activity (-g option). Each option displays the data differently.
The command in the following example prints information about graphics activity 10 times at 5 second intervals.
$ sar -g 5 10 16:24:50 gcxsw/s ginpt/s gintr/s fintr/s swpbf/s 16:24:55 0 2 72 5 0 16:25:00 0 0 72 2 0 16:25:05 0 0 72 2 0 16:25:10 0 0 72 2 0 16:25:15 0 1 72 3 0 16:25:20 3 37 72 39 0 16:25:25 0 40 72 13 0 16:25:30 0 36 72 8 0 16:25:35 1 13 72 35 0 16:25:40 1 51 72 45 0 Average 1 18 72 15 0 |
It is also useful to take a snapshot of your system activity before and after an application, as shown in the following example:
/usr/lib/sa/sadc 1 1 report_file run your_application /usr/lib/sa/sadc 1 1 report_file sar -A -f report_file |
For more information about these monitering tools, see their respective man pages.
Network bandwidth between two systems can be measured easily by using ttcp. The ttcp tool can be used to time the transmission and reception of data between two systems using the TCP or UDP protocols.
For testing, the receiver should be started first, with -s and -r options, and the transmitter later, with -t and -r options. The -t option means to start in transmit mode and the -r option means to start in receive mode.
To test TCP, use the following commands:
On the receiving host: /usr/etc/ttcp -r -s
On the transmitting host: /usr/etc/ttcp -t -s receiving host
To test UDP, use the following commands:
On the receiving host: /usr/etc/ttcp -r -s -u
On the transmitting host: /usr/etc/ttcp -t -s -u receiving host
Example 3-1 shows the testing of TCP performance from a server (rampage) to a client (o2-alto).
Example 3-1. Testing TCP Performance between Two Systems by Using ttcp
Enter the command from a receiving host (o2-alto).
o2-alto:~> /usr/etc/ttcp -r -s ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp ttcp-r: socket
Enter the command from a transmitting host (rampage).
rampage:~> /usr/etc/ttcp -t -s o2-alto ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp -> o2-alto ttcp-t: socket
After pausing, the results, similar to the following, are displayed on each host:
In o2-alto:
ttcp-r: accept from 130.62.46.200 ttcp-r: 16777216 bytes in 1.58 real seconds = 10340.35 KB/sec +++ ttcp-r: 3775 I/O calls, msec/call = 0.43, calls/sec = 2382.50 ttcp-r: 0.0user 0.3sys 0:01real 23% 20maxrss 0+0pf 3583+326csw
In rampage:
ttcp-t: connect ttcp-t: 16777216 bytes in 1.58 real seconds = 10373.98 KB/sec +++ ttcp-t: 2048 I/O calls, msec/call = 0.79, calls/sec = 1296.75 ttcp-t: 0.0user 0.2sys 0:01real 15% 936maxrss 0+0pf 1369+493csw
Here we can see that network bandwidth from rampage to o2-alto is 10,340 KB/s.
There are other tools to use for measuring the network traffic.
ping : To test the network access layer
netstat -s : To view the configuration
ifconfig -a : To see the status for all interfaces on the machine
traceroute : To test the Internet layer
OpenGL Vizserver total performance is affected by many factors, including the graphics framebuffer image readback rates, CPU speeds on both OpenGL Vizserver server and client for compression/decompression and network bandwidth.
The main purpose of monitoring OpenGL Vizserver performance is to find performance bottlenecks and ensure that an application running under OpenGL Vizserver gives the same performance as the application running locally on a huge graphics machine without using OpenGL Vizserver.
It is assumed that your application is already optimized and runs reasonably well in the current system configuration. To monitor OpenGL Vizserver performance, you can use various system tools, mentioned in “Measuring the Application Performance Locally”. However, with the values from these tools, it is difficult to understand how OpenGL Vizserver performs.
Starting with the OpenGL Vizserver 3.0 release, a Performance Co-Pilot (PCP) OpenGL Vizserver Performance Metrics Domain Agent (PMDA) module and a text-based tool, vsmonitor(1m), are available. They are easy to use and useful to monitor the performance of each stage in the OpenGL Vizserver pipeline.
Performance Co-Pilot (PCP) is an SGI product designed for monitoring and managing system-level performance. It provides a system-level suite of tools that cooperate to deliver distributed and integrated performance management services.
To use PCP OpenGL Vizserver PMDA to monitor OpenGL Vizserver performance, you need to install at least pcp_eoe.sw.eoe and pcp_eoe.sw.monitor in your system. The base pcp_eoe product is included in your IRIX 6.5 CD set and can be run without licenses. If you want more fully covered PCP services, you will need to install pcp, which requires PCP licenses.
To learn more about Performance Co-Pilot, see the following URL:
PCP OpenGL Vizserver PMDA acts as a gateway between a collection of performance data from the OpenGL Vizserver server and the Performance Metrics Collection Daemon (PMCD). PMCD acts as a mediator between PCP monitoring tools and PCP OpenGL Vizserver PMDA.
Once OpenGL Vizserver PMDA is installed, the performance data from the PMDA becomes available immediately to all monitoring tools that connect to the PMDA process (pmcd). The PMDA can also be added or removed while pmcd continues operation.
To use OpenGL Vizserver PMDA, vizserver_server.modules.perf should be installed on your system. OpenGL Vizserver PMDA files are located in the /var/pcp/pmdas/vizserver directory and the executable image for OpenGL Vizserver PMDA is /var/pcp/pmdas/vizserver/pmdavizserver, using domain number 222.
Starting a pmcd process automates the start of OpenGL Vizserver PMDA. Start the pmcd process by entering the following commands:
# chkconfig pmcd on # /etc/init.d/pcp start |
If pmcd is already running on your system, the above command will stop and restart the pmcd process.
If you have problems running pmcd, see the Performance Co-Pilot User's and Administrator's Guide.
You can also start OpenGL Vizserver PMDA without restarting the pmcd process. Go to the /var/vizserver/pmdas/vizserver directory and run the Install script. Choose both the collector and the monitor installation configuration options. Everything else is automated. If you still enounter problems, see the README file in the directory.
# cd /var/pcp/pmdas/vizserver # ./Install You will need to choose an appropriate configuration for installation of the "vizserver" Performance Metrics Domain Agent (PMDA). collector collect performance statistics on this system monitor allow this system to monitor local and/or remote systems both collector and monitor configuration for this system Please enter c(ollector) or m(onitor) or b(oth) [b] both Updating the Performance Metrics Name Space (PMNS) ... Compiled PMNS contains 357 hash table entries 1533 leaf nodes 239 non-leaf nodes 15974 bytes of symbol table Installing pmchart view(s) ... Terminate PMDA if already installed ... Installing files ... Updating the PMCD control file, and notifying PMCD ... Check vizserver metrics have appeared ... 23 metrics and 47 values |
After the successful installation, you can see that the PMCD configuration file (pmcd.conf) has the OpenGL Vizserver PMDA as an entry.
$ cat /etc/pmcd.conf # Name Id IPC IPC Params File/Cmd irix 1 dso irix_init libirixpmda.so pmcd 2 dso pmcd_init pmda_pmcd.so proc 3 dso proc_init pmda_proc.so vizserver 222 pipe binary /var/pcp/pmdas/vizserver/pmdavizserver -d 222 |
If pcp.sw.base is installed on your system, you can also use pcp to view the summary of PCP installation.
$ pcp Performance Co-Pilot configuration on alto.engr.sgi.com: platform: IRIX64 alto 6.5 10100655 IP30 64 hardware: 1 R10000 cpu, 3 disks, 1 xbow, 256MB RAM timezone: PST8PDT licenses: Collector Monitor pmcd: Version 2.2, 4 agents pmda: irix pmcd proc vizserver |
Once the OpenGL Vizserver PMDA has been successfully installed, you can monitor it using any PCP monitoring tools, such as pminfo, pmval, pmchart, and so on.
The command pminfo displays various types of information about performance metrics. With the -t option, it lists all of the exported metrics and one-line help messages. The -T option shows more verbose help messages. With the -f option, it fetches and prints the values for all instances. See the pminfo(1) man page for more information.
$ pminfo -t vizserver vizserver.nsession [number of ongoing sessions] vizserver.npipe [number of pipes allocated to OpenGL Vizserver] vizserver.period [sampling duration(sec)] vizserver.all.readback.rate [average rate(KB/s) of readback] vizserver.all.readback.time [average time(ms) spent on readback at each frame] vizserver.all.compress.rate [average rate(KB/s) on compression for all sessions] vizserver.all.compress.time [average time(ms) spent for compressing a frame] vizserver.all.network.rate [average rate(KB/s) on network transfer] vizserver.all.network.time [average time(ms) spent on writing a frame to network] vizserver.all.frames.total [total number of frames per second] vizserver.all.frames.spoiled [number of spoiled frames per second] vizserver.session.readback.rate [data rate(KB/s) of readback per session] vizserver.session.readback.time [time(ms) spent on readback at each frame per session] vizserver.session.compress.rate [data rate(KB/s) on compression per session] vizserver.session.compress.time [time(ms) spent on compressing a frame per session] vizserver.session.network.rate [data rate(KB/s) on network transfer per session] vizserver.session.network.time [time(ms) spent on writing a frame to network per session] vizserver.session.frames.total [total number of frames per session] vizserver.session.frames.spoiled [number of spoiled frames per session] vizserver.pipe.readback.rate [data rate(KB/s) of readback per pipe] vizserver.pipe.readback.time [time(ms) spent on readback at each frame per pipe] vizserver.pipe.frames.total [total number of frames per pipe] vizserver.pipe.frames.spoiled [number of spoiled frames per pipe] |
OpenGL Vizserver PMDA has 23 metrics as shown in the above example. They specify the characteristics of each stage of the OpenGL Vizserver pipeline. The vizserver.*.time metrics represent the average time spent processing a frame in each stage and the vizserver.*.rate metrics represent the average number of kilobytes per second that get into each stage of the pipeline.
The vizserver.all.* metrics represent the overall data, the vizserver.session.* metrics represent the data per each session, and the vizserver.pipe.* metrics represent the data per each graphics pipe.
To view a detailed description for each of the performance metrics, use the pminfo -T metric command.
The following examples show the number of active sessions and the average data rate and time of the image readback stage in the pipeline per session.
$ pminfo -ft vizserver.nsession vizserver.nsession [number of ongoing sessions] value 3 $ pminfo -ft vizserver.session.readback vizserver.session.readback.rate [data rate(KB/s) of readback per session] inst [0 or "yolee:"] value 12836.378 inst [1 or "guest:"] value 11454.321 inst [2 or "joch:"] value 12372.332 vizserver.session.readback.time [time(ms) spent on readback at each frame per session] inst [0 or "yolee:"] value 12.499605 inst [1 or "guest:"] value 13.661285 inst [2 or "joch:"] value 14.156073 |
The pmchart tool shows the performance metrics against time. It displays the selected metrics in a chart. You can select metrics from the New Plot option from the File menu or predefined view from the Open View option from the File menu. A predefined view for OpenGL Vizserver is the /var/pcp/config/pmchart/Vizserver file.
For more information about how to use pmchart, see the Performance Co-Pilot User's and Administrator's Guide. Figure 3-3 shows an example of using pmchart with OpenGL Vizserver PMDA.
 | Note: The pmchart tool is in the pcp.sw.monitor package subsystem. This tool is not available if you have only pcp_eoe.sw installed on your system. |
The pmval command provides a text-based display of the values for one or more instances of a selected performance metric. For example, the following command shows the values of the performance metric vizserver.session.readback.rate at a 1 second interval.
$ pmval vizserver.session.readback.rate metric: vizserver.session.readback.rate host: localhost semantics: instantaneous value units: Kbyte / sec samples: all interval: 1.00 sec guest: yolee: joch: 1.181E+04 1.597E+04 1.138E+04 1.137E+04 1.588E+04 1.128E+04 1.236E+04 1.625E+04 1.182E+04 1.059E+04 1.523E+04 1.315E+04 1.400E+04 1.449E+04 1.119E+04 1.095E+04 1.301E+04 1.208E+04 1.412E+04 1.542E+04 1.161E+04 1.148E+04 1.593E+04 1.128E+04 |
The vsmonitor tool is text-based and is used to display various performance metrics all together in a current shell window. It reports the current values of all the metrics from the OpenGL Vizserver server every 5 seconds (by default). The period can be changed by using the -f option.
The vsmonitor tool categorizes the performance metrics into three sections: server, sessions, and pipes. A server section displays the average, or sum, of the performance data of currently running sessions. A sessions section shows activity per session. And a pipes section shows activity per pipe.
The read/conv/comp/output times in a server section are averaged values of the currently running sessions and read/conv/comp/output rate and total/spoil frame are the sum of the sessions data.
In Figure 3-4, it shows that the OpenGL Vizserver server rudolph has three sessions running and each session uses one pipe. Session yolee shows the compression rate as 0 bytes and the number of spoiled frames per second at 17.0. This implies the session is currently running with no compression and spoiling turned on and a lot of frames are spoiled. Session joch shows the number of spoiled frame as 0, which means the spoiling is turned off.
See the vsmonitor(1m) man page for more detail description about each performance metric.
Choosing a compression scheme for OpenGL Vizserver is tricky. It requires analyzing multiple properties of the system such as the following:
Network latency
CPU load on the server and clients
Required frame rate
Required image quality
Analyzing these properties allows a more educated choice of compressors. OpenGL Vizserver comes pre-installed with several compression options, each with its benefits and drawbacks. As described in the user's guide, in an OpenGL Vizserver session, all clients connected to the server use the same compression. Therefore, it is important to choose a compressor that suits all connected clients.
There are two competing requirements in an OpenGL Vizserver session: image quality and frame rate. Table 3-1 describes some trade-offs of various compressors:
Table 3-1. Compression Trade-Offs
The performance of JPEG compression varies with the operating system. On Intel, AMD, and Macintosh platforms, certain instruction sets allow signficant acceleration of the compression and decompression process. On other operating systems such as IRIX and SunOS, performance varies by the strength of the machine. The compressors based on the Color Cell scheme are linear in complexity, which results in fast compression and decompression times on most platforms.
Choosing whether to enable or disable ZLIB compression is a matter of bottleneck location. You must weigh the cost associated with compressing and decompressing buffers with ZLIB. If you determine that there is a bottleneck in the communication between the client and server, then ZLIB may help. It reduces the size of the image data sent by a factor of 2 to 5 on average. In this case, the extra computation is worth it and the frame rate will increase. On the other hand, situations where a wide bandwidth exists will not benefit from ZLIB. The additional processing might lower the frame rate.
In most cases, the network bandwidth is a major factor of bottlenecks in the OpenGL Vizserver pipeline. To alleviate this problem, OpenGL Vizserver provides several compression types. However, there is a minimum network bandwidth size needed to use OpenGL Vizserver with reasonably good performance. The application window size and compression rate are also key factors to define the data size in a network transfer.
This section discusses the formula for figuring out how many frames per second are on a given network bandwidth and the formula for estimating how large of a network bandwidth is necessary to get a certain number of frames per second. It is assumed that an entire image is changed in each frame. This assumption is true in a worst case scenario: since the compression modules shipped with OpenGL Vizserver are based on frame differences, the bandwidth requirement is expected to be lower in practice.
A frame is the period of time that it takes to update the display with the new image. For example, a frame rate of 60 Hz means that the display is updated 60 times per second.
In OpenGL Vizserver, a frame size is represented as the size of an application's window, which is handled as an image. An image size is represented as the combination of width, height, and the depth of pixels, as follows:
frame_size = width * height * depth_of_pixel |
If you set the variables of the frame size, width, height, and depth of pixel as follows:
frame_size = f
width = w
height = h
depth_of_pixel = d
You get the following formula, because d is usually 24 bits (3 bytes):
f = d * w * h = 3 * w * h |
Since the network bandwidth between two systems is usually given in units of MB or KB, suppose that the network bandwidth is n KB.
n KB = 1024 * n (KB = 1024) |
Then, the number of frames on a given network bandwidth is the result of network bandwidth divided by a frame size. In other words, the following is true:
(1024 * n) / f = (1024 * n) / (3 * w * h) |
For c:1 compression, you can get c times more compression than no compression. The number of frames per second on a given network bandwith with c:1 compression is the following:
(1024 * n * c) / (3 * w * h) |
For no compression, c is 1.
For example, assume that the network bandwidth, image size, and compression ratio are as follows:
The number of frames per second on a given network bandwidth that OpenGL Vizserver can get is calculated as follows:
(1024 * 10340 * 4) / (3 * 1280 * 1024) ~= 10.77 |
In this example, you can get roughly 10 frames per second.
To estimate the network bandwidth (nKB) required by OpenGL Vizserver when you want to get k number of frames per second, use the formula from the previous section as follows:
k = (1024 * n * c) / (3 * w * h) 1024 * n = (3 * w * h * k) / c |
The preceding implies the following:
n KB = (3 * w * h * k) / c |
For example, if the image size and number of frames per second are given as in the following, calculate the required network bandwidth:
| Image size | 512 x 512 pixels | |
| Compression | No compression | |
| Frames per second | At least 10 frames per second |
The amount of network bandwidth necessary for k frames per second is calculated as follows:
1024 * n = (3 * 512 * 512 * 10) / 1 n = 7680 |
This shows that you need to have at least 7,680 KB/s of network bandwidth.
In order to keep the round-trip latency viewed by the client (for example, the time between moving the mouse and seeing the result on the client side), OpenGL Vizserver uses a frame acknowledgment mechanism at the application level. A client-side environment variable, VS_LATENCY, determines how many frames are allowed to be “in transit” from the session to the client over the network at the same time. This means that if the session has sent VS_LATENCY frames to the client but has not received an acknowledgment from the client that the first frame was received, the session does not send the next frame until the session gets this first acknowledgment from the client.
By default, VS_LATENCY is set to 2. This value is optimal for very low-latency networks, such as an Ethernet-based local area network (LAN). If the network's latency is high, as in a wide area network (WAN), this default value will cause OpenGL Vizserver to utilize the network's bandwidth poorly and to achieve a sub-optimal frame rate.
For example, consider the following case:
| Network bandwidth | 5 Mbyte/sec | |
| Network round-trip latency | 0.3 sec | |
| Typical OpenGL Vizserver frame size | 0.5 Mbyte |
In this case, the best frame rate possible is 10 frames/sec:
5/0.5 = 10 frames/sec |
However, in reality, the default VS_LATENCY value of 2 will reduce the frame rate to approximately 6 frames/sec:
2/0.3 ~= 6 frames/sec |
Setting VS_LATENCY to 3 will increase the frame rate to 10 frames/sec, thus, better utilizing the network:
3/0.3 = 10 frames/sec |
In general, the optimal VS_LATENCY is one that does the following:
Fully utilizes the network bandwidth and the client's capabilities (the least of the two).
Makes sure it does not send frames too fast for the client to process, thus creating high latencies.
A little algebra yields the following formula for calculating the optimal VS_LATENCY value:
VS_LATENCY = min{ ceil[(L+S/B)*C], ceil[1+L*B/S] }
|
The variable items in the formula are defined as follows:
| L | ||
| S | Frame size (bytes) | |
| B | ||
| C | Client processing speed (frames/second) |
The following are some typical network environments:
-
There is practically no latency (L = 0), and the optimal VS_LATENCY value is 1. The default value of 2 might add one frame of latency in this case, but the default value provides more robustness with respect to network bandwidth and latency fluctuations.
A WAN with medium latency, high network bandwidth, and deep compression
In this case, S/B is very small, and the optimal VS_LATENCY value is ceil(L*C). With 300 ms latency, and a client capable of drawing 15 frames/sec, the optimal VS_LATENCY value is 5.
A WAN with very high latency (L = 1000 ms), high network bandwidth, deep compression
The default value of 2 will get you 2 frames/sec, regardless of your bandwidth. If you have high bandwidth (45 Mbit/sec) and a fast client capable of 30 frames/sec, setting VS_LATENCY to 31 will achieve the full 30 frames/sec. Note that there is an inherent 30 frames of latency in such a network, which might make it very hard to use for OpenGL Vizserver sessions.
To summarize, the default value of VS_LATENCY is optimized for LANs. If you run a session over a high-latency network, adjusting the VS_LATENCY value (using the formula just described) might provide considerably higher frame rates.