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 [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
