USENIX Association Proceedings of the FREENIX Track: 2003 USENIX Annual Technical Conference San Antonio, Texas, USA June 9-14, 2003 THE ADVANCED COMPUTING SYSTEMS ASSOCIATION © 2003 by The USENIX Association All Rights Reserved For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.org Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein. X Window System Network Performance Keith Packard Cambridge Research Laboratory, HP Labs, HP [email protected] James Gettys Cambridge Research Laboratory, HP Labs, HP [email protected] Abstract havior (or on a local machine, context switches between the application and the X server). Performance was an important issue in the develop- One of the authors used the network visualization tool ment of X from the initial protocol design and contin- when analyzing the design of HTTP/1.1 [NGBS 97]. ues to be important in modern application and extension The methodology and tools used in that analysis in- development. That X is network transparent allows us volved passive packet level monitoring of traffic which to analyze the behavior of X from a perspective seldom allowed precise real-world measurements and compar- possible in most systems. We passively monitor network isons. The work described in this paper combines this packet flow to measure X application and server perfor- passive packet capture methodology with additional X mance. The network simulation environment, the data protocol specific analysis and visualization. Our experi- capture tool and data analysis tools will be presented. ence with this combination of the general technique with Data from this analysis are used to show the performance X specific additions was very positive and we believe impact of the Render extension, the limitations of the provides a powerful tool that could be used in the analy- LBX extension and help identify specific application and sis of other widely used protocols. toolkit performance problems. We believe this analysis With measurement tools in hand, we set about char- technique can be usefully applied to other network pro- acterizing the performance of a significant selection of tocols. X applications based on a range of toolkits and using 1 Introduction a variety of different implementation techniques. We are specifically interested in the effects of the Render The X Window System [SG92] was designed to of- extension’s [Pac01] approach to text, and whether the fer good performance over campus area networks for optimizations offered by the Low Bandwidth X (LBX) machines and applications in common use in the late extension [FK93] [Pac94] were of any use. Specific ap- 1980’s. A major part of the version 11 protocol design plication performance issues were also discovered and was to reduce the effect of network latency and band- forwarded to the relevant open source projects. width on application performance and correctness ob- served in analysis of X10 programs. Resource ID al- 2 Measuring X Performance location was moved to the client applications to elim- inate synchronous resource creation. Synchronous de- The measurements taken span a range of applications, vice grabs were added to provide correct operation of network characteristics and protocol compression tech- user interfaces when the user could manipulate input de- niques. vices faster than the applications could respond. The 2.1 Selecting Test Applications selection mechanism was added to provide a uniform cut&paste model while delaying and optimizing the un- An attempt was made to select applications representa- derlying bulk data transfer. Experience over the last 15 tive of modern X usage. Reasonably current versions of years has shown that further work in this area is possible each application were selected from the Debian Linux and desirable. distribution. One advantage of the passive monitoring There has previously never been packet level research technique is the ability to monitor several applications capturing and analyzing the actual network characteris- simultaneously and measure the performance of the col- tics of X applications. The best tools available have been lection as they interact on the network. This permits the dumps of proxy servers showing requests and responses, analysis of session startup sequences where many appli- with no direct correlation with the actual packet level re- cations are competing for resources. quests/responses and timing that determine network be- The following applications were measured in this ini- USENIX Association FREENIX Track: 2003 USENIX Annual Technical Conference 207 tial work LBX was an effort to improve performance over low- Mozilla (version 1.3); Web browser with client-side speed/high-latency links. A significant amount of that fonts, imaging the microscape synthetic web page work was focused on reducing latency effects of slow developed for the HTTP/1.1 performance work links without modifying applications. Another major Mozilla (version 1.3); Web browser with server- part of the work was in creating custom encodings of side fonts, imaging the microscape synthetic web X data to reduce the bandwidth required. The latency page developed for the HTTP/1.1 performance efforts focused on problems seen when LBX was being work designed. How well those efforts carry forward to mod- Kedit (Version 1.3) simple text editor based on the ern applications is explored in this paper. Qt toolkit More recently, network proxy support has been Nautilus (Version 2.2.2) file browser based on the added to the SSH [BS01] protocol enabling X con- GTK+ toolkit nections to be forwarded through a secure and option- KDE Session (Version 3.1) full KDE session ally compressed connection. SSH has no X-specific re- startup. encoding or compression techniques, it simply uses the Gzip [Gai93] compression technique on the datastream 2.1.1 Mozilla and Fonts when compression is enabled. Because of the rapid uptake of client-side fonts in appli- Measurements using raw X protocol as well as X run cation development, Mozilla was the only current appli- through both of these proxies show their effectiveness in cation available that supports both core and client-side improving performance. fonts in the same version. The current Debian Mozilla package provides an alternate version of the key drawing 3 Passive Network Analysis library that controls access to fonts; the only change in In the past, ethernet data monitoring required very little the Mozilla configuration required to select which style equipment; any host could trivially monitor traffic on the of fonts to use is to replace this library with the appropri- wire from any other host by placing the ethernet hard- ate version. This limits the changes as much as possible ware in promiscuous mode. Such is not the case today; which should make the resulting measurements an ac- twisted pair ethernet performance depends on switched curate representation of the difference between the two connections to provide a collision free link between the techniques. two endpoints. The easiest way to monitor the network is to capture packets on one end of the connection. While 2.1.2 KDE Session and LBX this may consume some CPU resources, the overhead is The XFree86 4.3 releases of the LBX extension and minimal given modern machine performance. Alterna- proxy are faulty, causing the KDE session to hang about tively, a “man in the middle” machine can be used to halfway through the startup process. Some modest at- capture packet traces between client and server. There tempts to discover the problem did not yield any results are also network switches which can mirror traffic from and so those values don’t appear in the resulting graphs. one port to another, but a single connection cannot reli- ably hold traffic from a full-duplex link and so packets 2.2 Network Performance Characteristics might be lost or packet ordering scrambled. For either For this study, one goal was to measure the performance host-based technique, systems are now fast enough that impact of latency vs. bandwidth, and so a set of la- it is possible to capture all packets in most applications tency and bandwidth values were used and each test without drops. We chose to capture packets on the X run with every pair of latency and bandwidth. The five client end of the network approach as the network sim- bandwidths used were 100Mb, 10Mb, 1Mb, 100Kb and ulator caused problems with capture at the router. The 10Kb. The four latencies used were 0.1ms, 1ms, 10ms passive capture configuration can be see in Figure 1. and 100ms. These latencies represent the time for a packet to traverse through the router in one direction, 3.1 Network Data Capture and so a round trip time would be at least twice that To minimize the impact of disk activity on the network value. monitoring process, the packet capture tool provides minimal information about each network event that is 2.3 X Protocol Encoding seen in the protocol trace. Each trace record is times- The X protocol was originally designed to run effi- tamped with that captured by the kernel packet logging ciently over the campus area networks available in the facility which provides kernel-level timestamping accu- late 1980’s, which ran at 10Mb/second. As modem per- rate to well under a millisecond. The capture application formance improved in the early 1990’s it became almost is run at nice -20 which has proven sufficient to avoid feasible to run X applications over dial-up links. packet loss. 208 FREENIX Track: 2003 USENIX Annual Technical Conference USENIX Association 3.2 Simulating Network Conditions X client X client X client The NISTNet package [Gro00] converts a Linux ma- chine into a network emulator capable of simulating a wide variety of network conditions.