1

Chromium Renderserver: Scalable and OpenRemote Rendering Infrastructure

Brian Paul, Member, IEEE, Sean Ahern, Member, IEEE, E. Wes Bethel, Member, IEEE, Eric Brug-ger, Rich Cook, Jamison Daniel, Ken Lewis, Jens Owen, and Dale Southard

Abstract—Chromium Renderserver (CRRS) is software infrastruc-

ture that provides the ability for one or more users torun and view image output from unmodified, interactiveOpenGL and X11 applications on a remote, parallelcomputational platform equipped with graphics hardwareaccelerators via industry-standard Layer 7 network proto-cols and client viewers. The new contributions of this workinclude a solution to the problem of synchronizing X11 andOpenGL command streams, remote delivery of parallelhardware-accelerated rendering, and a performance anal-ysis of several different optimizations that are generallyapplicable to a variety of rendering architectures. CRRSis fully operational, Open Source software.

Index Terms— remote visualization, remote rendering,parallel rendering, virtual network computer, collaborativevisualization, distance visualization

I. INTRODUCTION

The Chromium Renderserver (CRRS) is software in-frastructure that provides access to the virtual desktopon a remote computing system. In this regard, it issimilar in form and function to previous works, butprovides important new capabilities driven by contempo-rary needs and architectural opportunities. First, CRRSprovides seamless presentation of rendering results fromboth Xlib and hardware-accelerated OpenGL commandstreams: it is a vehicle for delivering imagery producedby remote, hardware-accelerated rendering platforms.Most previous remote desktop systems are capable ofdelivering imagery produced only by the Xlib commandstream; they typically have no knowledge of or access tothe imagery produced by hardware-accelerated OpenGLrendering. Second, it supports operation on parallel back-end systems composed of either shared- or distributed-memory computers – it is capable of harnessing thecapabilities of a parallel rendering platform for the

B. Paul, K. Lewis and J. Owen are with Tungsten Graphics, Inc.,Steamboat Springs, CO. brian.paul@tungstengraphics.com.

E. W. Bethel is with Lawrence Berkeley National Laboratory.S. Ahern and J. Daniel are with Oak Ridge National Laboratory.E. Brugger, R. Cook, and D. Southard are with Lawrence Liver-

more National Laboratory.

Fig. 1. An unmodified molecular docking application run in parallelon a distributed memory system using CRRS. Here, the cluster isconfigured for a 3x2 tiled display setup. The monitor for the “remoteuser machine” in this image is the one on the right. While thisexample has “remote user” and “central facility” connected via LAN,the typical use model is where the remote user is connected to thecentral facility via a low-bandwidth, high-latency link. Here, we seethe complete 4800x2400 full-resolution image from the applicationrunning on the parallel, tiled system appearing in a VNC viewerwindow on the right. Through the VNC Viewer, the user interactswith the application to change the 3D view and orientation, as wellas various menus on the application to select rendering modes. Asis typically the case, this application uses Xlib-based calls for GUIelements (menus, etc.) and OpenGL for high performance modelrendering.

purpose of generating imagery and sending it to a remoteviewer.

CRRS design and development has been motivated bythe explosive growth in data produced by simulations,collected by experiments and stored at centrally locatedcomputing and data warehousing facilities. Correspond-ingly, as network traffic continues to increase by anorder of magnitude every 46 months [3], it is increas-ingly important to locate data-intensive applications –visualization, rendering and analysis – “close to” thedata [2] where such applications have access to morecapable resources. This trend is increasingly importantas large-scale computational and experimental scienceteams combine forces to solve the world’s most chal-

2

lenging science problems [15].The rest of this paper is organized as follows. In

Section II we describe the background, previous workand motivation for CRRS. Next, in Section III we presentthe CRRS architecture. We characterize CRRS end-to-end performance in Section IV and show how various op-timizations impact overall end-to-end performance. Weconclude in Section V with discussion and suggestionsfor future work.

II. BACKGROUND AND PREVIOUS WORK

The idea of using remote desktops and applicationsis not new. Activity over the past decade includesproprietary (SGI’s OpenGL Vizserver [9], HP’s RemoteGraphics Software [5], and Mercury’s ThinAnywhere[14]) and Open Source (VNC [17], VirtualGL [4], [18])solutions. Orthogonal projects, like NX [11], aim toimprove the efficiency of Layer 7 communications [21]through a combination of compression, caching, andminimizing round-trips across high-latency links. NX isbetter thought of as a “protocol accelerator” rather thanas “remote desktop infrastructure.”

VNC [17] is a client-server system for remote desktopaccess that uses a simple, platform-independent protocol.We use the term “VNC” to refer to any of the multi-ple Open Source implementations. The VNC protocol,known as “Remote Framebuffer” (RFB), resides at OSILayer 7. Via RFB messages, the VNC Viewer authen-ticates to a VNC Server, sends event messages (mouseand keyboard events) and requests screen updates fromthe server. The VNC server responds to RFB UpdateRequest messages with RFB Update messages, whichcontain blocks of pixels that have changed since the timeof the previous an RFB Update Request from the client.

There exist many different VNC “servers” that varyin implementation. XF4VNC (xf4vnc.sf.net) provides anX server module that “snoops” Xlib traffic to determinewhich regions of the screen are modified. Others, likeGNOME’s vino-server and KDE’s krfb server, operateoutside of the X server: they periodically grab the desk-top image and scan it for changes. The XF4VNC methodis more efficient at detecting screen changes, but doesnot detect changes that result from direct rendering withOpenGL as such changes occur outside the X server.This shortcoming is solved with CRRS.

OpenGL Vizserver [9] is a proprietary product fromSGI that consists of a custom display client and server-side software libraries and executables. It allows a remoteuser to run hardware-accelerated graphics applicationson a server then display the resulting imagery on aremote client. Once a user connects from the client tothe server, he may run OpenGL and Xlib applications

the server system with the resulting Xlib- and OpenGL-based imagery appearing on the client’s display. Nomodification to applications is needed for use in theVizserver environment. Vizserver “snoops” the OpenGLprotocol, and internally triggers a framebuffer capturewhen it detects the presence of glFlush, glFinish,or glXSwapBuffers [13].

VirtualGL [4], [18] is an Open Source packagethat provides the ability to deliver hardware-acceleratedOpenGL rendering to remote clients. In “direct mode,”images pixels resulting from OpenGL rendering are com-pressed with an optimized JPEG codec and transmittedover a socket to the client; Xlib commands are sent overa separate socket to the client. In this configuration, theclient must run an X server as well as a special VirtualGLclient application. In “raw mode,” OpenGL pixels arewritten into an uncompressed X-managed bitmap. Xitself, or an X proxy (e.g., VNC) manages encoding theframebuffer pixels and transmitting them to the client.

VirtualGL achieves excellent remote image displayperformance through two vehicles. The first is its useof TurboVNC as a X proxy for mediating the interfacebetween remote client and application image generation.TurboVNC implements some of the same CRRS featureswe describe later, notably multibuffering, to effectivelyoverlap rendering, image acquisition, encoding and trans-mission. The second is a highly optimized encodingpath: TurboJPEG is a vector-optimized version of theJPEG encoder built with Intel’s Integrated PerformancePrimitives, a set of highly-optimized multimedia librariesfor x86 processors. One significant difference betweenCRRS and VirtualGL is the fact that CRRS is engineeredspecifically for use in a parallel, hardware-acceleratedrendering configuration. Another is that CRRS providesaccess to a remote desktop; VirtualGL lets a user runa single application. CRRS explicitly supports clientapplications that run in parallel.

