The Artima Developer Community
Articles | Discuss | Print | Email | First Page | Previous | Next
Sponsored Link

The Desktop as a Grid Service
Test-Driving Sun's Prototype Display Grid
by Frank Sommers
February 8, 2006

<<  Page 5 of 5


Bandwidth Versus Latency

In addition to subjective observations, we wanted to measure the Sun Ray's actual bandwidth consumption in the context of using the above applications. In order to gauge the Sun Ray's actual bandwidth use during the above interactive workload, we proceeded to measure the point-to-point peak available bandwidth between the remote Sun Ray server and the Sun Ray device.

While a DSL connection presents asymmetrical network bandwidth, with more bandwidth available for download than for upload, that matches the bandwidth requirements of a Sun Ray session, since most data is transmitted from the server to the thin client device at the network's edge. Thus, we focused on measuring download bandwidth from the remote server.

To eliminate TPC/IP connection startup latency from the measurements, we wrote a simple client-server bulk data transfer application. The server portion of that application ran inside a residential network on a fast laptop running the Fedora Core 4 version of Linux. The client portion, running on the remote Sun Ray server, opened a connection to the server and transfered a specified amount of bytes as character data from the Sun Ray server. To collect representative samples, we transferred 1 MB and 10 MB amounts of bulk data, and repeated each transfer three times at various times of the day, with the following results:

Bytes Sent Client's Time Server's Time Bandwidth on Client Bandwidth on Server
1 1 MB 9,085 ms 9,201 ms 901.7 Kbps 890.34 Kbps
2 1 MB 9,117 ms 9,191 ms 898.54 Kbps 891.3 Kbps
3 1 MB 8,648 ms 8,865 ms 947.27 Kbps 925.23 Kbps
4 10 MB 85,382 ms 85,403 ms 959.45 Kbps 959.22 Kbps
5 10 MB 84,891 ms 84,984 ms 965 Kbps 963.95 Kbps
6 10 MB 89,040 ms 89,049 ms 920.03 Kbps 919.94 Kbps
Average bandwidth measured: 932.00 Kbps 925.00 Kbps
Table 2: Point-to-point available bandwidth between CXONet Sun Ray server and residential DSL line.

Measurements done on 8/25/05. Solaris 10 CXO Server. Linux 2.6.12, Fedora 4. 3.2 Ghz Intel Pentium 4, 512 MB of memory. Network: SBC Yahoo DSL, 10 Mb/s 801.11/b wireless network, Linksys router. No significant difference detected over a 100Mb/s switched Ethernet.

As the table illustrates, at best the connection offered 965 Kbps of sustained bandwidth; the worst-case bandwidth was 890 Kbps. Given these samples, the average amount of sustained bandwidth between the DSL connection and the remote Sun Ray server was 928.5 Kbps.

Next, we proceeded to measure the thin client's bandwidth consumption during typical use of each of the four categories of applications listed above. A Sun engineer kindly set up a utility on the Sun Ray server that took a snapshot of the amount of data transferred between the Sun Ray server and the remote thin client device. With this utility collecting measurements, we proceed to work as usual with each of the four types of applications: Using the StarOffice spreadsheet to edit a dataset consisting of several hundred rows; reading and replying to email with Mozilla Thunderbird; developing Java code with IntelliJ IDEA; and browsing the Web with Mozilla Firefox.

We used each application exclusively for 30 minutes and took snapshots of the amount of bandwidth consumed in each 20-second interval. The following diagram shows the amount of data transferred in each measurement period, in each application use session as well as during the idle 30 minutes:

Figure 7: Amount of data transferred in each 20-second time period between a Sun Ray server. Four applications were measured, each session lasting 30 minutes.

As the diagram indicates, the amount of data transferred from client to server tends to be bursty. Since such data transfers represent mostly screen updates, replacing the local cache's content with new pixel data, most bursts occur when large sections of the screen require updates.

