* [Qemu-devel] [Bug 1725707] Re: QEMU sends excess VNC data to websockify even when network is poor
2017-10-21 14:29 [Qemu-devel] [Bug 1725707] [NEW] QEMU sends excess VNC data to websockify even when network is poor Carl Brassey
@ 2017-10-21 14:30 ` Carl Brassey
2017-10-21 14:30 ` Carl Brassey
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Carl Brassey @ 2017-10-21 14:30 UTC (permalink / raw)
To: qemu-devel
** Attachment added: "Used with QEMU.jpg"
https://bugs.launchpad.net/qemu/+bug/1725707/+attachment/4982276/+files/Used%20with%20QEMU.jpg
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1725707
Title:
QEMU sends excess VNC data to websockify even when network is poor
Status in QEMU:
New
Bug description:
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1725707/+subscriptions
^ permalink raw reply [flat|nested] 9+ messages in thread* [Qemu-devel] [Bug 1725707] Re: QEMU sends excess VNC data to websockify even when network is poor
2017-10-21 14:29 [Qemu-devel] [Bug 1725707] [NEW] QEMU sends excess VNC data to websockify even when network is poor Carl Brassey
2017-10-21 14:30 ` [Qemu-devel] [Bug 1725707] " Carl Brassey
@ 2017-10-21 14:30 ` Carl Brassey
2017-10-23 8:46 ` Daniel Berrange
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Carl Brassey @ 2017-10-21 14:30 UTC (permalink / raw)
To: qemu-devel
** Attachment added: "Used with other VNC servers.jpg"
https://bugs.launchpad.net/qemu/+bug/1725707/+attachment/4982277/+files/Used%20with%20other%20VNC%20servers.jpg
** Description changed:
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.
+ 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.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1725707
Title:
QEMU sends excess VNC data to websockify even when network is poor
Status in QEMU:
New
Bug description:
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1725707/+subscriptions
^ permalink raw reply [flat|nested] 9+ messages in thread* [Qemu-devel] [Bug 1725707] Re: QEMU sends excess VNC data to websockify even when network is poor
2017-10-21 14:29 [Qemu-devel] [Bug 1725707] [NEW] QEMU sends excess VNC data to websockify even when network is poor Carl Brassey
2017-10-21 14:30 ` [Qemu-devel] [Bug 1725707] " Carl Brassey
2017-10-21 14:30 ` Carl Brassey
@ 2017-10-23 8:46 ` Daniel Berrange
2017-10-23 12:14 ` Daniel Berrange
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Daniel Berrange @ 2017-10-23 8:46 UTC (permalink / raw)
To: qemu-devel
This is nothing specific to websockets AFAIK. Even using regular VNC
QEMU doesn't try to dynamically throttle data / quality settings.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1725707
Title:
QEMU sends excess VNC data to websockify even when network is poor
Status in QEMU:
New
Bug description:
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1725707/+subscriptions
^ permalink raw reply [flat|nested] 9+ messages in thread* [Qemu-devel] [Bug 1725707] Re: QEMU sends excess VNC data to websockify even when network is poor
2017-10-21 14:29 [Qemu-devel] [Bug 1725707] [NEW] QEMU sends excess VNC data to websockify even when network is poor Carl Brassey
` (2 preceding siblings ...)
2017-10-23 8:46 ` Daniel Berrange
@ 2017-10-23 12:14 ` Daniel Berrange
2018-01-22 1:28 ` jamiedo2nn
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Daniel Berrange @ 2017-10-23 12:14 UTC (permalink / raw)
To: qemu-devel
NB, if websockify crashes, then that is a serious flaw in websockify -
it shouldn't read an unbounded amount of data from QEMU, if it is unable
to send it onto the client. If websockify stopped reading data from
QEMU, then QEMU would in turn stop sending it once the TCP buffer was
full
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1725707
Title:
QEMU sends excess VNC data to websockify even when network is poor
Status in QEMU:
New
Bug description:
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1725707/+subscriptions
^ permalink raw reply [flat|nested] 9+ messages in thread* [Qemu-devel] [Bug 1725707] Re: QEMU sends excess VNC data to websockify even when network is poor
2017-10-21 14:29 [Qemu-devel] [Bug 1725707] [NEW] QEMU sends excess VNC data to websockify even when network is poor Carl Brassey
` (3 preceding siblings ...)
2017-10-23 12:14 ` Daniel Berrange
@ 2018-01-22 1:28 ` jamiedo2nn
2020-11-10 3:06 ` Thomas Huth
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jamiedo2nn @ 2018-01-22 1:28 UTC (permalink / raw)
To: qemu-devel
Reference:
https://github.com/novnc/noVNC/issues/431#issuecomment-71883085
QEMU uses many more (30x) operations with much smaller amounts of data
than other VNC server, perhaps this leads to the different result.
** Bug watch added: github.com/novnc/noVNC/issues #431
https://github.com/novnc/noVNC/issues/431
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1725707
Title:
QEMU sends excess VNC data to websockify even when network is poor
Status in QEMU:
New
Bug description:
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1725707/+subscriptions
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug 1725707] Re: QEMU sends excess VNC data to websockify even when network is poor
2017-10-21 14:29 [Qemu-devel] [Bug 1725707] [NEW] QEMU sends excess VNC data to websockify even when network is poor Carl Brassey
` (4 preceding siblings ...)
2018-01-22 1:28 ` jamiedo2nn
@ 2020-11-10 3:06 ` Thomas Huth
2021-04-22 17:33 ` Thomas Huth
2021-04-23 4:17 ` Launchpad Bug Tracker
7 siblings, 0 replies; 9+ messages in thread
From: Thomas Huth @ 2020-11-10 3:06 UTC (permalink / raw)
To: qemu-devel
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1725707
Title:
QEMU sends excess VNC data to websockify even when network is poor
Status in QEMU:
Incomplete
Bug description:
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1725707/+subscriptions
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug 1725707] Re: QEMU sends excess VNC data to websockify even when network is poor
2017-10-21 14:29 [Qemu-devel] [Bug 1725707] [NEW] QEMU sends excess VNC data to websockify even when network is poor Carl Brassey
` (5 preceding siblings ...)
2020-11-10 3:06 ` Thomas Huth
@ 2021-04-22 17:33 ` Thomas Huth
2021-04-23 4:17 ` Launchpad Bug Tracker
7 siblings, 0 replies; 9+ messages in thread
From: Thomas Huth @ 2021-04-22 17:33 UTC (permalink / raw)
To: qemu-devel
** Bug watch removed: github.com/novnc/noVNC/issues #431
https://github.com/novnc/noVNC/issues/431
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1725707
Title:
QEMU sends excess VNC data to websockify even when network is poor
Status in QEMU:
Incomplete
Bug description:
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1725707/+subscriptions
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug 1725707] Re: QEMU sends excess VNC data to websockify even when network is poor
2017-10-21 14:29 [Qemu-devel] [Bug 1725707] [NEW] QEMU sends excess VNC data to websockify even when network is poor Carl Brassey
` (6 preceding siblings ...)
2021-04-22 17:33 ` Thomas Huth
@ 2021-04-23 4:17 ` Launchpad Bug Tracker
7 siblings, 0 replies; 9+ messages in thread
From: Launchpad Bug Tracker @ 2021-04-23 4:17 UTC (permalink / raw)
To: qemu-devel
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1725707
Title:
QEMU sends excess VNC data to websockify even when network is poor
Status in QEMU:
Expired
Bug description:
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1725707/+subscriptions
^ permalink raw reply [flat|nested] 9+ messages in thread