HP’s Remote Graphics Software [5] supports remotedesktop access, including access to hardware-acceleratedgraphics applications. This system consists of two soft-ware components – a client and server. As with VNC,the client sends keyboard and mouse events over thewire to the server. The server forwards events to desktopapplications, then harvests and compresses image up-dates and sends them along to the client where they aredisplayed. This system uses a proprietary image codec toachieve high compression rates. It also uses a combina-tion of graphics API call interception (for OpenGL) andframebuffer state monitoring to determine which portionsof the display have changed and need to be sent tothe client. It provides session-level authentication usingMicrosoft password authentication protocol NTLM and

3

Kerberos under Windows and PAM under Unix. RGSalso supports multiple viewers simultaneously connectedto a single server for a collaborative session mode. WhileRGS supports “multi-screen” mode, it does not appear tosupport fully configurable distributed- or shared-memoryparallelism like CRRS.

Mercury International Technology’s ThinAnywhere[14] products support remote desktop access includingOpenGL. In its most flexible configuration, this systemuses the proprietary interactive Internet Protocol (iIP) forimage delivery from a server to ThinAnywere client(s)running under Linux or Windows. The server supportsboth RDP/iIP and X11/GLX, so it can provide accessto either Windows or Unix application servers. TheiIP protocol supports AES-128 encryption for transportarmoring, but the mechanism of key generation isn’tspecified in the public documentation. ThinAnywere alsosupports RDP and Citrix ICA with client and serverplugins, but does not support many-to-one or many-to-many clustered rendering.

IBM’s Deep Computing Visualization (DCV) system[8] offers a combination of scalable rendering infras-tructure and remote delivery of imagery in a client-server configuration. On the back end, DCV interceptsthe OpenGL command stream and routes subsets ofthe command stream to nodes of a distributed memorysystem for rendering. Sub-images from each are thencollected and combined into a final image, which isthen compressed and sent out to a remote client fordisplay. Like VirtualGL, the DCV system sends Xlibprotocol directly to the client for processing and the usualhost-based ACLs govern security policy. OpenGL pixelsare compressed and sent over a separate communicationchannel to a custom OpenGL client. The communicationprotocol for transporting OpenGL imagery is proprietary.

While DCV appears to support a mode of operationwhereby remote clients connect and interact througha VNC server, it does not appear to support parallelrendering operation in this mode of operation. CRRS,in contrast, implements a general and elegant solutionto the problem of providing pixels from both Xlib andOpenGL command streams – from potentially parallelapplications – to multiple remote clients.

Chromium is a “drop-in” replacement for OpenGLthat provides the ability for any OpenGL applicationto run on a parallel system equipped with graphicshardware, including distribute memory clusters [7]. Itintercepts OpenGL commands issued by the application,and routes them to the appropriate node for rendering.CRRS uses Chromium to implement the distributedmemory parallel rendering capability. During the courseof CRRS design and development, we added a new

������������ ��

��������������������������

���������������

���

�������������� ��������� �!

������"�

�� #���$� �#��

��������������������������

���������������

%&��$'(&&��� ���

�)����� ����

�� ��

�� *+����������

��������

,������

---

������#���������#����!

����������!

Fig. 2. CRRS system components for a two-tile DMX display wallconfiguration. Lines indicate primary direction of data flow. Systemcomponents outlined with a thick line are new elements from thiswork to implement CRRS; other components outlined with a thinline existed in one form or another prior to the CRRS work.

Chromium Stream Processing Unit (SPU) (see SectionIII-A.3) – the VNC SPU – that implements OpenGLframebuffer grabs, image encoding and transmission toa remote client via a specialized VNC server known asthe VNC Proxy (Section III-A.5).

III. ARCHITECTURE

CRRS consists of six general system components(below), many of which are built around VNC’s RFBprotocol. We leverage the RFB protocol because it iswell understood and there exist viewers for nearly allcurrent platforms. One of our design goals for CRRS isto allow an unmodified VNC viewer application to beused as the display client in a CRRS application. TheCRRS general components are:

• The application, which generates OpenGL and Xlibdrawing calls.

• The VNC Viewer, which displays the renderingresults from the application.

• The Chromium VNC Stream Processing Unit,which obtains and encodes the image pixels pro-duced by the OpenGL command stream from theapplication and sends them to a remote viewer.

• Distributed Multihead X (DMX), which is an X-server that provides the ability for an Xlib applica-tion to run on a distributed memory parallel cluster.

• The VNC Proxy, which is a specialized VNC Serverthat takes encoded image input from VNC Serversand VNC SPUs running on each of the parallelrendering nodes and transmits the encoded imagedata to the remote client(s). The VNC Proxy solvesthe problem of synchronizing the rendering resultsof the asynchronous Xlib and OpenGL commandstreams.

• The VNC Server X Extension is present on the Xserver at each parallel rendering node. This com-

4

ponent harvests, encodes and transmits the portionof the framebuffer modified by the Xlib commandstream.

A. CRRS System Components

CRRS is a system of components that interact throughthe Chromium, Xlib and RFB protocols. Figure 2 illus-trates the CRRS components and connections for a two-tile DMX display wall configuration. Descriptions of themain components follow.

1) Application: The application is a graphics or vi-sualization program that uses OpenGL and/or Xlib forrendering. Applications need no modifications to run onCRRS, but they must link with the Chromium fakerlibrary rather than the normal OpenGL library.

2) VNC Viewer: VNC Viewers (or just Viewer forshort in this paper) are available for virtually all com-puter systems. There are no special Viewer requirements– we tested many common Viewers with CRRS. Theresult is maximum flexibility for users and developerssince there is no “special” CRRS client-side viewer otherthan the standard, ubiquitous VNC Viewer.

3) VNC Chromium Stream Processing Unit: InCRRS, all OpenGL rendering is done through Chromium[7]. A new Chromium SPU, the VNC SPU, interceptsOpenGL rendering commands and returns the renderingresults to VNC clients (the Proxy in this case). In atiled/DMX rendering system, the Chromium TilesortSPU sends OpenGL rendering to the back-end servers,each of which hosts a VNC SPU.

The VNC SPU, which is derived from Chromium’sPassthrough SPU, is multi-threaded to perform ren-dering and RFB services simultaneously. The mainthread renders the incoming OpenGL command streamand then, upon SwapBuffers or glFinish orglFlush, retrieves the rendered image from OpenGLwith glReadPixels and stores the image pixels in aholding buffer. A second thread acts as a VNC server. Itaccepts connections from any number of VNC viewersand responds to RFB Update Request messages byencoding RFB Update responses using image pixel datafrom the holding buffer.

4) DMX: DMX (Distributed Multi-head X) is a spe-cial X server for controlling multi-screen displays [16].To an Xlib application, the DMX X server appearsas an ordinary X server. For CRRS, we added severalenhancements to the DMX X server to support the RFBprotocol. Specifically, the DMX server needed the abilityto accept RFB mouse and keyboard events. The DMXserver, however, does not need the ability to send RFBimages updates since the Proxy handles that task. DMXis not required to run CRRS in a single-tile configuration.

5) VNC Proxy: The VNC Proxy (or just Proxy forshort) is derived from the VNC Reflector project[6]. Itoperates as an agent between the application desktop(which may be a multi-screen DMX display) and somenumber of VNC Viewers. To the application desktop, theProxy appears as a VNC client. To the VNC Viewers, itappears as a VNC server.

