[Spice-devel] troubleshooting performance and latency issues?

[Frediano Ziglio]

> >>>>
> >>>>
> >>>>
> >>>> Hi,
> >>>>
> >>>> I've observed some latency issues, for example, changing focus from one
> >>>> terminal to another is a bit sluggish.  Typing isn't too bad.
> >>>> Interaction with the sliding GNOME unlock screen and drawing the desktop
> >>>> after unlock is painfully slow.
> >>>>
> >>>
> >>> Looks like your problems are due to a low bandwidth instead of high
> >>> latency. Does spice detect a low bandwidth (should be written in the
> >>> logs)
> >>> ?
> >>>
> >>
> >> Can you suggest which log file to check, or journalctl and a possible
> >> grep command?
> >>
> > 
> > They are in /var/log/libvirt/qemu (at least on my machines).
> > Should not be big to require a grep, unless you enable additional
> > logs.
> > 
> 
> Thanks, here is what I found:
> 
> grep latency /var/log/libvirt/qemu/${VM}.log | cut -f3 -d:
>  latency 6.442000 ms, bitrate 15242858 bps (14.536722 Mbps)
>  latency 4.716000 ms, bitrate 18609384 bps (17.747292 Mbps)
>  latency 7.116000 ms, bitrate 15983891 bps (15.243426 Mbps)
>  latency 12.324000 ms, bitrate 15829951 bps (15.096618 Mbps)
>  latency 7.526000 ms, bitrate 19341556 bps (18.445545 Mbps)
>  latency 3.726000 ms, bitrate 16404604 bps (15.644650 Mbps)
>  latency 6.999000 ms, bitrate 20247558 bps (19.309576 Mbps)
>  latency 9.373000 ms, bitrate 22070154 bps (21.047739 Mbps)
>  latency 3.819000 ms, bitrate 19262965 bps (18.370595 Mbps)
>  latency 5.808000 ms, bitrate 16567434 bps (15.799936 Mbps)
>  latency 53.710000 ms, bitrate 4911212 bps (4.683697 Mbps) LOW BANDWIDTH
>  latency 100.954000 ms, bitrate 821117 bps (0.783078 Mbps) LOW BANDWIDTH
>  latency 41.180000 ms, bitrate 593653 bps (0.566152 Mbps) LOW BANDWIDTH
>  latency 6.116000 ms, bitrate 15928322 bps (15.190432 Mbps)
>  latency 7.282000 ms, bitrate 13945728 bps (13.299683 Mbps)
>  latency 8.717000 ms, bitrate 6145905 bps (5.861192 Mbps) LOW BANDWIDTH
>  latency 6.423000 ms, bitrate 14845097 bps (14.157388 Mbps)
>  latency 2.085000 ms, bitrate 5363208 bps (5.114754 Mbps) LOW BANDWIDTH
>  latency 5.981000 ms, bitrate 3645399 bps (3.476523 Mbps) LOW BANDWIDTH
>  latency 13.411000 ms, bitrate 17843917 bps (17.017285 Mbps)
>  latency 6.944000 ms, bitrate 11591709 bps (11.054715 Mbps)
>  latency 8.826000 ms, bitrate 16924500 bps (16.140461 Mbps)
>  latency 13.359000 ms, bitrate 18063947 bps (17.227122 Mbps)
>  latency 1.068000 ms, bitrate 20059355 bps (19.130092 Mbps)
>  latency 5.237000 ms, bitrate 6574913 bps (6.270326 Mbps) LOW BANDWIDTH
>  latency 1.022000 ms, bitrate 6562924 bps (6.258892 Mbps) LOW BANDWIDTH
>  latency 1.916000 ms, bitrate 19701969 bps (18.789262 Mbps)
>  latency 1.029000 ms, bitrate 17367559 bps (16.562995 Mbps)
> 

Well... this confirm my theory of just a low bandwidth :-)
Looks like your connection goes up and down. Are you using WiFi ?

> >>
> >>>> The virtual server I connect to runs Debian jessie and GNOME 3 desktop,
> >>>> it is a default install:
> >>>> Xorg = 2:1.16.4-1
> >>>> xserver-xorg-video-qxl = 0.1.1-2+b1
> >>>> spice-vdagent = 0.15.0-1.2
> >>>>
> >>>> I'm monitoring the latency of the connection to the KVM/libvirt/SPICE
> >>>> server with Smokeping, average ping time is about 0.8ms, no packet loss.
> >>>>
> >>>
> >>> With such network latency you should not have much network latency
> >>> issues, unless ssh (which seems you are using add a lot of it) add this
> >>> issue.
> >>>
> >>>>
> >>>> I've setup the KVM/libvirt/SPICE host like this:
> >>>> Debian stretch
> >>>> Kernel = 4.9.13
> >>>> libspice-server1 = 0.12.8-2.1
> >>>> libvirt0 = 3.0.0-3
> >>>>
> >>>>
> >>>> I've tried using both virt-manager and virt-viewer as clients on a
> >>>> Debian jessie system, connecting over SSH to the KVM host, these are the
> >>>> client versions:
> >>>>
> >>>> virt-manager = 1:1.0.1-5
> >>>> virt-viewer = 1.0-1
> >>>>
> >>>
> >>> Can you try without SSH?
> >>>
> >>
> >> OK, I tried this:
> >>
> >>   virsh edit <domain>   and changed the listen IP to 0.0.0.0
> >>
> >> Then I used spicy to connect directly to the port as I wasn't sure how
> >> to tell virt-manager or virt-viewer to connect directly to the SPICE port.
> >>
> >> I found some things are a bit faster but it is still not ideal
> >>
> >> In particular, rendering the gray background of the GNOME unlock screen
> >> appears very slow, it renders one line at a time from top to bottom, it
> >> takes several seconds.  Rendering the desktop background image (default
> >> Debian theme) was also slow.  I understand that I could change the
> >> background image, but the gray lock screen, being a single colour,
> >> shouldn't that render more quickly?
> >>
> > 
> > weird, looks like is not compressing at all!
> > With remote-viewer you can add options like
> > --spice-preferred-compression=glz
> > (see "remote-viewer --help-spice" command), you should be able to connect
> > with "remote-viewer spice://<ip>:<port>" (not using ssh).
> > 
> 
> OK, using remote-viewer and not using SSH it now appears a lot faster
> rendering the unlock screen and the desktop.
> 

>From a quick research looks like even virt-viewer support same
compression option of remote-viewer and also supports ssh (not clear
if supported by remote-viewer too).

> This runs over a WAN connection so most ports, including SPICE, are
> firewalled by default, I only tested it briefly with that port open.  Is
> it considered safe to allow access to that port?
> 

Absolutely not! Unless you configure SSL on top and disable not
encrypted connections (not sure how).

> I would normally consider running something like that over IPsec so that
> only trusted hosts can connect, should that have less overhead than
> running it over SSH or is there another way to go about it?
> 

I would stick to default SSH or setup properly SSL but is just personal
opinions. All 3 solutions (SSH, SSL or IPsec) had an encryption layer.

> Regards,
> 
> Daniel
> 

I'm sure somebody more expert on client and server configurations
will feel my gaps.

Frediano