[Spice-devel] Spice protocol performance

[Jure Erznožnik]

Hello (very fearfully, because I found no list that could be helpful and 
this one seems to be for developers...),

I have been trying for a long while now to get my VM machines to perform 
well, but I can't seem to get it right. I seem to be suffering from two 
issues:

 1. remote-viewer / libvirt host uses inefficient codecs to transfer
    audio / video
 2. virtual machines themselves don't seem to have their graphics
    accelerated sufficiently

I proceed to elaborate on both:

*#1 - inefficient codecs*

So I have a number of VMs running under qemu on Ubuntu 18.04. AMD 2700x 
+ nvidia 1060 gtx (driver nvidia). qemu 4.2, libvirt 6.0.0. Everything 
works fine except accessing the VMs remotely: the slower the connection, 
the worse it gets. Running them on 4K monitor - please note the 
resolution. Using remmina or virt-viewer, makes no difference.

  * on local machine, everything is next to perfect, the only noticeable
    quality degradation is video full-screen.
  * 1gbit LAN: noticeable delays rendering stuff, video becomes grainy
    even when in a small window
  * 100 mbit LAN / internet: a full screen refresh can take several seconds
  * 20/4 mbit internet: when a full screen refresh is needed, I can
    observe the 64x64 squares being rendered across the screen and it
    takes multiple seconds. Scrolling an editor window is an operation
    that takes patience. Connection useless but for the most urgent
    tasks where patience is not an issue. Even X over ssh seems the
    better option here.

I compare this to Win10 RDP, which - over the same 20/4 connection - 
behaves as if I were at the machine in question, even for full-screen video.

The VMs are all setup thus:

  * Display spice: Spice server with everything on default, no OpenGL
  * Video VirtIO: model VirtIO, 3D acceleration: yes, heads:2, RAM 128MB

I tried video: QXL, but that one completely hogged my LAN, even at gbit, 
delivering little for the bandwidth taken (it was less performant than 
VirtIO). Same for running everything on local machine too. It seems it 
just continuously grabs frames and transmits them regardless of whether 
there's any action or not.

Driver in use for guests is virtio-pci for manjaro (video frames 
undistorted, but frames lost depending on bandwidth), qxl for ubuntu 
(video frames are chopped up, presumably by algorithm snapping them 
partially before transmission). QXL despite the fact that video for the 
vm in question is set to VirtIO. May also be a result of my tinkering 
but useful for comparison anyway.

I have searched all 'round the place and I did find this thread 
<https://spice-devel.freedesktop.narkive.com/m7FY7Dvb/spice-v12-00-26-add-gstreamer-support-for-video-streaming>. 
It seems to have been merged, but there are no instructions on how to 
modify VM configuration to use H264 instead of MJPEG for video encoding.

*#2 - inadequate graphics acceleration*

Well, I mostly base this one on observed CPU usage. I have noticed on 
all my linux guests (Manjaro, Ubuntu) that even moving a window around 
the desktop significantly raises CPU usage in the guest. I would venture 
to guess one core gets taken by such an endeavor. Playing a video in 
browser full screen would take closer to two cores.

It is not much different for Windows guests: running a video or a skype 
video session absolutely hogs the CPU. While skype itself takes little 
CPU, the overall CPU usage goes toward 80 - 100% on a 6 core VM. The 
actual process consuming that CPU is not shown in details pane. Using 
Red Hat QXL controller for display adapter on Win10 64-bit.

I have found no solution to this problem.


After a very long time and continuing frustration with the problem, I 
turn to you guys in hope of a suggestion on what I'm doing wrong. Just 
as gladly I would hear of a setup that is known to perform well, I have 
no particular need to resolve my exact issues. Reinstalling the host and 
/ or guests is not a problem if a known good configuration will perform 
for me too...

Thanks,
Jure

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20200812/c902199e/attachment.htm>