The Proxy collects images rendered by OpenGL andXlib into a virtual framebuffer (VFB), which is then usedto satisfy requests from the Viewers. When using a DMXdisplay wall, the Proxy queries DMX for the identity ofthe back-end X servers and their tile boundaries. TheProxy directly connects to each of the back-end serversin order to collect imagery, bypassing the DMX serveritself. Otherwise, all RFB traffic would need to make anintermediate trip through the DMX server.

On the Viewer side, the Proxy processes some RFBcommands and passes others along. It processes RFBAuthentication messages (see Section III-C for security-related discussion) as part of the initial Viewer-Proxyconnection. During operation, it sends mouse and key-board RFB event messages directly to the front-endX/DMX server for further processing. The Proxy an-swers RFB Update Request messages from all Viewersby encoding RFB Update messages from its internalframebuffer. In turn, the Proxy sends RFB Update Re-quest messages to all back-end VNC Servers. The sourceof Xlib image data comes from the VNC Server runningon each back-end X server, while the OpenGL imagedata comes from the Chromium VNC SPU, which wedescribe in Section III-A.3.

All the “parallel aware” aspects of CRRS are con-solidated into the Proxy. Thus, any “standard” VNCServer may be used in the CRRS back-end: no special“parallel VNC Server” code is required in the back-end. As the Proxy acts as a message router – brokeringcommunication between a set of hosts in the back-end and one or more Viewers – it has the potential tobecome a performance bottleneck. This concern led us topursue optimization strategies (see Section III-B) as wellas conduct a battery of performance tests (see SectionIV) to better understand end-to-end system performancecharacteristics. The VNC Proxy has been set up as anOpen Source project at SourceForge [19].

B. Optimizations

In this section, we describe a number of optimizationsin CRRS that can have a profound impact on end-to-endperformance:

• RFB caching. Improves performance by maintain-ing a cache of RFB Update messages that containencoded image data. The VNC Proxy responds to

5

RFB Update Requests by sending cached responsesrather than encoding, possibly multiple times, thecontents of its internal VFB. This optimization helpsto reduce end-to-end latency.

• Bounding box tracking. Here, only the portions ofthe scene rendered by OpenGL that have changedare rendered and transmitted to the remote client.This optimization helps to reduce the amount ofRFB image payload.

• Double buffering. By maintaining a double-bufferedVFB in the VNC SPU, two operations can occursimultaneously – application rendering and imageencoding/transmission. This optimization helps toreduce end-to-end latency.

• Frame synchronization. While not strictly an opti-mization, this feature is needed to synchronize par-allel rendering streams as well as to prevent framedropping (spoiling) when images are rendered morequickly than they can be delivered to the remoteclient.

1) RFB Caching: Normally, the Proxy decodes in-coming RFB Updates to its VFB, which is a full res-olution image. When a Viewer sends an RFB UpdateRequest to the Proxy, the Proxy responds by extractingpixels from its VFB, compresses/encodes them into anRFB Update response and sends to the Viewer. It is oftenthe case that the Proxy will receive an RFB Updatefrom an X-server VNC module or VNC SPU, decodethen store results in its VFB only to shortly thereafterregenerate the same data in response to an RFB UpdateRequest from a Viewer. The purpose of the RFB Cachingoptimization is to avoid the re-encoding step, therebyreducing latency and processing load, and thus improvethe VNC Proxy’s overall throughput.

When RFB Caching is enabled, the Proxy saves theincoming RFB Update messages in their encoded formatin a cache. When a Viewer requests an update fromthe Proxy, the Proxy searches its RFB cache to see ifthe request can be satisfied by a cached entry. If not,the Proxy generates a new RFB update message for theViewer using its local VFB as the source of pixel data.Each cache entry consists of screen region bounds and ablock of encoded/compressed pixel data for that region.

At present, the Proxy caches RFB Update messagesonly from the VNC SPU(s), and not those from theXF4VNC VNC server(s). This issue is the result of howzlib compression is implemented in the tight encoder ofVNC Servers – we “fixed” the zlib compression problemfor the VNC Server code in the VNC SPU, but did notpropagate those changes to the XF4VNC VNC Server soas to avoid introducing a version dependency in CRRS.

When the Proxy receives a new RFB Update message

from a Server, the Proxy searches its RFB cache todetermine if any cached regions intersect the new region.When the Proxy finds a cached region intersecting thenew region, the older cache entry is discarded and theincoming message is saved as a new cache entry. Whenthe old and new regions partially overlap (e.g., are notidentical), this algorithm produces the correct resultssince for each incoming RFB Update message, the Proxyfirst decodes the message by modifying its VFB and thencaches the new message.

The Proxy appends new entries into the cache anduses a linear cache search algorithm to locate entriesin the cache. The linear search algorithm is acceptablesince the cache typically contains only a small numberof entries. The number of cache entries is less than orequal to the number of DMX screens multiplied by thenumber of OpenGL display windows. For this reason,the cache memory consumption has an upper bound thatis the size of the Proxy’s VFB if we assume that the sizeof a compressed RFB pixel block is always smaller thanthe uncompressed image in that pixel block.

It is typically the case that the viewer-requested updatearea does not exactly match the area covered by cachedRFB Update messages. In the case of these “partialintersections,” the Proxy computes an intersection ratio,which is the quotient of: (1) the intersection area ofthe requested and cached regions, and (2) the area ofthe cached region. The closer this quotient is to 1.0,the greater the overlap of the requested and cachedregions. The Proxy compares this ratio to a user-tunableintersection ratio threshold parameter to determine if theparticular cached entry is a “hit” or a “miss.”

For our typical intended use case – animations of2D or 3D scientific visualization – the RFB cache cansatisfy all the viewer’s RFB Update Requests, therebyavoiding the cost of an image compression for eachupdate. The positive impact on performance stems from(1) reduced computational cost of the Proxy performingcompression and encoding to satisfy the Viewer’s RFBUpdate Request, and (2) a corresponding decrease inlatency when the Proxy answers RFB Update Requests.

2) Bounding Box Tracking: A key feature of anefficient VNC server implementation is the ability totrack the regions of the screen that have changed andthen perform RFB encoding for only those regions. Inthe Xlib-only configuration where the VNC server runsas an extension to the X server, the VNC server “snoops”the Xlib protocol to track screen regions that change.To achieve the same type of capability when renderingscenes with OpenGL, we have designed and imple-mented a similar capability in CRRS called “boundingbox tracking.” This optimization, when enabled, restricts

6

RFB processing to only those window regions that havechanged as a result of OpenGL drawing commands. Thisapproach avoids having to encode and transmit the entireOpenGL window if only a small portion has changed.

In a Chromium configuration, the OpenGL “commandsnoop” occurs at the tilesort SPU level: application-generated OpenGL commands are processed by thetilesort SPU where they are “packaged” and then routedto the appropriate crserver for rendering. Part of the“packaging” includes bounding box information for theprimitive represented by the set of OpenGL commands.When the tilesort SPU’s bounding box tracking feature isenabled, primitives are sent only to the crservers wherethey will be rendered, thereby saving network bandwidthand processing. This feature existed in Chromium priorto the CRRS project; however, the crservers did not passthe bounding box information on to their hosted SPU(s).The implication is that no other SPUs in the SPU chainon the rendering hosts would be able to use boundingbox information. We enhanced the crserver so that suchbounding box data is passed along to the first SPU inthe chain. In the CRRS case, the first SPU in the chainis the VNC SPU. The VNC SPU uses the boundingbox information in an effort to send smaller RFB updatemessages to the client (the Proxy). That is, if only a smallpart of the OpenGL window is changing, only that smallpart of the window should need to be encoded and sentto the VNC Proxy, not the whole window.

