[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:
http://keithp.com/~keithp/talks/usenix2003/html/net.html
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.