[Spice-devel] spice performance tweaking

Thu Sep 29 13:04:45 UTC 2016

Hi,

I'm not using TLS to connect the spice session, so unless there is another
encryption that I'm not aware of, it's already off
And I already tried switching of lzo compression, but if there was an
improvement I couldn't see it.

I'm not sure where the microsoft windows display driver entered the
discussion,
whenever I said window I was referring to one of the square boxes on my
linux desktop that contains the application that I'm lookinf at
(firefox/terminal/chrome).

Rob Verduijn

2016-09-29 13:21 GMT+02:00 Frediano Ziglio <fziglio at redhat.com>:

>
> Hi,
>
> I tried a virtual rhel7.3beta (server with gui) on a rhel7.3beta host.
>
> The host was a laptop to which I setup to use my old wifi router that only
> has 54Mbit so the bandwith was poor and unstable.
>
> Without the compression options the spice display was really bad.
> You could see the screen being rendered bit by bit.
>
> I tried this with the custom rpm and did not really see an improvement.
>
> I downgraded the spice-server and rebooted
>
> I added the compression options:
>       <image compression='glz'/>
>       <jpeg compression='always'/>
>       <zlib compression='always'/>
>       <streaming mode='all'/>
>
> Now the spice display was very usable and almost no artifacts.
>
> Only when moving the windows you can see tearing at the edges.
> Also started a glxgears window to see how it deals with that
>
> I applied the custom rpm and rebooted the host.
>
> After restarting the vm and logging into spice
> There is less tearing when moving the window.
>
>
> Good! Thanks for the test! I'll work to make these changes integrated in a
> future version.
>
>
>
> So there is an improvement, but it's hard to tell how much  by simply
> watching when draging the window.
>
>
> some details from our openvpn config
> the protocol has to be tcp.....
>
> centos 7.2 openvpn server settings:
>
> port secret-port-number
> proto tcp
> dev tun
> tun-mtu 1500
> ca /path/to/ca
> cert /path/to/cert
> key /path/to/key
> dh /path/to/dh
> server some.ip.address some.subnet.mask
> ifconfig-pool-persist ipp.txt
> keepalive 10 120
> comp-lzo
> user nobody
> group nobody
> persist-key
> persist-tun
> status /path/to/log
> verb 3
> mute 20
>
> I would personally try different combination of compression/encryption.
> Obviously you want encryption on the VPN but if you have also encryption
> on Spice this
> is mainly wasting bandwidth and latency.
> Also depending on the type of data VPN compression can be a bad idea.
> I would try (if this is possible) to turn it off.
>
> On the Windows side I tried to see what could cause the flicker issue.
> It seems for some reason (unknown to me) some commands are trying to read
> some data back
> from the card causing a 0.01 seconds delay (which could be one cause of
> the delay). No much
> to suggest to improve this. Looks like the XPDM driver can be compiled
> using different way
> to do the synchronization and looks like the new WDDM driver does the
> synchronization in
> a different way (not clear why).
> I don't think I'll have much more time to investigate into this.
> I would suggest to open a ticket upstream so people don't forget this.
>
> Frediano
>
> fedora 24 NetworkManager settings:
> [connection]
> id=our id for our top secret vpn
> uuid=xxxxxxxx.xxxx.xxx.xxx.xx
> type=vpn
> permissions=user:secretusernottellingyou:;
> secondaries=
>
> [vpn]
> remote-random=no
> connection-type=tls
> remote=remote.ip.address
> tunnel-mtu=1500
> comp-lzo=yes
> cert-pass-flags=1
> proto-tcp=yes
> port=<secret-port>
> mssfix=yes
> dev-type=tun
> ca=/path/to/ca
> key=/path/to/key
> cert=/path/to/crt
> service-type=org.freedesktop.NetworkManager.openvpn
>
> [ipv4]
> dns-search=
> ignore-auto-routes=true
> method=auto
> never-default=true
>
>
> route1=additional.route/mask
>
>
> route2=additional.route/mask
>
>
>
> [ipv6]
>
>
> addr-gen-mode=stable-privacy
>
>
> dns-search=
>
>
> method=auto
>
>
>
> Cheers
> Rob Verduijn.
>
>
>
>
> 2016-09-15 16:04 GMT+02:00 Rob Verduijn <rob.verduijn at gmail.com>:
>
>> Hello,
>>
>> The performance fixes sound awesome.
>> I'm afraid I cannot test them in the environment with the low bandwith
>> setup soon (maybe next week, but don't hold your breath)
>> I'm going to build a local test setup to see if this is improving some of
>> the issues. I got a laptop running the rhel7.3 beta, let's see how that
>> performs.
>>
>> Rob Verduijn
>>
>>
>> 2016-09-15 13:31 GMT+02:00 Frediano Ziglio <fziglio at redhat.com>:
>>
>>> I saw you are using CentOS 7. I built the package with RHEL 7 (they are
>>> binary compatible).
>>> About the testing just which normal usage you should see improvements in
>>> bandwidth and
>>> reactivity.
>>>
>>> Changes from current CentOS package:
>>> - used a newer version, there are couple of changes that decrease
>>> latency;
>>> - additional patches to improve bandwidth usage (for small drawing this
>>> should decrease
>>>   bandwidth usage by a 15-20%);
>>> - additional patch to decrease a bandwidth limitation due to a peculiar
>>> half-duplex usage
>>>   of spice protocol (this is clearly visible with high latency
>>> connections);
>>> - additional patch to decrease packet fragmentation due to TCP_NODELAY
>>> usage.
>>>
>>> Alternatively would be helpful for us to get a local reproduction of the
>>> problem.
>>> OpenVPN configuration files would be helpful (we don't need any security
>>> detail like keys, ip, host or system names, just to understand the type
>>> of VPN,
>>> encryption parameters, compression, additional latency introduced and so
>>> on).
>>>
>>> The fact that you are not able to get a record from the guest means that
>>> the QXL
>>> (guest <-> server) protocol how the spice-server is handling guest
>>> command is
>>> fine. The fact that on the client you can see clearly such slowness is
>>> due to spice
>>> protocol, the connection/vpn, some spice-server implementation and
>>> possibly
>>> client implementation too. Unfortunately too much stuff to be able to
>>> point the
>>> finger to one of them.
>>> I tried some test and did this:
>>> - opened task manager on Windows 7;
>>> - switched to performance tab;
>>> - maximized task manager;
>>> - double clicked on CPU usage to get only CPU usage and history.
>>> When CPU usage change I can see the flickering on CPU usage but not on
>>> the history graphs. It this the kind of flickering you are noticing?
>>>
>>> Frediano
>>>
>>>
>>> For which distro is that package ?
>>> Centos 7.2 ? rhel7.3beta or fedora24 ?
>>>
>>> Rob Verduijn
>>>
>>> 2016-09-14 15:59 GMT+02:00 Frediano Ziglio <fziglio at redhat.com>:
>>>
>>>> Could you test at least? Would be very helpful. We could then backport
>>>> some improvements.
>>>>
>>>> Frediano
>>>>
>>>>
>>>> thanx,I'll stick with the centos packages,
>>>>
>>>> I need a very good reason before I start using beta packages.
>>>> And a nice to have feature is not one of them.
>>>>
>>>> Also I dug in to the openvpn tweaks and it seems that all of them are
>>>> related to udp tunnels.
>>>> Performance is sadly rather low when you have to use tcp (like me)
>>>> because the firewall is managed by a third party.
>>>>
>>>> Rob Verduijn
>>>>
>>>> 2016-09-14 15:49 GMT+02:00 Frediano Ziglio <fziglio at redhat.com>:
>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>> I'm trying to improve my spice performance on a kvm host/guest.
>>>>> It's currently rather slow and I can see screens beeing build up, and
>>>>> delays when draging windows.
>>>>>
>>>>> It's being tunneled through openvpn, which is set to use tcp.
>>>>> tcp required because of the firewall which is maintained by 3rd party.
>>>>>
>>>>> I have full access to the kvm host, kvm guest and openvpn server.
>>>>>
>>>>> Have you got any tips so that I can improve spice performance ?
>>>>> I alrready am running tuned with the virtual-guest profile for  guests
>>>>> and host profile for the host.
>>>>> All systems are runnning CentOS 7
>>>>>
>>>>> Any tips for :
>>>>> - the KVM host ?
>>>>> - the KVM guest ?
>>>>> - the openvpn server ?
>>>>>
>>>>> Cheers
>>>>> Rob Verduijn
>>>>>
>>>>> Hi,
>>>>>   can you try version at https://www.datafilehost.com/d/b07f008e ?
>>>>>
>>>>> The sha1 hash (please check it) is 0e2191c363e109475aeb2bff401e69
>>>>> 9f0a07a795.
>>>>>
>>>>> Be prepare for the rollback, it's not a version meant for production
>>>>> usage.
>>>>>
>>>>> Frediano
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20160929/7316bba0/attachment-0001.html>