The VNC SPU’s method for using bounding boxinformation is as follows. As the OpenGL commands arerendered, the VNC SPU accumulates bounding boxes inan “accumulated dirty region” data structure. That datastructure maintains information indicating which regionsof the window have been modified by OpenGL drawingcommands. When the VNC SPU needs to send an RFBUpdate message to the Proxy, it sends data only from theaccumulated dirty regions rather than the entire windowregion.

The glClear command requires special handling. Anaive implementation would simply treat glClear asa rendering command that changes the entire OpenGLwindow: the entire window is the modified region, notjust the region defined by the previous bounding boxes.This would defeat the purpose of tracking the accumu-lated dirty region.

Our approach is to maintain two separate dirty regions:the current frame’s region and the previous frame’sregion. When glClear is executed (at the start of theframe), the current region is assigned to the previousregion, and the current region is emptied. During ren-dering, the current region accumulates the bounding boxdata. At the end of the frame, we compute the union

of the previous and current region. The union specifieswhich window areas need to be read and placed in theSPU’s virtual framebuffer.

If only the current region were read back, the imageof the object from the previous frame would linger inthe VNC SPU’s VFB. By including the previous frame’sregion in readback, we effectively erase the old imagedata with the window’s current background color (setby glClearColor). This algorithm ensures that theVNC SPU’s VFB is always up to date with respect tothe current window contents.

The VNC SPU also must cope with the situation inwhich it is sending RFB updates at a different (slower)rate than the application frame rate. For example, in thetime it takes the VNC SPU to send one RFB Updatemessage to the Proxy, the application may have renderedmany frames. If only the previously described unionregion were sent to the Proxy, the Proxy’s VFB maynot be updated correctly. Instead, the VNC SPU needsto send to the Proxy all framebuffer regions that havepotentially changed since the previous update was sentto the Proxy. To solve this problem, the VNC SPUbuilds and maintains an accumulated dirty region. Thisregion contains the accumulation of all bounding boxesbetween the times when the Proxy sends RFB Updatesto clients. Thus, subsequent RFB Updates sent from theVNC SPU to the Proxy contain all window regions thathave changed since the previous RFB Update messagewas sent.

There are several special cases in which the boundingboxes are ignored and the entire window contents areread back and sent. Examples include the first time awindow is rendered to, whenever a window is moved orresized, and whenever the clear color is changed.

The effectiveness of bounding box tracking for re-ducing the size of RFB Update messages depends onhow much of the window changes from frame to frame.In turn, the amount the window contents change fromframe to frame is highly application dependent. In caseswhere the entire window contents change between eachframe, as would be the case with video games, boundingbox tracking will provide no performance gain. In othercases, like scientific visualization applications that oftendisplay a 3D model in the center of the window, a sizablefraction of the window contents might not change fromframe to frame. In these cases, there is opportunity forperformance gains due to bounding box tracking.

3) Double Buffering: The VNC SPU uses an internalimage buffer – its VFB – to store the pixels it obtainsfrom each OpenGL window via glReadPixels. Thatbuffer also serves as the source for the RFB imagecompressors (tight, hextile, etc.).

7

There are two threads in the VNC SPU: the mainapplication thread and the VNC server thread. The mainapplication thread will periodically call SwapBuffersor glFinish or glFlush. The VNC SPU interceptsthose functions and updates its VFB with the currentwindow image using glReadPixels. Meanwhile, thesecond thread accepts RFB Update Request messagesfrom the Proxy and replies to them with encoded RFBUpdate messages. To prevent encoding errors that couldresult from the encoder reading the VFB while it isbeing updated with new contents, the VFB must not bemodified while encoding is in progress. Since the firstthread’s glReadPixels calls do exactly that, we mustsynchronize access to the VFB by the two processingthreads.

Our initial VNC SPU implementation synchronizedtwo-thread VFB access with a mutex so that only onethread could access the VFB at any time. Performanceand profiling analysis showed that each of the twothreads spent a significant time amount of time simplywaiting for access to the shared framebuffer.

We improved performance – eliminating stalls due towaiting – by using a double-buffered VFB. The mainapplication thread can write to the “back” buffer whilethe second thread can read from the “front buffer” toperform RFB image encoding. The main thread per-forms a VFB buffer exchange after SwapBuffers,glFinish, or glFlush whenever the RFB encoderis not reading from the “front buffer.” This approachallows the application to run at a faster frame rate thanthe RFB encoder. If the RFB encoder can’t keep up withthe application’s frame rate, intermediate frames will bedropped (spoiled).

In some situations (such as with frame synchroniza-tion, below) we do not want frames to be dropped, sowe have implemented a VNC SPU configuration optionthat will prevent frame dropping. When this option isenabled, there is a handshake signal to regulate VFBbuffer swapping. The VNC SPU’s main thread raisesa signal when a new frame is ready. The VNC SPU’sserver thread waits for this signal, then encodes theimage and sends the RFB Update. During encoding, theVFB is locked so that the main VNC SPU thread cannotupdate it with new contents. When the server threadis finished encoding, the lock is released and the mainVNC SPU thread can update the VFB with new contentsbefore returning control to the application.

4) Frame Synchronization: When using a DMX dis-play, there is a separate VNC SPU for each screen in thetiled display. Further, there is no explicit synchronizationbetween the VNC SPUs and the image streams beingsent to the Proxy. The result is that at any given point

in time, the Proxy’s framebuffer may contain data fromtiles produced at slightly different points in time. For ananimated scene, the visual result is that a Viewer maybe displaying results from different points in time. Whenthe application stops animating, all the SPUs “catch-up”and the last frame’s image data appear in the Viewer asexpected.

We added a frame synchronization option to the Proxyto address this problem. The key objective is to preventsending RFB Update messages to the Viewer(s) whenthe Proxy’s framebuffer is mid-way through an aggregateupdate (i.e., receiving updates from one or more VNCSPUs.) We implement such synchronization using a bar-rier mechanism in the Proxy that manages the incomingand outgoing RFB streams, which contains state for eachincoming and outgoing VNC socket connection. Eachincoming (i.e., VNC SPU) socket can be in one of threebarrier states: pre-update, mid-update, and post-update.The initial state is pre-update. Each outgoing socket(i.e., VNC Viewer) connection can be in one of twostates: blocked and non-blocked. The initial state is non-blocked.

When the Viewer receives the first part of an incomingRFB Update message from the Proxy, the Viewer’ssocket state is set to mid-update. All of the Proxy’soutgoing socket connections also are blocked so nointermediate RFB Updates will be sent to the Viewer.When the Proxy receives the end of the message, itsets the socket state to post-update. The socket also isblocked so no further input will be read and no RFBUpdate requests will be sent to the VNC SPU. After allthe Proxy sockets connected to SPUs have transitionedto the post-update state, the barrier is released and allsockets are unblocked (and the VNC SPU sockets areset to the pre-update state). At that time, the Proxy’soutgoing socket(s) will be serviced and an RFB Updatewill be sent to the viewer(s). There will be no incomingRFB Updates pending on the Proxy’s SPU sockets sinceno requests will have been sent.

Frame synchronization requires that the VNC SPUsdo not drop frames as described above. Otherwise, ifframes were dropped, one might see different frames ofanimation in different image tiles. Another requirementis that the VNC SPU always sends an RFB Update atthe end of a frame, even when there is no new pixeldata to be sent. When there is no new pixel data tosend, the VNC SPU sends a null/empty RFB Updatemessage, which has no content, but serves to satisfy thesynchronization needs of the barrier.

