----- Original Message ----- > > I don't know what were the network conditions you tested, but it > > would be great if you could repeat your test with lower bandwidth > > (you can use tc), and also, you can try disabling off-screen > > surfaces in the driver. > > I do have a test network constructed for just that purpose, so I > can manage and measure all aspects of the network. > > It was with the latency set to 80 ms that I probed the issue with the > ack window size. > > For the tests I ran, though, I was on an uncrippled network, using > all default settings for Xspice. I do not know what form of image > compression was in use; only that it would be whatever default would > be chosen (I believe the default is auto lz, and my sense is that > I was mostly seeing lz and quic images going across the wire, but > don't quote me on that). I forgot to ask that you measure CPU consumption on the server: You could have (manually) enable better compression schemes for the images, which would have reduced the total bytes sent. That costs CPU, though. BTW, if you could post a (compressed) capture of your traffic, should be fairly easy to evaluate how many images were sent, how many were cached, and how many other commands were sent. May help focus on the important stuff to optimize, from bandwidth point of view. Y. > > As far as I recall, disabling surfaces prevented Xspice from > working properly, so I did not test that mode. I did not really > understand how to analyze the effectiveness of surface caching, > so while I saw the ability to gather those statistics, I didn't > do that exercise. > > I haven't tried throttling bandwidth; it's interesting to know that > the code > may respond to that condition. > > > > > In the same matter, another improvement we planned is to change the > > limit for the size of the queue of messages directed to the > > client: currently it is limited to a constant number of messages. > > When we reach the limit, we stop reading from the driver command > > ring. We planned to change it to use a limit based on the > > estimation of the total size that is pending to be sent to the > > client. Maybe we should consider limiting it by the time duration > > from the head to tail. In this manner we can have more control of > > the refresh rate, and maybe be able to drop more commands than > > today. > > > > That said, if the scenario is composed of commands that don't hide > > one another, all the above wouldn't help. > > Right; the worst case scenario I hit was a set of 27,000 draw > operations, > each one next to the other, none hiding another. > > What I found as I probed typical use cases for most Linux apps > was that solid() calls dominated the use case; with a typical > run containing a few thousand 'other' calls, and then 100,000 > or more calls to solid(). > > (Of course, a case I care strongly about, MS Office in Wine, turns > out to devolve into a lot of surfaces and copies, so it wasn't > strictly true :-/). > > > How are you verifying that the user experience remains the same? > > That there is no tearing, distortion, missing elements, etc.? > > > > That's a good question; I don't have a great answer. It Works For Me > (TM) > is pretty lame <grin>. Seriously, we plan to do some QA around this > whole > stack, so I expect to uncover a few further issues. > > The test code I posted does include an option to record the user > session > to a movie file; I plan to use a video diff tool to compare the > resulting > movie to a capture of a session running purely on an Xvfb server. > That will > give me a number to use to compare to 'correct'. I hope to use that > to > quantify the 'quality' of various solutions. > > Note that this sounds nice on paper; I have yet to actually do this, > so it > may not work all that well in practice. The session capture software > seems > to work only so-so, and the diff software costs money that I haven't > spent yet. > > But I would very much appreciate other suggestions on how best to > test > and verify that the solution is working well. > > Cheers, > > Jeremy > _______________________________________________ > Spice-devel mailing list > Spice-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/spice-devel > _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel