From: Constantin K. <co...@ce...> - 2002-05-11 09:25:11
|
Hello Phillip, >>>>> "PP" == Phillip Pi <ph...@ap...> writes: PP> Awesome, I think I got it compiled and working! I am wondering. PP> Has anyone tried TightVNC over a dial-up modem connection that PP> goes up to 3.0 KB/sec? I tried using Best Compression, 8-bit PP> colors, 640x480 resolution, simple X desktop, etc. It still seems PP> slow. Are there anything else to make it faster? >> Please take a look at server logs under $HOME/.vnc/ directory, make >> sure the clients really use the Tight encoding (see the statistics >> in the logs). PP> What do you think from my pasted log? Can I simplify more? :) PP> [edited the logs to remove server/IP addresses] Ok, let me comment the logs. PP> 10/04/02 01:17:48 Got connection from client 209.245.78.xxx PP> 10/04/02 01:17:48 Protocol version 3.5 PP> 10/04/02 01:17:48 Ignoring minor version mismatch PP> 10/04/02 01:17:51 Pixel format for client 209.245.78.xxx: PP> 10/04/02 01:17:51 8 bpp, depth 8 PP> 10/04/02 01:17:51 true colour: max r 7 g 7 b 3, shift r 0 g 3 b 6 PP> 10/04/02 01:17:51 Using tight encoding for client 209.245.78.xxx PP> 10/04/02 01:17:51 rfbProcessClientNormalMessage: ignoring unknown encoding 8 PP> 10/04/02 01:17:51 Using compression level 9 for client 209.245.78.xxx PP> 10/04/02 01:17:51 Enabling X-style cursor updates for client 209.245.78.xxx PP> 10/04/02 01:17:51 Using image quality level 9 for client 209.245.78.xxx PP> 10/04/02 01:17:51 Enabling LastRect protocol extension for client 209.245.78.xxx The client was connected and requested Tight encoding and 8 bpp color format. PP> 10/04/02 01:18:07 Client 209.245.78.xxx gone PP> 10/04/02 01:18:07 Statistics: PP> 10/04/02 01:18:07 key events received 0, pointer events 139 PP> 10/04/02 01:18:07 framebuffer updates 8, rectangles 1350, bytes 25869 PP> 10/04/02 01:18:07 LastRect markers 3, bytes 36 PP> 10/04/02 01:18:07 cursor shape updates 4, bytes 328 PP> 10/04/02 01:18:07 copyRect rectangles 131, bytes 2096 PP> 10/04/02 01:18:07 tight rectangles 1212, bytes 23409 PP> 10/04/02 01:18:07 raw bytes equivalent 968249, compression ratio 41.362254 Well, the connection was only 16 seconds long, and the server sent 25869 bytes to the client. The strange thing here is that the updates are very small (1212 rectangles, about 19 compressed bytes each rectangle on average, where 12 bytes is the size of rectangle header data, regardless of the encoding). Another interesting issue is that there were many CopyRect rectangles. I think that low performance here is not related to the encoder or pixel format. When there are so many _very_ small rectangles, they would be encoded inefficiently by any encoder, due to the nature of the RFB protocol. I think this behaviour (sending too many small rectangles) is application specific. What application did you use on the server during that session? I planned to work on improvement for Xvnc that could combine many small rectangles together, to improve average throughoutput, but had no possibility to find the time / money support for the project. Maybe I'll work on that at some point, but I would not promise to do it really soon. -- With Best Wishes, Constantin |