[Spice-devel] Unfair comparisons with RDP

[Alon Levy]

On Sat, Jul 02, 2011 at 02:34:15PM -0400, John A. Sullivan III wrote:
> On Fri, 2011-07-01 at 17:05 +0200, Alon Levy wrote:
> > On Fri, Jul 01, 2011 at 03:00:32PM +0200, Gianluca Cecchi wrote:
> > > On Fri, Jul 1, 2011 at 1:04 PM, John A. Sullivan III  wrote:
> > > > Interesting observation. That is true; we did not create separate VM
> > > > definitions for SPICE and TSPlus thus the TSPlus environment is using
> > > > the QXL driver.  Would we expect that to have any "supercharging" effect
> > > > on RDP?
> > > >
> > > >
> > > 
> > > Probably not, because afaik (that is not so much ;-) Remote Desktop
> > > (and probably tsplus too) works at the GDI call level, so it should
> > > not depend so much on video adapter/video driver...
> > > It was simply a question that arose analysing how to correctly
> > > replicate comparisons...
> > > Coming back to the test case and these operations:
> > > 
> > > rdp
> > > 17:             display desktop, i.e., minimize all open applications
> > > 42:             Paint existing LibreOffice document, i.e., restore from minimize
> > > 
> > > spice
> > > 61:             display desktop, i.e., minimize all open applications
> > > 92:             Paint existing LibreOffice document, i.e., restore from minimize
> > > 
> > > I think they are GDI ones, so that naturally when using rdp they are
> > > executed locally on client desktop (only the gdi directives are sent),
> > > while in spice (raster?) they will be network intensive (from a slow
> > spice implements a driver, which implements a large part of the gdi api. So any
> > operation that it doesn't implement is done via the windows gdi software rendering
> > and the result given to the driver (which is spice) as an image.
> > 
> > So in cases where the specific operations are all implemented by the driver the
> > performance should be identical. In other cases spice will be suboptimal, since
> > it will send the image and not the operation. In both cases the rendering should
> > be correct.
> <snip>
> Hmmm . . . as I think about it, this is why I was surprised that the
> streaming video performance was not better and why MJPEG mattered at all
> so I'm sure there's some kind of fundamental misunderstanding on my part
> and perhaps the part of other SPICE newbies.
> 
> Let's go back to the classic scenario of a user watching a YouTube video
> in their browser.  If they are watching it locally, the local computer
> is decoding the stream and sending GDI or X (is X the proper term for
> the graphics rendering engine in Linux?) commands to the local video
> output.
> 
> If they are using SPICE to view the guest, I was assuming that the guest
> is decoding the video stream and the SPICE server on the host is then
> sending the GDI or X commands to the SPICE client.  Thus, unless those
> commands consume a lot of bandwidth, why would the performance the
> client sees be any slower than if they were playing it locally if it is
> the same set of GDI or X commands?

Bandwidth of Youtube video: (guessing) 200 KB/sec
Bandwidth of resulting GDI writes (assume uncompressed frames of 320x240 32bps, 20 fps, again
I know the numbers are wrong but for ball park figures): 6000 KB/s

Bandwidth of mjpeg stream: don't know. somewhere in the middle.

> 
> Is the bottleneck not the SPICE communication between SPICE server and
> client but rather the QXL communication between guest and host, i.e.,
> the guest is decoding flv but then sending MJPEG to the host and that's
> the bottleneck? Then again, that's a backplane connection and should be
> oodles faster than any Internet connection.
No, that isn't the problem. The problem is that the mjpeg stream uses much
more bandwidth then the flv.

> 
> Where is my understanding broken? Thanks - John
>