Re: About our effort at NoMachine

On Thursday 27 March 2003 02:11 am, Keith Packard wrote:
> Around 1 o'clock on Mar 27, Gian Filippo Pinzari wrote:
> > Yep. Keith Packard, if I remember correctly, seems to not agree
> > on proxies being used as a long term solution,
>
> Not on proxies in general, of which SSH is a good example, but only on the
> LBX proxy in particular which has the very bad behaviour of operating a
> request at a time which increases latency for large requests even further.
>
> However, all of my measurements over DSL-style lines (<1Mb bandwidth >
> 50ms rtt) show that bandwidth is not a significant problem, and that the
> dominant cost remains latency, even for image intensive applications like
> web browsers.

I completely agree, but I'm speaking about 33Kbps links :-). In my opinion
SSH is not even an option. Zlib compression in SSH can achieve a ratio
of 5:1. With NX you get an average compression ratio of 50:1. It can be
200:1 in case of a Web banner or 150:1 as it is common at session startup
if you already have a cache file.

Zlib is not designed to compress big amounts of data in real-time. The
performance penalty of compressing raw X protocol through Zlib is quite
significant. Test showed that NX compression is >10 times faster than
raw Zlib compression of X protocol, still offering >10 times better
compression. Reason is very simple. NX is designed to just compress
X traffic, not generic data. I know it's hardly to believe. We include a
session administration client that can be used to get partial and total X
protocol statistics while session is running. It even offers CPU usage
statistics. I think somebody should give this stuff a try.

> If done in a trivial manner, image caching will also introduce latency for
> misses as the proxy will be forced to wait for the entire image to be
> available from the client before locating it in the cache.  However, I can
> imagine a clever cache which could recognise a miss early and start
> streaming the image as soon as that was detected.

This is the way it is implemented.

> > They can finally leverage the cross-client recurrence of common X
> > operations to achieve significant compression ratios.
>
> LBX attempted this for some operations with limited success; server
> startup data and keymapping information could be supplied from the local
> cache.  I wonder how much additional data could be shared in this fashion,

Between 70% and 80% of total traffic, depending on requests. Could be
more, but the differential algorithms for some requests are so efficient to
make caching useless. Requests, event and replies are compressed to
an average of 16 bits each. This includes images. I'm speaking of normal
X sessions, browsing the Internet and reading e-mails. If you want to watch
a MPEG4 video, don't expect 50:1 compression :-).

> and again, if the effect is only to reduce data on the wire, the technique
> won't be nearly as effective as one which could short-circuit the X server
> entirely.

As I told, we devoted a lot of time to short-circuit almost everything at X
client side, even X Expose events. The X traffic produced by NX is almost
completely streaming of requests and images and, infact, is amazingly
effective.

>
> > Proxies can efficiently multiplex the traffic, and optimize bandwidth
> > usage according to the type of traffic being generated.
>
> Seems like you're reimplementing TCP on top of TCP.  In my experience, TCP
> works pretty well without an additional multiplexing layer on top.

Of course, but through multiplexing I can put together those 100 bytes
produced by each of my 3 different clients, find repeated sequences
and stream compress the result, wait for some other client that needs
to write and finally write only if the link is not congested, otherwise can
put at sleep some of the clients that are generating more traffic and
give precedence to those that are waiting for a reply. Do this with 3
different TCP connections.
 
>  This
> was one of the significant problems in LBX as large requests could
> monopolize the wire for a long time.

Infact we split big requests in chunks and stream them interleaved with
higher priority traffic. Let me explain my point. Xlib buffer is 1024 bytes.
Consider I compress it 20:1. I get a packet of 50 bytes. I don't think
packet fragmentation is a better option.

>  Using one TCP stream per client
> means each client gets a fair share of the network bandwidth.

In theory should work. Unfortunately I'm not sure pppd is sharing our
point of view :-). Try to run a NX session over a modem link while you
are copying a file through SSH...

/Gian Filippo.