x11vnc es lento, pero usa solo el 10% del ancho de banda disponible

Estoy usando x11vnc en una red de 15Mbit / s con latencia de 20ms. Cuando la pantalla cambia mucho, x11vnc es lento; por ejemplo, cuando cambio una pestaña en un navegador, la vista tarda casi dos segundos en volver a dibujarse completamente.

Lo extraño es que la velocidad máxima de conexión de x11vnc es incluso durante el redibujado lento solo alrededor del 10% del ancho de banda disponible. ¿Por qué x11vnc no utiliza el ancho de banda disponible para acelerar el rediseño? Por ejemplo, scp está utilizando el 100% del ancho de banda disponible sin problemas.

¿Cómo puedo identificar cuál es el cuello de botella para x11vnc en mi sistema? Hasta ahora pienso:

1. 10% de uso de red => la red no es un cuello de botella
2. velocidad de lectura de fb: 601 MB / seg => leer fb no es un cuello de botella

¿Alguna idea de cómo puedo perfilar más x11vnc y descubrir qué está causando una desaceleración?

Por ejemplo, ¿hay algún interruptor para x11vnc que muestre cuántos datos está manejando y cuánto tiempo toma capturar una pantalla, procesarla, comprimirla y enviarla a través de la red?

Para responder mi propia pregunta:

El cambio de codificación estricta a codificación hextil resolvió el problema con un redibujado lento por completo.

Para agregar algunos detalles: he notado que durante el lento rediseño de la pantalla, la CPU en el cliente se disparó al 100% de uso. Estaba usando una codificación estricta y desde la página VNC Tight Encoder - Resultados de la comparación se puede ver que la codificación estricta es bastante intensiva en CPU en comparación con la codificación hextil. Después de cambiar a hextile, el uso máximo de la CPU nunca es del 100%, se utiliza casi todo el ancho de banda disponible y el rediseño siempre toma menos de un segundo. Entonces la CPU del cliente fue el cuello de botella.

O una alternativa aún mejor (menos ancho de banda, bajo uso de CPU y parece incluso más rápido que el hextil) es compilar x11vnc con soporte TurboVNC y luego usar el cliente TurboVNC .

La razón es que la captura de pantalla / renderizador es ineficiente. Muchas implementaciones de VNC diferentes juegan con esto para lograr un mejor rendimiento.

Si no es necesario para reflejar exactamente lo que está en la consola local, una mejor solución es NX de NoMachine o FreeNX como un entorno de escritorio remoto. El rendimiento es día y noche en comparación con VNC incluso a través de enlaces WAN.

Espero que esto funcione. http://www.karlrunge.com/x11vnc/faq.html#faq ... busque los parámetros del visor VNC y los parámetros x11vnc:

Funcionó para mi.