While “frame synchronization” ensures that the con-tents of the Proxy’s VFB from each VNC SPU areconsistent, it does not prevent “image tearing” in the

8

Viewer. Image tearing occurs when rendering is notsynchronized to the refresh rate of a monitor. In thecase of the VNC Viewer, image tearing occurs when thedecoding and displaying of the image data in an RFBUpdate message takes longer than the monitor’s refreshrate. The traditional solution to this problem in computergraphics involves double-buffering. In this case, double-buffering in the VNC Viewer would alleviate imagetearing during Viewer image display. At least one VNCdistribution, TurboVNC, is known to offer a double-buffered Viewer. We have not explored using this double-buffered Viewer with CRRS.

Under some circumstances, we have observed CRRSframe synchronization results in improved performancedue to more efficient VNC SPU operation. When framesynchronization is enabled, the VNC SPU is preventedfrom dropping frames as the two threads in the VNCSPU are synchronized. Without this synchronization, theVNC SPU’s server thread may sometimes be starved orpreempted by the main thread, resulting in an overalldecrease in RFB throughput.

C. Security

Because CRRS is a system of components actingthough multiple protocols, implementation of securitycan be problematic. Each of the underlying protocolshave their own pre-established authorization mecha-nisms, and one of the CRRS design requirements is thatit is based on open standards. Thus, our security analysisfocuses on categorizing the risk of the connections andensuring that sites have avenues to “tighten the securityscrews” as required by their policies.

A pictorial view of the connections and their typesin CRRS is shown in Figure 3. In that Figure, theconnections between one or more Viewers and the Proxyoccur in Zone 1. These Zone 1 connections typicallyoccur in the open internet and consist exclusively ofRFB traffic. Inside the CRRS back end, connectionsthat occur between the Proxy, the VNC servers in eachof the tiles of a DMX display, and DMX itself occurin Zone 2. Traffic in Zone 2 consists of a mixture ofRFB and Xlib protocols. Further inside the CRRS backend, the (potentially parallel) rendering application emitsOpenGL and Xlib rendering commands. OpenGL com-mands are routed to one or more Chromium crservers,while Xlib traffic is routed to the DMX server, which inturn, snoops the Xlib protocol and routes Xlib commandsto the appropriate tile for rendering. This traffic occursin Zone 3.

For many sites, security in Zone 1 will be the mostcritical issue. The Zone 1 RFB connection might occurfrom remote locations and are thus outside the control

Fig. 3. CRRS Security Zones. Zone 1 traffic consists exclusively ofRFB protocol messages, and typically occurs over the open internet.A commonly accepted practice to “secure” this connection is toforce all such traffic through SSH tunnels, where site-wide policycan enforce authentication and the connection is armored. Inside thecenter, Zone 2 traffic consists of a mixture of RFB and Xlib messagesbetween the Proxy and the VNC servers. Zone 3 traffic consists ofapplication-generated OpenGL and Xlib command streams, and istypically where services like MPI are provided for parallel applicationoperation.

of the site. Additionally, the RFB protocol itself hasonly a basic mechanism for authentication and providesno encryption or other protection during transport. Tomitigate security concerns, the Proxy supports bindingthe listening socket to a specific IP address. That featurecan be used in conjunction with SSH or SSL tunnelingsoftware to provide both stronger authentication andtransport layer encryption. Additionally, the CRRS teamhas provided client patches that implement SSL directlyin the java-based viewer to the upstream maintainers ofthat code.

The standards for Zone 2 and 3 security likely will bedriven by site-specific deployment models and require-ments. In general, both Zone 2 and Zone 3 connectionsoccur within the interconnect fabric of a single visual-ization cluster rather than over the open network. Sincesuch fabrics are private to a cluster, transport securityconcerns are generally addressed as part of the clusterdesign, leaving only user authorization as a concern.For the Zone 2 connections, this means using Xauthand vncpasswd to authorize the connections between theProxy and other back-end components in order to denyaccess from other users running on the same node as theProxy. For sites that use a clustering model that restrictslogins to a few front-end nodes, moving the Proxy to an“internal” node can provide further mitigation of secu-rity issues by removing the requirement for user-basedsecurity in favor of host-based security. For deploymentsthat do not use a cluster model, Zone 2 connections canbe addressed via SSL or SSL tunneling in the same wayas Zone 1.

For Zone 3 there are typically no additional require-ments beyond those for Zone 2. The Zone 3 connectionare analogous to MPI messages, for which most sites re-

9

quire at most host-based authorization. Again, the optionfor tunneling remains, though probably at a substantialcost in performance.

IV. PERFORMANCE CHARACTERIZATION

A. Performance Test Applications

For the purpose of performance evaluation, we em-ployed one network bandwidth measurement tool andtwo different rendering applications.

Iperf is a tool for measuring effective TCP or UDPbandwidth/throughput over IP networks [1].

City is a lightweight GLUT/OpenGL application thatis included the Chromium distribution. It draws a sceneconsisting of a flat ground surface and a number oftextured buildings. The scene rotates a small amountabout an axis perpendicular to the ground between eachframe. This application is useful in our tests because itsrendering cost is relatively low and about 50%-75% ofthe screen pixels change from frame to frame.

svPerfGL is a lightweight OpenGL benchmark appli-cation – similar to SPECViewperf in intent – that loadstriangle vertex/normal/color data stored in a netCDF file(such data files are accessible at the svPerfGL project site[20]), rotates about about a vertical axis a small amounteach frame, runs for a finite duration and reports averageframe rate at the end of the run. Like city, its render-ing will result in about 50%-75% of the screen pixelschanging on each frame. Its focus is on benchmarkingOpenGL systems under a load characteristic of scientificvisualization.

B. Methodology and Resources for End-to-End Tests

1) Computing Platforms: For our performance tests,we ran the CRRS back-end components (Zones 2 and 3)on a cluster at Lawrence Berkeley National Laboratory(LBNL). Each of the eight nodes of the LBNL clusterruns SuSE Linux 10.0 and consists of dual-socket, dual-core 2.6Ghz AMD Opteron processors, 16GB of RAM,NVIDIA GeForce 8800 graphics accelerators, Infiniband4x interconnect for intranode traffic and gigabit ethernetfor internet traffic.

At Lawrence Livermore National Laboratory (LLNL),the display platform is a 16-node cluster consisting ofdual-socket, single-core 2.0Ghz AMD Opteron proces-sors running the RHEL4+CHAOS Linux distribution.Each node has 4GB of RAM, an NVIDIA GeForce6600GT graphics accelerator, Infiniband 4x interconnectfor intranode traffic and gigabit ethernet for internettraffic.

At Oak Ridge National Laboratory (ORNL), the dis-play platform is a 64-node cluster. Each node consistsof dual 2.2Ghz AMD Opteron processors with 2GB of

Iperf (Mb/s) LAN WAN-R WAN-H1 WAN-H2Clear 877.00 2.07 168.00 10.80Tunnel 380.00 1.97 115.00 49.00Tunnel -c (JPG) 87.40 2.07 82.00 36.30Tunnel -c (XWD) 291.00 17.20 150.0 51.00Ping RTT (ms) 0.01 16.25 2.71 62.25

TABLE I. Results of iperf bandwidth measurement of four differentnetworks reported in megabits/second. The networks consist of aGigabit ethernet LAN, residential broadband (WAN-R), and twodifferent high-speed networks – one between LBNL/LLNL (WAN-H1), the other between LBNL/ORNL (WAN-H2). We had iperftransfer known image data between endpoints (“Tunnel -c – JPG”and “Tunnel -c – XWD”) to measure the impact of SSH compressionon throughput.

