[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xougen] GPL-ed X compression scheme -- my gaff

From: Gian Filippo Pinzari
Subject: Re: [xougen] GPL-ed X compression scheme -- my gaff
Date: Wed, 1 Oct 2003 04:31:22 +0200
User-agent: KMail/1.5

First of all thank you for your attention to our NX work. We also aim 
at a better X-Window. We hope to see fruitful cooperation between 
Xouvert and NoMachine. 

On Sat, 27 Sep 2003 02:02:34, Jonathan Walther wrote:
> I seem to recall Keith Packard saying he'd tested it, and there wasn't
> much of a performance win over using raw gzip compression on the data
> stream. 

I don't remember to have ever read something like this. Did Keith say this
in a private conversation?

I read here:


that Keith think that raw gzip compression can offer sufficient compression
to make X work fine over 'moderately' low-bandwidth links, given that 
programmers pay attention to writing smarter X clients. I don't have any 
evidence he ever tried our software.

Compression applied to an interactive network protocol is something very
complex to design and implement. On the other hand it is very simple to
evaluate. It is 'good' if it lets you work confortably in front of your remote
desktop and it is 'bad' otherwise. Is Zlib enough to run X over low-bandwidth 
links? Well, it probably depends on the definition of 'low-bandwidth' links. 
NX goal is to let users run X applications over the Internet, with a bandwidth 
of 3 KBps and a latency in the order of 200 ms. Everything requiring more 
bandwidth or assuming lower latency is simply not enough. 

Zlib compression in SSH can offer an average compression of 4:1. This 
is a very good ratio for a generic compressor. I'm speaking about running 
a contemporary X environment, like a GNOME or KDE desktop, browsing 
the Internet and making office automation, not just downloading a tiled 
background. This compression can be more than enough if you have a 
DSL connection and 256Kbps downstream, but you need 40:1 if you have 
an analog modem, you are many hops away or are downloading a video 
at the same time. NX provides an average compression exceeding 70:1 
in the same conditions, still offering less overhead (due to caching) and 
better interactivity (due to improved flow control and other nifty features 
made possible by intelligent multiplexing, like streaming of big requests). 
Maybe most X users have broadband connections and don't need better 
compression, but better compression is mandatory if you want to run X 
applications on mobile phones or in other environments where bandwidth 
is a costly resource. Note that you need good and fast compression 
even if you want to run more than a handful of X sessions on a LAN.

Having said that, I would add that I don't see any need to merge most 
of NX improvements in the X protocol. As noted by Keith Packard in the 
above document, it would be enough to let Xlib and other extension libra-
ries clear the padding bytes in the protocol. This would benefit SSH+Zlib 
as well as NX. NX was designed to stay on top (or aside) of X-Window. 
Our goal is to develop a framework and an architecture to run X (and other 
applications based on open protocols) over the Internet, in a peer-to-peer 
fashion. NX and X-Window can walk and improve together. We would like 
to see NX integrated in Linux and Unix, that's another story.

How NX can help building a better X-Window? Well, probably by allowing
normal users, not only geeks, to run X over the network. More X-users = 
more and better X-applications. NX can help developers, also, by means
of the reporting capabilities of nxproxy. X protocol statistics are easily 
accessible through the admin client or by sending to nxproxy a SIGUSR1 
or a SIGUSR2 signal. Statistics are stored in file 'stats', in the session 
directory. Obviously you can get X protocol statistics running xmon or 
other tools... But it is easier in NX and, most importantly, always available. 
I'm sure that if X developers would have a chance to look at X statistics 
more often, they would easily and naturally write more X-protocol friendly 
applications. Remember: if an application works fine with NX it will work 
even better with SSH+Zlib and wonderfully well with plain X :-).

With my best regards,

/Gian Filippo Pinzari.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]