O x11vnc é lento, mas usando apenas 10% da largura de banda disponível

11

Estou usando x11vnc em uma rede de 15Mbit / s com latência de 20ms. Quando a tela está mudando muito, o x11vnc fica lento - por exemplo, quando troco uma guia em um navegador, leva quase dois segundos até que a exibição seja totalmente redesenhada.

O estranho é que a velocidade máxima de conexão do x11vnc é, mesmo durante o redesenho lento, apenas 10% da largura de banda disponível. Por que o x11vnc não está usando a largura de banda disponível para acelerar o redesenho? Por exemplo, o scp está usando 100% da largura de banda disponível sem problemas.

Como posso identificar qual é o gargalo do x11vnc no meu sistema? Até agora eu penso:

  1. 10% de uso da rede => rede não é um gargalo
  2. taxa de leitura fb: 601 MB / s => ler fb não é um gargalo

Alguma idéia de como posso criar um perfil adicional do x11vnc e descobrir o que está causando uma desaceleração?

Por exemplo, existe alguma opção para o x11vnc mostrar quantos dados ele está manipulando e quanto tempo leva para capturar uma tela, processar e compactá-la e enviá-la pela rede?

linux mmm
fonte

Respostas:

11

Para responder minha própria pergunta:

Mudar da codificação restrita para a codificação hextile resolveu o problema com o redesenho lento completamente.

Para acrescentar alguns detalhes: notei que durante o redesenho lento da tela, a CPU no cliente estava aumentando com 100% de uso. Eu estava usando codificação restrita e, na página VNC Tight Encoder - Resultados da comparação , pode ser visto que a codificação restrita é bastante intensiva na CPU quando comparada à codificação hextile. Depois de mudar para o uso máximo da CPU hextile nunca é 100%, quase toda a largura de banda disponível é utilizada e o redesenho sempre leva menos de um segundo. Portanto, a CPU do cliente era o gargalo.

Ou uma alternativa ainda melhor (menos largura de banda, baixo uso da CPU e parece ainda mais rápido que o hextile) é compilar x11vnc com suporte ao TurboVNC e, em seguida, usar o cliente TurboVNC .

mmm
fonte
Aqui estão algumas de largura de banda e compressão comparações temporais tightvnc.com/archive/compare.html
huyz
1
Como exatamente você mudou a codificação?
ScottF
1

O motivo é que a captura de tela / renderizador é ineficiente. Muitas implementações diferentes de VNC brincam com isso para obter melhor desempenho.

Se você não precisa refletir exatamente o que está no console local, uma solução melhor é o NX ou o FreeNX da NoMachine como um ambiente de área de trabalho remota. O desempenho é dia e noite em comparação com o VNC, mesmo nos links WAN.

jfalcon tcp Don Fanning
fonte
1

Espero que isso funcione. http://www.karlrunge.com/x11vnc/faq.html#faq ... pesquise os parâmetros do visualizador VNC e os parâmetros x11vnc:

Funcionou para mim.

Kishor Pawar
fonte
1
Bem-vindo à falha do servidor! Nós realmente preferimos que as respostas tenham conteúdo, não ponteiros para o conteúdo. Teoricamente, isso pode responder à pergunta, no entanto, seria preferível incluir aqui as partes essenciais da resposta e fornecer o link para referência.
Chris S