Predictably, Web browsing required the most updates, since the screen had to update not only each time the browser loaded a new Web page, but also during scrolling a page. IntelliJ's bandwidth consumption reflected the loading of new code text, scrolling, and switching between editor windows, as well during running unit tests. During code edits, however, very little screen update activity took place. The email program's bandwidth usage mirrors the pattern of loading a new email message and composing replies in a new window. The spreadsheet exhibits a more uneven usage: While editing spreadsheet data within a single screen view, no scrolling was involved, and hence the editing activity consumed little bandwidth; the peaks represent scrolling activity. Table 3 summarizes these measurements:

Idle Time StarOffice Spreadsheet Reading Email with Thunderbird Developing with IntelliJ IDEA Web Browsing with Firefox
Total bytes transferred 321.51 KB 15,057.7 KB 22,553 KB 23,560.08 KB 43,464.89 KB
Avg bandwidth consumed 1.43 Kbps 66.92 Kbps 100.24 Kbps 104.71 Kbps 193.18 Kbps
Avg of available bandwidth consumed 0.11% 7.21% 10.8% 11.28% 20.81%
Peak bandwidth consumed 23.61 Kbps 428.15 Kbps 420.06 Kbps 405.09 Kbps 894.44 Kpbs
Max. of available bandwidth consumed 2.54% 46.11% 45.24% 43.63% 96.11%
Table 3. Bandwidth consumption during four workloads, each involving a different application, in addition to idle time.

The summary table computes the average bandwidth consumed by each activity during each 30-minute session, the peak bandwidth occurring in any 20-second interval, and the relationship of the bandwidth consumed by each activity to the total available bandwidth on the network connection.

While Web browsing required the most screen updates, and hence the most bandwidth, even that activity took advantage of only 20.81% of the total bandwidth available between the server and thin client, with an average bandwidth requirement of 193.18 Kbps. Web browsing also proved the burstiest activity, with the highest peak requiring 96.11% of the available bandwidth. The other usage patterns required much less bandwidth, and proved much less bursty. None of the activities took up the maximum bandwidth available between the Sun Ray server and the thin client at the DSL end of the connection.

These four application categories represent only a subset of desktop usage patterns, and exclude, for instance, multimedia, such as streaming video. RealVideo and the Java Media Player executing on the remote desktop did not compare well to using those applications on a local desktop, suggesting higher bandwidth requirements.

Apart from multimedia applications, however, bandwidth no longer appears to be a limiting factor in broader consumer deployment of the Sun Ray remote desktop service. This experiment suggests that the occasional screen redraw delays are not the result of insufficient network bandwidth between the Sun Ray server and the thin client. Barring bandwidth as the cause leaves network latency as the possible cause of redraw delays. That latency may be caused by the Internet connection between the Sun Ray server and the thin client, and might also be caused by constraints on the server or the thin client to process the Sun Ray protocol commands.

While more measurements are needed to determine the key source of latency, should limitations in processing capability on either the client or server be among the reasons, protocol commands can be optimized to trade more bandwidth for less computational intensity. For instance, compressing less protocol commands would consume more bandwidth between client and server, but would relieve both of some processing work. In addition, much of the server's work can be distributed on a grid to scale up the server's processing ability.

Reducing the latency inherent in the Internet connection between server and thin client requires a network topology designed to minimized the hops between the connection endpoints. Such a network might be relatively straightforward to build, and several commercial network providers already operate colocation facilities in close network proximity to most end-users, such as in large metropolitan areas. Placing Sun Ray servers at these locations, and directing a user's session to a server in near proximity to the user could help reduce network latency. Such dynamic redirection, however, would also require possible additions to the Sun Ray protocols to determine which server to direct the user's session's after login.

Future Possibilities

The Sun Ray system currently requires a dedicated thin client device. Since the architecture can be implemented in software as well, should Sun make a Sun Ray client available as a software package, or even open-source that software, possibly any network-connected client could access a remote Sun Ray server.

The Sun Ray architecture's relatively low computation and memory requirements on the client make that an especially attractive option for mobile devices[24] [25] [26]. For instance, a cell phone connected to the network via a cellular network or WiFi could run the Sun Ray software, and render the display to a BlueTooth-enabled display. The cell phone could also integrate a BlueTooth-enabled keyboard and mouse to provide a complete portable desktop experience. Recent developments with foldable displays and miniaturized, expandable keyboards, together with a ubiquitous Sun Ray client, could foreshadow a new era in mobile computing[27] [28].


