RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1158029 - [RFE] Spice: Improve performance over high latency WAN links
Summary: [RFE] Spice: Improve performance over high latency WAN links
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: spice
Version: 7.4
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: 7.4
Assignee: Frediano Ziglio
QA Contact: SPICE QE bug list
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-28 11:17 UTC by Evgheni Dereveanchin
Modified: 2021-12-10 14:26 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-05-24 10:59:57 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Evgheni Dereveanchin 2014-10-28 11:17:11 UTC 
Description of problem:
SPICE is operating poorly when used over high-latency WAN/VPN links - mouse cursor is lagging, as well as text input. 

Version-Release number of selected component (if applicable):
virt-viewer 0.6.0
rhev 3.4

How reproducible:
Always

Steps to Reproduce:
1. set up RHEV with a separate display network (to isolate the problem)
2. simulate a high-latency WAN link on the Display Network (change eth0 to device name used for the display network):
# tc qdisc add dev eth0 root netem delay 200ms 10ms 25% loss 0.5% 5% corrupt 0.1%  reorder 1% 2%

This creates ~200ms delay, up to 5% loss, 0.1% corruption and 2% reordering of all outgoing packets. The shaper does not affect network throughput.

3. initiate a SPICE session to a VM running on this host

Actual results:
Slow response from all interfaces of the VM, mouse lagging, text input into an editor delayed, screen redraw time more than 2 seconds for 1024*768 displays (open black window over white desktop, etc).

Expected results:
Interface not affected by latency and remains usable

Additional info:

It is understandable that 200 ms delay is very high, however RDP protocol seems to handle it much better. At least a local cursor is drawn instead of the remote one which massively improves user experience and removes perceived lag.
Comment 1 Evgheni Dereveanchin 2014-10-29 07:30:12 UTC 
I want to add that the shaper (reproducer step 2) can be applied on client side as well, so no changes to RHEV side are required to test this.
Comment 9 Frediano Ziglio 2016-12-02 15:31:59 UTC 
Got some investigations.
I instrumented spice-server adding message counter.
I tested with a connection having 100ms latency and 20Mbit.
As expected the number of commands per second is much higher than Windows (70 versus 200 of RHEL7).
I applied the network improvements patches I sent 18 months ago and got clear improvements, the commands goes up to 500 (a bit less) doing continued scrolling and responsiveness is better.
The reason of so much commands compared to Windows is that on RHEL7 Mesa implementation split images in chunks of 64K pixels (more or less). This increase the number of needed commands. Also this make video detection and streaming in general much worse basically causing spice-server code to create multiple streams.
Beside the network optimizations possible I think would be worth collapsing (so doing the reverse of what Mesa is doing) so to have bigger images and less commands.
Comment 10 Frediano Ziglio 2016-12-05 12:22:42 UTC 
Got a couple of promising patches specifically for RHEL7.
Trying to get also some better statistics.
Comment 11 Marc-Andre Lureau 2016-12-06 14:46:47 UTC 
worth pointing out the upstream series to improve mesa (also reducing memcpy and traffic in guest): drisw/glx: use XShm if possible
Comment 12 Frediano Ziglio 2017-05-24 10:59:57 UTC 
Current status:
- mesa patch does not fix the issue (https://bugzilla.redhat.com/show_bug.cgi?id=1030024#c19);
- my workaround patch which is working and tested are rejected for 7.4;
- for 7.5 we are going to support Virgl instead of Qxl so the problem will disappear.
Note You need to log in before you can comment on or make changes to this bug.