x11vnc est lent, mais n'utilise que 10% de la bande passante disponible

J'utilise x11vnc sur un réseau à 15 Mbits / s avec une latence de 20 ms. Lorsque l'écran change beaucoup, x11vnc est lent - par exemple, lorsque je change d'onglet dans un navigateur, il faut presque deux secondes pour que la vue soit entièrement redessinée.

Ce qui est étrange, c'est que la vitesse de connexion maximale de x11vnc n'est même pendant le redessin lent que d'environ 10% de la bande passante disponible. Pourquoi x11vnc n'utilise-t-il pas la bande passante disponible pour accélérer le redessin? Par exemple, scp utilise 100% de la bande passante disponible sans problème.

Comment identifier le goulot d'étranglement pour x11vnc sur mon système? Jusqu'à présent, je pense:

1. 10% d'utilisation du réseau => le réseau n'est pas un goulot d'étranglement
2. taux de lecture fb: 601 Mo / sec => la lecture fb n'est pas un goulot d'étranglement

Toutes les idées comment puis-je profiler x11vnc et découvrir ce qui cause un ralentissement?

Par exemple, existe-t-il un commutateur pour x11vnc pour afficher la quantité de données qu'il gère et combien de temps il faut pour récupérer un écran, le traiter et le compresser et l'envoyer sur le réseau?

Pour répondre à ma propre question:

Le passage d'un codage serré à un codage hextile a résolu complètement le problème du redessin lent.

Pour ajouter quelques détails: j'ai remarqué que lors du lent redessinage de l'écran, le processeur du client atteignait 100% d'utilisation. J'utilisais un encodage serré et à partir de la page VNC Tight Encoder - Résultats de comparaison, on peut voir que l'encodage serré est assez gourmand en CPU par rapport à l'encodage hextile. Après le passage à l'utilisation maximale du processeur hextile, l'utilisation n'est jamais de 100%, presque toute la bande passante disponible est utilisée et le redessin prend toujours moins d'une seconde. Le processeur du client était donc le goulot d'étranglement.

Ou encore meilleure alternative (moins de bande passante, faible utilisation du processeur et semble encore plus rapide que hextile) consiste à compiler x11vnc avec le support TurboVNC , puis à utiliser le client TurboVNC .

La raison en est que la capture d'écran / rendu est inefficace. De nombreuses implémentations VNC différentes jouent avec cela pour obtenir de meilleures performances.

Si vous n'avez pas besoin de refléter exactement ce qui se trouve sur la console locale, une meilleure solution est NX ou FreeNX de NoMachine en tant qu'environnement de bureau distant. Les performances sont de jour comme de nuit par rapport à VNC, même sur des liaisons WAN.

J'espère que cela devrait fonctionner. http://www.karlrunge.com/x11vnc/faq.html#faq ... recherchez les paramètres du visualiseur VNC et les paramètres x11vnc:

Ça a marché pour moi.