[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xfree86-devel
Subject:    Re: Reengineering X applications
From:       Gian Filippo Pinzari <pinzari () nomachine ! com>
Date:       2004-05-12 13:02:37
Message-ID: 40A2206D.1080304 () nomachine ! com
[Download RAW message or body]

Suresh wrote:
> In the paper "Profiling the X Protocol" by John Daskin & Pat Hanrahan,
> Its is given that most X messages trains are less than 100 bytes and since
> the TCP/IP protocol adds 48 bytes of header information, this is a bigh
> overhead, (and hence he has suggested using Compressed Serial IP over PPP
> (CSLIP/PPP) since it adds only 7 bytes of header information. )
> 
> Does NX already adress this?

In previous versions of Xlib the display buffer was 1024
bytes. In current versions the size has been increased
to 4096. Actually applications seldom flush the buffer
when it is full. On the contrary, they often rely on
XSync() calls to force Xlib to flush the buffer and get
the available events. The figure of 100 bytes probably
doesn't reflect the status of modern X toolkits, but we
are not that far from reality. My data say that some
toolkits are much more efficient than others and in
this specific space, I think, there is lot of space for
improvements. These issues, anyway, are application
specific and not related to the X protocol. The wire
representation of the X messages is quite compact and
can hardly be improved.

Compression of X protocol (any compression) can easily
solve this overhead problem, given it is bundled with
efficient multiplexing. Neither would I consider this
a problem, as X can't work efficiently over the Internet
without encapsulation and multiplexing. Both SSH and NX
can do that and both SSH and NX pay attention to effi-
cient framing. About NX, great attention is obviously
devoted to these aspects. The document below explains
how NX compression is working:

http://www.nomachine.com/documentation/NX-XProtocolCompression.php

At the best compression level, NX reduces the size of
each distinct X protocol message to an average of 12/18
bits, depending on the application. The size of each
frame transmitted over the network is 100/120 bytes. At
a compression ratio of 20:1 it means that each frame
carries 2000 bytes of X data. By increasing the size of
the frame by 20% we can expect a comparable increase in
performance. nxproxy tries to queue as many message is
possible in each frame but it lacks precise information
on when it's the right time to flush the link (the
GetInputFocus/XSync messages coming from the clients are
not a reliable source of information) and it can't wait
too long without affecting the responsiveness. Presently
the coalescence time in case of modem connections is 40
ms.

You can get very detailed statistics by running
nxlcient --admin. Statistics include number and size
of the X messages, number and size of the frames and
the multiplexing overhead.

/Gian Filippo.


_______________________________________________
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
[prev in list] [next in list] [prev in thread] [next in thread]