The author would like to thank Brian Foley, Bob Gianni, and Ismet Nesmicolaci, all with Sun Microsystems, Inc., for assistance in evaluating the Sun prototype display grid.

Talk back!

Have an opinion about display grids? The Desktop as a Grid Service


[1] Bob Bemer, best-known as the "father of ASCII" described the time-share concept in 1957. The first system implementing the concept was MIT's Multiple Access Computer, Machine Aided Cognition, or Project MAC.

[2] John McCarthy. Reminiscences on the History of Time Sharing Presented at Stanford University, about 1983.

[3] D. M. Ritchie and K. Thompson. The UNIX Time-Sharing System. Communications of the ACM, 17, No. 7 (July 1974), pp. 365-375.

[4] D. M. Ritchie. The Evolution of the Unix Time-sharing System. AT&T Bell Laboratories Technical Journal 63 No. 6 Part 2, October 1984, pp. 1577-93.

[5] The Java Authentication and Authorization Service (JAAS).

[6] D. Balfanz and L. Gong. Experience with Secure Multi-Processing in Java Proceedings of the IEEE International Conference on Distributed Computing Systems, 1998.

[7] I. Foster, C. Kesselman and S. Tuecke. The Anatomy of the Grid. Enabling Virtual Organizations International Journal of Supercomputing Applications, 2001.

[8] M. Wahl, et al. Lightweight Directory Access Protocol Internet Engineering Task Force RFC 2251. 1997.

[9] Sun Microsystems, Inc. NFS: Network File System Protocol Specification. Internet Engineering Task Force RFC 1094. 1989.

[10] SAMBA

[11] I. Foster and C. Kesselman, editors. The Grid 2: Blueprint for a New Computing Infrastructure. Morgan Kaufmann, 2003. link

[12] M. Vernon. Save money by taking control of your desktops TechRepublic, August 23, 2005,39020481,39214436,00.htm

[13] X Windows.

[14] Citrix Access Suite

[15] Citrix GoToMyPC

[16] Microsoft Remote Desktop Protocol

[17] Virtual Network Computer

[18] R. Baratto, J. Nieh and L. Kim. THINC: A Remote Display Architecture for Thin-Client Computing Technical Report CUCS-027-04, Department of Computer Science, Columbia University, July 2004.

[19] Sun Ray Thin Client

[20] B. K. Schmidt, M. L. Lam, and J. D. Northcutt. The Interactive Performance of Slim: A Stateless Thin Client Architecture. Operating Systems Review, 34(5): 33-47., 1999.

[21] Firefox and Thunderbird

[22] OpenOffice

[23] IntelliJ IDEA

[24] A. M. Lai, J. Nieh, B. Bohra, V. Nandikonda, A. P. Surana, and S. VarshneyaMobility. Improving Web Browsing Performance on Wireless Pdas Using Thin-Client Computing Proceedings of the 13th ACM International Conference on World Wide Web, 2004.

[25] S. J. Yang, J. Nieh, S. Krishnappa, A. Mohla, and M. Sajjadpour. Mobility and Wireless Access: Web Browsing Performance of Wireless Thin-Client Computing Proceedings of the 12th international conference on World Wide Web, 2003.

[26] A. Lai, J. Nieh. Limits of Wide-Area Thin-Client Computing. Proceedings of the 2002 ACM SIGMETRICS International Conference on Measurement and Modeling of Computer Systems, 2002.

[27] P. Sayer. Notebooks to Get Foldable Displays PC World, September 6, 2000.,aid,18349,00.asp

[28] L. Valigra. Next Digital Screen Could Fold Like Paper Christian Science Monitor, January 8, 2004.

About the author

Frank Sommers is an Artima Developer Senior Editor. He is also founder and president of Autospaces

<<  Page 5 of 5

Articles | Discuss | Print | Email | First Page | Previous | Next

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use