x11vnc è lento, ma utilizza solo il 10% della larghezza di banda disponibile

Sto usando x11vnc su rete 15Mbit / s con latenza di 20ms. Quando lo schermo cambia molto x11vnc è lento - ad esempio quando cambio una scheda in un browser, ci vogliono quasi due secondi prima che la vista sia completamente ridisegnata.

La cosa strana è che la massima velocità di connessione di x11vnc è anche durante il ridisegno lento solo circa il 10% della larghezza di banda disponibile. Perché x11vnc non utilizza la larghezza di banda disponibile per accelerare il ridisegno? Ad esempio, scp utilizza senza problemi il 100% della larghezza di banda disponibile.

Come posso identificare qual è il collo di bottiglia per x11vnc sul mio sistema? Finora penso:

1. 10% di utilizzo della rete => network non è un collo di bottiglia
2. frequenza di lettura fb: 601 MB / sec => leggere fb non è un collo di bottiglia

Qualche idea su come posso profilare ulteriormente x11vnc e scoprire cosa sta causando un rallentamento?

Ad esempio, c'è un interruttore per x11vnc per mostrare quanti dati sta gestendo e quanto tempo ci vuole per afferrare uno schermo, elaborarlo e comprimerlo e inviarlo in rete?

Per rispondere alla mia domanda:

Il passaggio dalla codifica stretta alla codifica hextile ha risolto completamente il problema con un lento ridisegno.

Per aggiungere alcuni dettagli: ho notato che durante il lento ridisegno dello schermo la CPU sul client stava aumentando l'utilizzo del 100%. Stavo usando la codifica stretta e dalla pagina VNC Encoder stretto - Risultati del confronto si può vedere che la codifica stretta è abbastanza intensiva per la CPU rispetto alla codifica hextile. Dopo il passaggio all'utilizzo massimo della cpu hextile non è mai al 100%, viene utilizzata quasi tutta la larghezza di banda disponibile e il ridisegno richiede sempre meno di un secondo. Quindi la CPU del client era il collo di bottiglia.

O un'alternativa ancora migliore (meno larghezza di banda, basso utilizzo della cpu e sembra persino più veloce dell'erile) è quella di compilare x11vnc con supporto TurboVNC e quindi utilizzare il client TurboVNC .

Il motivo è che l'acquisizione / rendering dello schermo è inefficiente. Molte diverse implementazioni VNC giocano con questo per ottenere prestazioni migliori.

Se non c'è bisogno di riflettere esattamente ciò che è attiva nella console locale, una soluzione migliore è NX NoMachine o FreeNX come ambiente desktop remoto. Le prestazioni sono diurne e notturne rispetto a VNC anche su collegamenti WAN.

Spero che questo funzioni. http://www.karlrunge.com/x11vnc/faq.html#faq ... cerca i parametri del visualizzatore VNC e i parametri x11vnc:

Ha funzionato per me.