RAM and running the SuSE 9.2 Linux distribution. Thefourteen nodes driving the display wall are equipped withNVIDIA QuadroFX 3000G graphics accelerators.

2) Networks and Throughput Measurement: To mea-sure network performance, we ran iperf in two differentmodes: (1) a direct connection between client and server,and (2) tunneling the iperf connection through SSH.The tunneled connection represents a typical CRRS usescenario, where the connection between the Viewer andProxy occurs over the open internet. Table I shows themeasured throughput over each of these networks.

Since most SSH implementations offer a losslesscompression option, we included tests to measure theeffective compression when moving pre-compressed anduncompressed image data – the typical CRRS payload.For these tests, we prepared archive files of images inJPEG and XWD format for the pre-compressed anduncompressed image tests, respectively. Each of theJPEG and XWD image sequences show exactly the samething: an isosurface rotating a small amount each frameabout the vertical axis; approximately 50%-75% of theimage pixels change on each frame. The results in TableI show that tunneling has a more pronounced adverseimpact on throughput on higher speed networks, andthat SSH compression produces better throughput whentransmitting uncompressed through the tunnel.

The four different networks shown in Table I areas follows: (1) LAN: switched copper gigabit ethernet;(2) WAN-R: residential broadband from LBNL to theresidence of one of the authors; (3) WAN-H1: high-speedIP network between LBNL and LLNL over ESnet; (4)WAN-H2: high-speed IP network between LBNL andORNL over ESnet.

During performance testing, which spanned manymonths, we discovered a large amount of variation inperformance over these networks. This variance wasat times quite severe – as much as 50%. Worse, oneof the mid-stream service providers for the residentialbroadband network changed its routing in a way thatadversely affected network performance. To work around

10

this situation, we used a bifurcated strategy. For thosetests that require multiple collaborative users, we (1)would run iperf prior to any testing to verify that networkconditions were close to baseline, and (2) then run thegiven test five times and average the results.

For most other tests, we assembled a network emulatorat LBNL. The emulator consists of: (1) the Nist NETnetwork emulator software [10], which supports usertunable bandwidth and latency parameters; (2) two work-stations – one acts as a gateway and runs the networkemulator software, the other is a “remote client” thatroutes all IP traffic through the gateway machine.

C. Individual Performance Optimizations

Earlier in Section III-B, we described a number ofoptimizations aimed at improving overall end-to-endCRRS performance. This Section presents results oftests aimed at measuring the impact of each of theseindividual optimizations when applied separately andtogether. For these tests, we used the city and svPerfGLapplications. Each was run five times for a duration ofsixty seconds at varying resolution/tiling configurationsand over different networks configurations using thenetwork emulator. The choices for configurations andapplications are intended to provide reasonably broadcoverage across optimization opportunities.

In one test configuration, we run both applicationsunder CRRS at SXGA resolution (1280x1024) on asingle node and transmit results to a remote Viewer.In another, we run both applications under CRRS at aresolution of 4800x2400 pixels on a 3x2 DMX muraland transmit results to a remote Viewer. In each ofthese configurations, we vary the optimization and thenetwork.

Both applications report their frames-per-second ren-dering rate, which is the metric for measuring perfor-mance in these tests. In all test configurations, we enablethe frame synchronization option (Section III-B.4). Withframe synchronization enabled, the application-reportedframes-per-second accurately reflects the rate that framesare delivered to the remote Viewer over the course of therun. We average the frames-per-second from five runs toaccount for variation in network (emulator) and systemperformance.

1) No Optimizations: We begin the optimization test-ing by measuring performance without any optimizationswhatsoever. These results, shown in Figure 4, establishthe performance baseline for measuring the impact ofindividual optimizations.

Here we see a noticeable performance difference de-pending upon how image payload data is encoded. Thehextile encoder is lossless and inexpensive but results

No Optimizations

0

2

4

6

8

10

12

14

16

LAN WAN-R WAN-H1 WAN-H2

Fram

es/s

ec

City, Tight, 1x1City, Hextile, 1x1svPerfGL, Tight, 1x1svPerfGL, Hextile, 1x1City, Tight, 3x2City, Hextile, 3x2svPerfGL, Tight, 3x2svPerfGL, Hextile, 3x2

Fig. 4. Frame rate of test applications over different networks,varying resolution, and no CRRS optimizations.

in a lower rate of compression than the tight encoder.Therefore, when the network can transmit payload fasterthan the processor can compress it, the hextile encoder isa better choice. Conversely, when network throughput isthe bottleneck, better compression results in better framerates.

The tight encoder is “adaptive” in the sense that itexamines blocks of pixels and then encodes the pixelblocks in one of two ways. If the block of pixels is“homogeneous,” it uses a form of run-length encoding.If not, then the block of pixels undergoes JPEG compres-sion. The JPEG encoder has tunable attributes to balanceimage quality versus amount of compression. In thesetests, we used an image quality value of 95%, which isoften accepted as being “visually lossless,” yet producingreasonably good compression ratios.

2) RFB Caching: We instrumented the Proxy to re-port the effective compression ratio by computing thenumber of bytes sent divided by the number of pixels atthree bytes per pixel in the Proxy’s virtual framebuffer.For both test applications, we ran the instrumented Proxycode using both tight and hextile encoders. The approx-imate compression ratios for each of these combinationsare shown in Table II. While the absolute amount ofcompression is highly dependent upon the image con-tents, we observe that the hextile compression ratio variesless than that for the tight encoder. We also observe that

Application City svPerfGLTight, JPEG quality=95 12.0:1 26.1:1Hextile 3.1:1 3.4:1

TABLE II. Approximate compression ratios for each of the tightand hextile image encoders when applied to the image output to thetwo test applications city and svPerfGL. The tight encoder, whichuses lossy compression based upon JPEG, provides high levels ofcompression, and therefore is better suited for use on high latency,low bandwidth network links.

11

the lossy tight encoder is able to achieve much highercompression ratios for these particular applications.

The test results, shown in Figure 5, indicate that RFBcaching has a greater positive impact on performancewhen using the more expensive tight encoder by avoidingmultiple executions of the encoder on a block of imagedata. We see more consistent performance improvementin the tiled than serial configurations across all test pa-rameters. In the tiled configuration, CRRS is processingabout six times more image data than in the serial config-uration; we expect the RFB caching performance impactto be more consistently present in this configuration. Wealso see less performance variability in the lower latencynetworks (LAN, WAN-H1) than in the higher latencynetworks. This result is expected since the overall framerate is a function of latency – the effects of network andProxy response are additive.

In some cases, RFB caching seems to have a small,adverse impact on overall application performance. Thisresult occurs when using the fast hextile encoder on arelatively small amount of image data. In these config-urations, it is likely that the cache lookup and replace-ment operations, which involving allocating and freeingmemory buffers, take longer than simply encoding andtransmitting the image data.

3) Bounding Box Tracking: This optimization aimsto reduce the size of RFB Update payload by havingthe VNC SPU encode RFB Update messages that reflectonly the portion(s) of the OpenGL display windowthat actually change from frame to frame. Without thisoptimization, each VNC SPU will encode the entirecontents of the OpenGL display window in response toan RFB Update Request message.

The test results, shown in Figure 6, indicate this opti-mization has a uniformly positive, albeit modest, impactregardless of encoder type and network. This result is

