diff options
Diffstat (limited to 'results/classifier/deepseek-2-tmp/output/manual-review/1725707')
| -rw-r--r-- | results/classifier/deepseek-2-tmp/output/manual-review/1725707 | 62 |
1 files changed, 0 insertions, 62 deletions
diff --git a/results/classifier/deepseek-2-tmp/output/manual-review/1725707 b/results/classifier/deepseek-2-tmp/output/manual-review/1725707 deleted file mode 100644 index 07a22f4e..00000000 --- a/results/classifier/deepseek-2-tmp/output/manual-review/1725707 +++ /dev/null @@ -1,62 +0,0 @@ - -QEMU sends excess VNC data to websockify even when network is poor - -Description of problem -------------------------- -In my latest topic, I reported a bug relate to QEMU's websocket: -https://bugs.launchpad.net/qemu/+bug/1718964 - -It has been fixed but someone mentioned that he met the same problem when using QEMU with a standalone websocket proxy. -That makes me confused because in that scenario QEMU will get a "RAW" VNC connection. -So I did a test and found that there indeed existed some problems. The problem is: - -When the client's network is poor (on a low speed WAN), QEMU still sends a lot of data to the websocket proxy, then the client get stuck. It seems that only QEMU has this problem, other VNC servers works fine. - -Environment -------------------------- -All of the following versions have been tested: - -QEMU: 2.8.1.1 / 2.9.1 / 2.10.1 / master (Up to date) -Host OS: Ubuntu 16.04 Server LTS / CentOS 7 x86_64_1611 -Websocket Proxy: websockify 0.6.0 / 0.7.0 / 0.8.0 / master -VNC Web Client: noVNC 0.5.1 / 0.61 / 0.62 / master -Other VNC Servers: TigerVNC 1.8 / x11vnc 0.9.13 / TightVNC 2.8.8 - -Steps to reproduce: -------------------------- -100% reproducible. - -1. Launch a QEMU instance (No need websocket option): -qemu-system-x86_64 -enable-kvm -m 6G ./win_x64.qcow2 -vnc :0 - -2. Launch websockify on a separate host and connect to QEMU's VNC port - -3. Open VNC Web Client (noVNC/vnc.html) in browser and connect to websockify - -4. Play a video (e.g. Watch YouTube) on VM (To produce a lot of frame buffer update) - -5. Limit (e.g. Use NetLimiter) the client inbound bandwidth to 300KB/S (To simulate a low speed WAN) - -6. Then client's output gets stuck(less than 1 fps), the cursor is almost impossible to move - -7. Monitor network traffic on the proxy server - -Current result: -------------------------- -Monitor Downlink/Uplink network traffic on the proxy server -(Refer to the attachments for more details). - -1. Used with QEMU -- D: 5.9 MB/s U: 5.7 MB/s (Client on LAN) -- D: 4.3 MB/s U: 334 KB/s (Client on WAN) - -2. Used with other VNC servers -- D: 5.9 MB/s U: 5.6 MB/s (Client on LAN) -- D: 369 KB/s U: 328 KB/s (Client on WAN) - -It is found that when the client's network is poor, all the VNC servers (tigervnc/x11vnc/tightvnc) -will reduce the VNC data send to websocket proxy (uplink and downlink symmetry), but QEMU never drop any frames and still sends a lot of data to websockify, the client has no capacity to accept so much data, more and more data are accumulated in the websockify, then it crashes. - -Expected results: -------------------------- -When the client's network is poor (WAN), QEMU will reduce the VNC data send to websocket proxy. \ No newline at end of file |