On Wed, 2011-07-20 at 10:13 +0300, Yaniv Kaul wrote: > On 07/20/2011 05:31 AM, John A. Sullivan III wrote: > > Hello, all. I know I've raised a large number of issues over the last > > few weeks most of which are still open. I'd like to summarize them here > > and ask for your direction on how we can further troubleshoot and > > resolve them, in other words, how can we as integrators rather than > > programmers help. > > > > The bottom line is that SPICE is much slower than RDP for accessing the > > same Windows guest and it is not only orders of magnitude slower than > > X2Go for accessing Linux guests, it is not even usable. It is quite > > possible we have mangled the installation but we have tried to be > > careful and have stuck primarily with Fedora 15 to make our installation > > as much "out of the box" as possible. Here are the specifics: > > I'd like to suggest you open bugs on each issues, so they can be > identified and tracked by all. > I know you have opened on some, but having the ability to talk about bug > XYZ is easier than 'Linux guest driver issue'.
Gladly but I'm not sure all are bugs. I suppose that's part of what I'm asking. For example, the high CPU utilization in Linux and the non-responsive VDAgent seem to be so I've opened those but I'm not sure about the general performance issues. That's why I was asking for some guidance for us to do more troubleshooting before we open it as a bug > > <snip>> > > Windows guest - both Windows 7 and Windows Server 2008: > > SPICE is transferring four to five times as much data across the wire as > > RDP even with effects disabled. VDAgent is running although it is > > sometimes unstable and we are using a virtio serial driver. QXL driver > > is working. We were told it that our packet traces seemed to indicate > > we were not compressing images even though we are configured to do so, > > our bandwidth is less than 10 Mbps, and the qemu server logs seem to > > indicate we are using compression. We reconfigured to force compression > > and saw the same anecdotal results. I'm not sure how we measure this if > > the configuration and logs are saying we are compressing. How can we > > verify this lack of compression? Is this discerned from the Wireshark > > dissector? If so, is there a newer one available than the one on the web > > site? > > Attached please find the latest source of the Spice dissector. It's not > that great (and it's a hacky reverse-engineered dissector), but it gets > the work done. > Feel free to send me (off-list, compressed) packet captures that look > wrong, and I might try to fix some of the issues (I'm aware of many > already, the code is full of FIXME's and TODOs). > Y. > > <snip>> > > So, I suppose one question is, are these because of misconfigurations on > > our part or are they bugs still being worked out in SPICE? Would it make > > more sense for use to recompile everything from git? If so, which > > repository? However, does that then imply that SPICE is not yet really > > ready for production WAN use? > > > > Sorry to be a pain but I suppose it is because we really want to use > > SPICE but we keep coming up a little short compared to more mature > > technologies. Thanks - John <snip> _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
