> 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). 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 [email protected] http://lists.freedesktop.org/mailman/listinfo/spice-devel