RFB Caching Optimization Improvement

-20.00%

0.00%

20.00%

40.00%

60.00%

80.00%

100.00%

120.00%

City, Tight,1x1

svPerfGL,Tight, 1x1

City,Hextile,

1x1

svPerfGL,Hextile,

1x1

City, Tight,3x2

svPerfGL,Tight, 3x2

City,Hextile,

3x2

svPerfGL,Hextile,

3x2

Perc

ent I

mpr

ovem

ent

LANWAN-RWAN-H1WAN-H2

Fig. 5. RFB Caching performance improvement test results.

Bbox Tracking Optimization Improvement

0.00%

2.00%

4.00%

6.00%

8.00%

10.00%

12.00%

14.00%

City, Tight,1x1

svPerfGL,Tight, 1x1

City,Hextile,

1x1

svPerfGL,Hextile,

1x1

City, Tight,3x2

svPerfGL,Tight, 3x2

City,Hextile,

3x2

svPerfGL,Hextile,

3x2

Perc

ent I

mpr

ovem

ent

LANWAN-RWAN-H1WAN-H2

Fig. 6. Bounding box tracking performance improvement test results.

expected since this optimization will reduce the overallamount of RFB traffic for the two test applications inall configurations. The absolute amount of improvementgain is a function of scene contents – scenes where littlechanges from frame to frame will realize a greater benefitthan those that make more extensive inter-frame changes.We also see this optimization has a positive impactregardless of whether used in serial or parallel configura-tions. This optimization, which propagates bounding boxinformation to the parallel rendering nodes, is capableof producing a positive impact throughout the parallelrendering back end.

4) Double Buffering: This optimization allows themultithreaded VNC SPU to maintain and operate withmultiple internal VFB’s. One thread responds to RFBUpdate Request messages and reads/encodes from onebuffer, while another thread harvests OpenGL pixelsfrom the other. This optimization is intended to elimi-nate contention between these two threads and thereforeincrease overall throughput.

Double Buffering Optimization Improvement

0.00%

2.00%

4.00%

6.00%

8.00%

10.00%

12.00%

14.00%

16.00%

18.00%

City, Tight,1x1

svPerfGL,Tight, 1x1

City,Hextile,

1x1

svPerfGL,Hextile,

1x1

City, Tight,3x2

svPerfGL,Tight, 3x2

City,Hextile,

3x2

svPerfGL,Hextile,

3x2

Perc

ent I

mpr

ovem

ent

LANWAN-RWAN-H1WAN-H2

Fig. 7. Double buffering optimization performance improvementtest results.

Double buffering has greater positive impact when

12

using the hextile rather than the tight encoder. Like RFBcaching, double buffering serves to reduce end-to-endlatency. The greater performance improvement seen withthe hextile encoder is due to the fact that it can encodeimage data more quickly than the tight encoder.

Test results, shown in Figure 7, indicate performanceimprovement from this optimization is uniformly posi-tive across both serial and tiled configurations. This re-sult is expected since the performance gain from doublebuffering, which effectively overlaps application render-ing and RFB image encoding, is present at each of theparallel rendering nodes. In contrast, other optimizations,like RFB caching, occur only at the Proxy, which iseffectively a serial “junction point” in CRRS betweenthe back-end rendering engines and the Viewer.

We see greater positive impact on higher latencynetworks (WAN-R, WAN-H2) than on lower latencynetworks (LAN, WAN-H1). This result is expected dueto the additive nature of end-to-end latency.

5) All Optimizations: Here, we run the test batterywith all of the above optimizations enabled. Figure 8presents the results in the same format as for the individ-ual unit tests, while Figure 9 shows the results organizedby network and optimization rather than application.

All Optimizations Improvement

0.00%

20.00%

40.00%

60.00%

80.00%

100.00%

120.00%

City, Tight,1x1

svPerfGL,Tight, 1x1

City,Hextile,

1x1

svPerfGL,Hextile,

1x1

City, Tight,3x2

svPerfGL,Tight, 3x2

City,Hextile,

3x2

svPerfGL,Hextile,

3x2

Perc

ent I

mpr

ovem

ent

LANWAN-RWAN-H1WAN-H2

Fig. 8. Relative performance improvement from enabling alloptimizations.

Double buffering’s amount of positive impact ap-pears to be inversely proportional to the latency of theunderlying network. In other words, double bufferingprovides the greatest amount of performance gain onhigh-latency networks. RFB caching has a noticeable,positive impact across all test applications, encoders,networks and display resolutions. Bounding box trackinghas a modest, but positive, impact on performance inall configurations. Since this performance optimization’simpact is a function of scene content, other applicationsmay realize a greater or lesser degree of performance

Average Improvement

0.00%

5.00%

10.00%

15.00%

20.00%

25.00%

30.00%

RFB Caching Double Buffering Bounding Box Tracking All

CRRS Optimization

Perc

ent I

mpr

ovem

ent

LAN WAN-RWAN-H1WAN-H2

Fig. 9. Relative performance improvement from enabling alloptimizations.

gains. Overall, the performance improvement of all op-timizations appears to be nearly additive. This result isexpected since they all serve to either reduce latency orthe amount of RFB Update payload traffic. We concludefrom these tests that CRRS performs best when RFBcaching, double buffering and bounding box tracking areall enabled for all types of encoders and networks.

V. CONCLUSION AND FUTURE WORK

CRRS is software infrastructure that provides theability for a remotely located user to take advantageof distributed memory parallel rendering resources at acentrally located facility to perform interactive visual-ization. This type of use model is increasingly commonand reflects the need to perform visual data analysis“close to” the data. The new contribution of this work isthe design and implementation of software infrastructurethat performs parallel, hardware-accelerated renderingfor unmodified OpenGL applications with delivery ofresults via industry-standard mechanisms to one or morecollaborative clients. Our study includes detailed per-formance evaluation of several different system opti-mizations. These optimizations, while couched in termsof CRRS, will be of benefit to virtually all renderingapplications where end-to-end performance is a concern.All CRRS system components are Open Source, freelyavailable, and have undergone extensive testing.

During CRRS development and testing, we did con-duct some preliminary scalability studies. In particular,we examined performance when adding more simulta-neous collaborative viewers. Due to space limitations,those results are not presented here. One conclusion fromthat testing is that the benefits from CRRS optimiza-tions, particularly RFB caching, extend to the multi-participant use model. The primary bottleneck in thatcase is network throughput at the VNC Proxy host.

13

Interesting future work would include additional studiescharacterizing performance of strong scaling (addingmore rendering nodes for a fixed problem size) and weakscaling (increasing the number of rendering nodes andproblem size). Such studies would be instrumental inidentifying performance bottlenecks and system limits.

During our testing, we encountered several limitationsthat would merit further investigation and future work.First, when performing image downsizing at the Proxy– so that the application can render at a high resolutionand the results displayed at a much smaller resolution –we often encountered situations in which it was difficultto read text on menus. One of the test users (shown inFigure 1) suggested a “fisheye” style of rendering for fo-cus views. This capability is not trivially implementablein the current system.

Another interesting enhancement would be dynamicresolution selection for remote clients. The idea herewould be for the Viewer and Proxy to negotiate a scalingfactor to meet some performance criteria. Furthermore,extending this idea to be dynamic over the course ofthe application session would be useful. At present, thescale factor is specified when the Proxy is launched andremains constant for the duration of the run. Related,extending CRRS with alternate encoding methods likeMPEG may help to improve absolute performance; sim-ilar work has been explored with success for use withmobile devices [12].

