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％的可用带宽所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。