Bug 827381

Hi,

What resolution is the vm configured to run at, and what is the native resolution of the client? Note that
spicec will change the clients monitor resolution to change the vm's when going fullscreen, where as
remote-viewer will use scaling instead, so if the resolutions mismatch, try changing the client resolution
using "xrandr" to the one of the vm before starting remote-viewer to get rid of the scaling.

Also can you try the following:

1) Same Fedora-17 client config on a more powerful machine
2) RHEL-6.3 beta + included remote-viewer under the AMD E-350 machine in question 
3) RHEL-6.3 beta + included spicec under the AMD E-350 machine in question 

The reason I'm asking is:
1) See if this is a problem with remote-viewer demanding more from the CPU / GPU, or else where
2) See if the GPU drivers in RHEL-6 perform better on an E-350 then those in Fedora-17
3) See if there has not been a regression in E-350 GPU driver performance between the RHEL-6 you've been testing with and 6.3 beta.

Thanks & Regards,

Hans

(In reply to comment #1)
> Hi,
> 
> What resolution is the vm configured to run at, and what is the native
> resolution of the client? Note that
> spicec will change the clients monitor resolution to change the vm's when
> going fullscreen, where as
> remote-viewer will use scaling instead, so if the resolutions mismatch, try
> changing the client resolution
> using "xrandr" to the one of the vm before starting remote-viewer to get rid
> of the scaling.

resolution is set to native resolution of screen (1920x1080 or 1680x1050) For F17 the spice-vdagentd does set this correct. On rhel6.3-beta it must be done by hand.

I did try both rhel6.3-beta and F17 with a default install (including updates)
connected to a virtual F17 on rhev6.2 (with a 6.3 qemu-kvm and spice* for usb-redirection)

rhel63-beta does work perfect (youtube gives same performance on VDI as native)
F17 is very bad (VDI gives a slideshow with stuttering sound. Native on F17 works perfect)

I am going to try remote-viewer on rhel63-beta. Is there way to change the firefox-xpi to remoteviewer in stead of spicec?

(In reply to comment #2)
>
> I am going to try remote-viewer on rhel63-beta. Is there way to change the
> firefox-xpi to remoteviewer in stead of spicec?

That should be the default in RHEL-6.3.

#cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.3 Beta (Santiago)

#rpm -qa | grep spice
spice-glib-0.11-7.el6.x86_64
spice-xpi-2.7-17.el6.x86_64
spice-client-0.8.2-15.el6.x86_64
spice-gtk-0.11-7.el6.x86_64
spice-vdagent-0.8.1-3.el6.x86_64
spice-gtk-tools-0.11-7.el6.x86_64

#rpm -qR spice-xpi
firefox  
libc.so.6()(64bit)  
.....
spice-client >= 0.8.2-13
.....

#rpm -q virt-viewer
virt-viewer-0.5.2-4.el6.x86_64

Spice-xpi always uses spicec in this installation. So it is not (yet?) the default in rhel6.3-beta

Hi,

(In reply to comment #4)
> #rpm -qa | grep spice
> spice-glib-0.11-7.el6.x86_64
> spice-xpi-2.7-17.el6.x86_64
> spice-client-0.8.2-15.el6.x86_64
> spice-gtk-0.11-7.el6.x86_64
> spice-vdagent-0.8.1-3.el6.x86_64
> spice-gtk-tools-0.11-7.el6.x86_64

Ok, so you're spice-gtk packages are slightly too old, here are the latest el6 packages:
http://people.fedoraproject.org/~jwrdegoede/rh6spice/

Can you please try the performance with these, and see how they compare with remote-viewer in Fedora-17, as well as with spicec from RHEL-6.3 beta?

Thanks,

Hans

ah spice-xpi-client is now an alternatives option so I can change on rhel63-beta between spicec and remote-viewer nice!

I updated with youre packages from comment 5. 
performance on rhel63-beta is good with both spicec and remote-viewer. Almost the same quality in the F17-VDI as on the local rhel63-beta.

If I test with remote-viewer on F17-VDI and local F17, performance is bad in VDI and good on local machine.

(In reply to comment #6)
> If I test with remote-viewer on F17-VDI and local F17, performance is bad in
> VDI and good on local machine.

Ok, so this does not seem to be a fundamental remote-viewer issue, but rather an issue with F-17 as client machine OS.

Other possible interesting data points would be:
1) Trying spicec as client under Fedora-17 (AFAIK we use the alternatives setup there too, and spicec is available in spice-client)
2) Are you running a full-blown F-17 on the client, if so can you configure gnome-shell to fallback mode, goto "system-settings" -> "system" -> "details" -> "graphics" to do this.
3) Try F-17 as client on different hardware, IE on an atom with suport Intel graphics (so no gma500)

The problem is F-17 has 3 differences which can explain this:
1) gtk3 versus gtk2
2) different kernel kms driver / mesa stack
3) gnome shell (so composited graphics) rather then gnome 2.

The above tests will help us get a better feeling for where the performance problems are coming from.

First an additional comment about an unrelated mini-bug that I've noticed in many spice sessions:  If a spice session is ended with one or more keyboard modifiers depressed - the obvious example being <ctrl>-<alt>-<backspace> - then on reconnection to the guest from a new client session these modifiers typically remain in the xkb lock-state.  Retaining the lockable modifiers is good in theory, but in practise most such locks are rarely visibly exposed as locked.  Retaining key-depressed locks is a bad idea under any circumstance.

Back to the performance issues: across a variety of guest platforms and client platforms, rough testing seems to show that spicec tends to incur about 10% (5%-15%) less CPU load than either GTK-driven client once the client CPU usage rises above 60% or so on any given core.  This seems to very roughly coincide with a slightly higher network bandwidth being generated by the GTK client-server pairing, although this correlation is imprecise at best.  In all cases I have also found that if a connection is driven to frame-stuttering (regardless of whether the qemu process or the client process is the one being caused to stutter), when using spicec the audio/video link stays synchronised, and they both stutter together.  When using the GTK clients, whether compiled with pulse or with gstreamer, synchronisation is lost immediately and is not regained.  Usually this occurs when the audio itself stutters, after which it remains lagged. Interestingly, pausing and unpausing an AV stream does not clear the lag, although restarting the AV process usually does.

Good news, from the spice-devel mailinglist:

this problem is correct by update to libjpeg-turbo 1.2.1, from the libjpeg-turbo changelog:

33 [5] Worked around a severe performance issue with "Bobcat" (AMD Embedded APU)
34	processors.  The MASKMOVDQU instruction, which was used by the libjpeg-turbo
35	SSE2 SIMD code, is apparently implemented in microcode on AMD processors, and
36	it is painfully slow on Bobcat processors in particular.  Eliminating the use
37	of this instruction improved performance by an order of magnitude on Bobcat
38	processors and by a small amount (typically 5%) on AMD desktop processors.

Thanks to nicolas prochazka for the update on this! Closing this bug since  libjpeg-turbo-1.2.1 is available as a Fedora-17 update.