x11vnc는 느리지 만 사용 가능한 대역폭의 10 % 만 사용

대기 시간이 20ms 인 15Mbit / s 네트워크에서 x11vnc를 사용하고 있습니다. 화면이 많이 바뀌면 x11vnc가 느려집니다 (예 : 브라우저에서 탭을 전환 할 때보 기가 완전히 다시 그려 질 때까지 거의 2 초가 걸립니다.

이상한 점은 x11vnc의 최대 연결 속도가 느린 다시 그리기 중에도 사용 가능한 대역폭의 약 10 %에 불과하다는 것입니다. x11vnc가 다시 그리기 속도를 높이기 위해 사용 가능한 대역폭을 사용하지 않는 이유는 무엇입니까? 예를 들어 scp는 사용 가능한 대역폭의 100 %를 문제없이 사용하고 있습니다.

시스템에서 x11vnc의 병목 현상을 식별하려면 어떻게해야합니까? 지금까지 나는 생각합니다 :

1. 10 % 네트워크 사용량 => 네트워크가 병목 현상이 아닙니다
2. fb 읽기 속도 : 601 MB / sec => fb 읽기는 병목 현상이 아닙니다

x11vnc를 더 프로파일 링하고 속도 저하를 일으키는 원인을 어떻게 알 수 있습니까?

예를 들어 x11vnc가 처리하는 데이터 양과 화면을 잡고 처리하고 압축하여 네트워크를 통해 전송하는 데 걸리는 시간을 보여주는 스위치가 있습니까?

내 질문에 대답하려면 :

타이트 인코딩에서 16 진 인코딩으로 전환하면 느린 다시 그리기 문제가 완전히 해결되었습니다.

세부 사항을 추가하려면 : 화면을 천천히 다시 그리는 동안 클라이언트의 CPU가 100 % 사용량으로 급상승하는 것으로 나타났습니다. 나는 엄격한 인코딩을 사용하고 있었고 VNC Tight Encoder- 비교 결과 페이지 에서 16 진수 인코딩과 비교할 때 단단한 인코딩이 CPU를 많이 사용한다는 것을 알 수 있습니다. 16 진수 최대 CPU 사용량으로 전환 한 후 100 %가되지 않으면 거의 모든 가용 대역폭이 사용되며 다시 그리는 데는 1 초도 걸리지 않습니다. 따라서 클라이언트의 CPU는 병목 현상이었습니다.

또는 더 나은 대안 (대역폭이 적고 CPU 사용량이 적고 16 진수보다 빠릅니다)은 TurboVNC 지원으로 x11vnc 를 컴파일 한 다음 TurboVNC 클라이언트 를 사용하는 것 입니다.

화면 캡처 / 렌더러가 비효율적이기 때문입니다. 많은 다른 VNC 구현은 더 나은 성능을 달성하기 위해이 함께 놀러.

로컬 콘솔에있는 것을 정확하게 반영 할 필요가없는 경우 더 나은 솔루션은 원격 데스크톱 환경으로서 NoMachine의 NX 또는 FreeNX 입니다. WAN 링크를 통해서도 VNC와 비교하여 낮과 밤의 성능이 보장됩니다.

이것이 효과가 있기를 바랍니다. http://www.karlrunge.com/x11vnc/faq.html#faq ... VNC 뷰어 매개 변수 및 x11vnc 매개 변수를 검색 하십시오 .

그것은 나를 위해 일했다.