An LBX Postmortem

Keith Packard

LBX Architect

XFree86 Core Team

SuSE, Inc.

Abstract

Current applications are analyzed to judged the efficacy of the techniques
used by LBX to improve X performance over low-bandwidth/high-latency network
links. The results show that LBX fails to substantially improve performance
largely because of it's requirement to provide compatibility with the X wire
protocol. The historical context of the development of LBX has also
burdened it with the replication of a significant amount of network
infrastructure making it both overly complex and less efficient on the wire.

LBX Design Goals

LBX was designed to ameliorate the effects of limited bandwidth and high
latency network connections on the execution of X applications. It was
based on the simple X compression work done by Network Computing Devices
(Xremote) and Tektronix (Serial XPress).

Both of those protocols focused only only compressing the X bytestream using
relatively simplistic techniques. As they were developed in an era before
the widespread adoption of serial-line IP technologies (SLIP and PPP), both
also provide for the multiplexing of many X applications over a standard
RS232 link.

LBX was an attempt to analyze the successes of these two implementations and
develop a standard incorporating the best of them along with new
technologies. The most important new ideas were in reducing the effects of
higher network latency. However, without changing the internals of
applications, the areas where LBX can have effect are rather limited. LBX
provides for short-circuiting in pixel allocation and window property data
transmission between clients. It also caches Atom names to reduce round
trips when multiple applications intern the same Atom name.

X Applications Characteristics

X applications have usually been developed in a high-bandwidth/low-latency
environment, either entirely within a single machine or perhaps over a local
area network. Such environments exhibit bandwidth in excess of 1MB/sec and
latencies less than 1ms. Moving applications to serial lines decreases the
bandwidth by more than a factor of 100 and increases latency by a similar
amount.

Relatively simplistic analysis of X protocol traffic from current and older
X applications demonstrates that while limited bandwidth has an effect on
application performance, the largest effect comes from large network latency
usually present in low speed network links.

While version 11 of the X protocol was designed to allow for asynchronous
operation for almost everything, application development often takes
advantage of the relatively low latency provided by local or intra-computer
networking. Applications make frequent requests for data which could easily
be computed or cached. Xlib doesn't provide easy access to the underlying
asynchronous nature of the protocol forcing additional synchronization
points during application execution.

The effect of additional synchronous communication is most evident during
application startup; applications which start in less than one second over a
local network can take tens of seconds to start over a modem link. Much
less important are the smaller effects which occur during program operation
as application feedback latencies of less than 50 to 100ms are not generally
visible to the user.

X Application Behavior Analysis

To assess the value of the various LBX network optimizations, application
startup data were collected and analyzed to determine which operations
would affect startup times most significantly in the presence of a
low-bandwidth/ high-latency network link. What became evident was that
while the techniques present in LBX might help somewhat, the overwhelming
performance problems were caused by application and toolkit misfeatures that
couldn't be easily masked outside by an X protocol proxy.

Using X Over Slow Links

Interpretation of the application behavior lead to a set of simple
application and toolkit recommendations which would improve performance in
all networking environments. Such changes would not have the detrimental
effects of LBX in using a proxy while providing nearly all of the benefits.

The only useful changes to the wire protocol are the use of lossless image
compression within X or a full wire-level compression proxy such as SSH
underneath X. Again, these could be implemented without the addition of a
separate proxy agent.

Conclusion

As LBX is only able to slightly improve application performance over slow
network links, there has never been a significant effort to widely deploy
it. However, given the ability to modify the toolkits used by X
applications, the underlying performance problems can be fixed with
relatively modest changes providing better performance than LBX could offer
while avoiding the complexity of an external proxy agent.