Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am using x11vnc over 15Mbit/s network with 20ms latency. When the screen is changing a lot x11vnc is slow - for example when I switch a tab in a browser, it takes almost two seconds until the view is fully redrawn.

The strange thing is that max connection speed of x11vnc is even during slow redrawing only about 10% of the available bandwidth. Why is x11vnc not using available bandwidth to speed the redrawing up? For example scp is using 100% of available bandwidth without problems.

How can I identify what is the bottleneck for x11vnc on my system? So far I think:

  1. 10% network usage => network is not a bottleneck
  2. fb read rate: 601 MB/sec => reading fb is not a bottleneck

Any ideas how can I further profile x11vnc and find out what is causing a slowdown?

For example is there any switch for x11vnc to show how much data it is handling and how long it takes to grab a screen, process and compress it and send it over the network?

share|improve this question

3 Answers 3

The reason is that the screen capture/renderer is inefficient. Many different VNC implementations play around with this to achieve better performance.

If you don't need to reflect exactly what is on the local console, a better solution is NoMachine's NX or FreeNX as a remote desktop environment. Performance is day and night compared to VNC even over WAN links.

share|improve this answer
up vote 1 down vote accepted

To answer my own question:

Switching from tight encoding to hextile encoding resolved the problem with slow redrawing completely.

To add some detail: I have noticed that during slow redrawing of the screen the cpu on the client was spiking to the 100% usage. I was using tight encoding and from the page VNC Tight Encoder - Comparison Results it can be seen that tight encoding is quite cpu intensive when compared to hextile encoding. After switching to hextile max cpu usage is never 100%, almost the whole available bandwidth is utilized and redrawing always takes less than a second. So the client's CPU was the bottleneck.


Or even better alternative (less bandwidth, low cpu usage and seems even faster than hextile) is to compile x11vnc with TurboVNC support and then use TurboVNC client.

share|improve this answer
    
Here are some bandwidth and compression time comparisons tightvnc.com/archive/compare.html –  huyz Apr 2 '13 at 6:47

I hope this should work. http://www.karlrunge.com/x11vnc/faq.html#faq ... search for VNC viewer parameters and x11vnc parameters:

It worked for me.

share|improve this answer
1  
Welcome to Server Fault! We really do prefer that answers have content, not pointers to content. This may theoretically answer the question however, it would be preferable to include the essential parts of the answer here, and provide the link for reference. –  Chris S Oct 10 '12 at 13:21

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.