Linux   发布时间:2022-04-01  发布网站:大佬教程  code.js-code.com
大佬教程收集整理的这篇文章主要介绍了linux-x11vnc很慢,但只使用10%的可用带宽大佬教程大佬觉得挺不错的,现在分享给大家,也给大家做个参考。

概述

我在15Mbit / s网络上使用X11vnc,延迟为20ms.当屏幕变化很多时,x11vnc很慢 – 例如当我在浏览器中切换选项卡时,几乎需要两秒钟才能完全重绘视图. 奇怪的是,x11vnc的最大连接速度在缓慢重绘时仅为可用带宽的10%左右.为什么x11vnc没有使用可用带宽来加速重绘?例如,scp正在使用100%的可用带宽而没有问题. 如何确定系统中x11vnc的瓶颈是什么?到目前为止,我认为
我在15Mbit / s网络上使用X11vnc,延迟为20ms.当屏幕变化很多时,x11vnc很慢 – 例如当我在浏览器中切换选项卡时,几乎需要两秒钟才能完全重绘视图.

奇怪的是,x11vnc的最大连接速度在缓慢重绘时仅为可用带宽的10%左右.为什么x11vnc没有使用可用带宽来加速重绘?例如,scp正在使用100%的可用带宽而没有问题.

如何确定系统中x11vnc的瓶颈是什么?到目前为止,我认为:

> 10%的网络使用率=>网络不是瓶颈
> fb读取速率:601 MB /秒=>读fb不是瓶颈

任何想法如何进一步分析x11vnc并找出导致减速的原因?

例如,是否有任何x11vnc开关显示它处理的数据量以及获取屏幕,处理和压缩屏幕并通过网络发送它需要多长时间?

解决方法

回答我自己的问题:

从紧密编码切换到六边形编码解决了完全缓慢重绘的问题.

添加一些细节:我注意到在缓慢重绘屏幕期间,客户端上的cpu达到了100%的使用率.我使用的是紧密编码,从页面VNC Tight Encoder – Comparison Results可以看出,与hextile编码相比,紧密编码非常密集.切换到hextile max cpu后,使用率绝不是100%,几乎可以利用整个可用带宽,重绘总是不到一秒钟.所以客户端的cpu是瓶颈.

或者甚至更好的替代方案(更少的带宽,更低的cpu使用率,似乎甚至比六角形更快)到compile x11vnc with TurboVNC support然后使用TurboVNC client.

大佬总结

以上是大佬教程为你收集整理的linux-x11vnc很慢,但只使用10%的可用带宽全部内容,希望文章能够帮你解决linux-x11vnc很慢,但只使用10%的可用带宽所遇到的程序开发问题。

如果觉得大佬教程网站内容还不错,欢迎将大佬教程推荐给程序员好友。

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。