There are several interesting systems that performremote delivery of imagery produced by hardware-accelerated rendering – it would be interesting to seea head-to-head comparison of absolute frame rate for astandard set of benchmarks for all these systems.

While we have touched on issues related to security,we have not directly solved any of them. An ongoingdebate within the community is the extent to which secu-rity, specifically authorization and authentication, shouldbe performed by the distributed visualization/renderingsystem. Related, the centrally located facilities are sys-tems that are shared by many users, but graphics cardsand X servers are typically employed in a single-usermode. Some sites address this problem by requiring allinteractive visualization jobs to be marshaled by a centralbatch queue. While this approach works, it can leavemuch to be desired from the perspective of the user.

ACKNOWLEDGMENT

This work was supported by the Director, Officeof Science, Office of Advanced Scientific ComputingResearch, of the U.S. Department of Energy throughthe SBIR/STTR program under Contract No. DE-FG02-04ER86198.

REFERENCES

[1] A. Tirumala and F. Qin and J. Dugan and J. Ferguson and K.Gibbs. Iperf Version 2.0.2. http://dast.nlanr.net/projects/Iperf, 2005.

[2] Gordon Bell, Jim Gray, and Alex Szalay. Petascale Computa-tional Systems. IEEE Computer, 39(1):110–112, 2006.

[3] Joe Burrescia and William Johnston. ESnet Status Update.Internet2 International Meeting, 2005.

[4] D. R. Commander. VirtualGL: 3D Without Boundaries – TheVirtualGL Project. http://virtualgl.sourceforge.net/, 2007.

[5] Hewlett Packard Company. Remote Graphics Software.http://h20331.www2.hp.com/Hpsub/cache/286504-0-0-225-121.html, 2006.

[6] HorizonLive.com, Inc. VNC Reflector. http://vnc-reflector.sourceforge.net/, 2007.

[7] Greg Humphreys, Mike Houston, Ren Ng, Randall Frank, SeanAhern, Peter D. Kirchner, and James T. Klosowski. Chromium:A Stream-Processing Framework for Interactive Rendering onClusters. In SIGGRAPH ’02: Proceedings of the 29th AnnualConference on Computer Graphics and Interactive Techniques,pages 693–702, New York, NY, USA, 2002. ACM Press.

[8] IBM Systems and Technology Group. IBM DeepComputing Visualization Technical White Paper. http://www-03.ibm.com/servers/deepcomputing/visualization/downloads/dcv%techwp.pdf, 2005.

[9] Silicon Graphics Inc. OpenGL Vizserver. http://www.sgi.com/products/software/vizserver/, 2007.

[10] Internetworking Technology Group, National Institute for Stan-dards and Technology. Nist NET. http://www-x.antd.nist.gov/nistnet/, 2007.

[11] Kurt Pfeifle. NX Components. http://openfacts.berlios.de/index-en.phtml?title=NX_Components, 2007.

[12] F. Lamberti and A. Sanna. A Streaming-Based Solution forRemote Visualization of 3D Graphics on Mobile Devices.IEEE Transactions on Visualization and Computer Graphics,13(2):247–260, March-April 2007.

[13] Jenn McGee and Ken Jones. SGI OpenGL VizserverAdministrator’s Guide. http://techpubs.sgi.com/library/manuals/4000/007-4481-008/pdf/007-4481-%008.pdf, 2004.

[14] Mercury International Technology, Inc. ThinAnywhere. http://www.thinanywhere.com, 2007.

[15] U.S. Department of Energy Office of Science. ScientificDiscovery Through Advanced Computing. http://www.scidac.org, 2007.

[16] Red Hat, Inc. Distributed Multihead X Project. http://dmx.sourceforge.net/, 2007.

[17] Tristan Richardson, Quentin Stafford-Fraser, Kenneth R. Wood,and Andy Hopper. Virtual Network Computing. IEEE InternetComputing, 2(1):33–38, 1998.

[18] Simon Stegmaier, Marcelo Magallon, and Thomas Ertl. AGeneric Solution for Hardware-Accelerated Remote Visualiza-tion. In VISSYM ’02: Proceedings of the Symposium on DataVisualisation 2002, pages 87–94, Aire-la-Ville, Switzerland,Switzerland, 2002. Eurographics Association.

[19] Tungsten Graphics, Inc. VNC Proxy. http://vncproxy.sourceforge.net/, 2007.

[20] Visualization Group, Lawrence Berkeley National Laboratory.svPerfGL. http://codeforge.lbl.gov/projects/svperfgl, 2007.

[21] Hubert Zimmerman. OSI Reference Model – The ISO Model ofModel of Architecture for Computer Systems Interconnection.

14

IEEE Transactions on Communications, 28(4):425–432, April1980.

Brian Paul is a senior engineer and cofounderof Tungsten Graphics, Inc. His interests in-clude interactive rendering, visualization, andgraphics software development. He earned hisBS and MS degrees in computer science fromthe University of Wisconsin in 1990 and 1994,respectively. Brian is a member of the IEEE.

Sean Ahern is a computer scientist and the Vi-sualization Task Leader for the National Cen-ter for Computational Sciences at Oak RidgeNational Laboratory. He is ORNL’s PI withinSciDAC’s Visualization and Analytics Centerfor Enabling Technology. Prior to Oak Ridge,he was the Visualization Project Leader withinthe Advanced Scientific Computing (ASC)program at Lawrence Livermore National Lab-

oratory. He has extensive experience with distributed visualizationand data processing on computational clusters. He has won twoR&D 100 Awards for his work on the VisIt visualization systemand the Chromium cluster rendering framework. He holds degrees inComputer Science and Mathematics from Purdue University.

E. Wes Bethel is a Staff Scientist at LawrenceBerkeley National Laboratory and foundingTechnical Director of R3vis Corporation. Hisresearch interests include high performanceremote and distributed visualization algorithmsand architectures. He earned his MS in Com-puter Science in 1986 from the University ofTulsa and is a member of ACM and IEEE.

Eric Brugger is a computer scientist withLawrence Livermore National Laboratorywhere he is the project leader for VisIt, anopen-source, distributed, parallel scientific vi-sualization and analysis tool. He received anR&D 100 award in 2005 as part of the VisItdevelopment team. Eric has over 15 years ofexperience in scientific visualization. His areasof expertise include parallel rendering, parallel

visualization architectures, scientific data file formats, scientific datamodeling, and parallel I/O.

Rich Cook has worked for six years as acomputer scientist for the Lawrence LivermoreNational Laboratory Information Managementand Graphics Group. He graduated from Uni-versity of California, Davis with a Master’sdegree in computer science in 2001.

Jamison Daniel is presently full-time researchstaff in the Scientific Computing Group at theNational Center for Computational Scienceslocated within the Oak Ridge National Lab-oratory.

Ken Lewis is director of engineering for Tung-sten Graphics, Inc. He has 28 years experi-ence in the workstation and computer graphicsindustry. He has a MS degree in computerscience from the University of Colorado.

Jens Owen is CEO of Tungsten Graphics,Inc. He has been active in the graphics indus-try for many years: Director of Engineeringand Founder of Precision Insight, EngineeringManager at VA Linux Systems, EngineeringManager for a small X Server developmentcompany, and Graphics Software Developerfor Hewlett Packard’s Workstation Division.Jens holds a BSCS from Colorado State Uni-

versity.

Dale Southard is a computer scientist withLawrence Livermore National Laboratory. Heis currently the hardware architect for visual-ization and post-processing systems, as well asa developer and security specialist with bothvisualization and systems groups.