On Tue, 15 Nov 2011 18:36:55 -0600 DRC <dcomman...@users.sourceforge.net> wrote:
> The attached spreadsheet shows the low-level performance effects of > enabling and disabling the CUT, as well as the effect of changing its > block size to 256 x 256 instead of the default of 16 x 16. Tests were > performed both with typical LAN settings (compress level=1/quality > level=8) and WAN settings (compress level=3/quality level=1 and compress > level=1/quality level=1.) > JPEG quality level 1 is not what I'm considering a reasonable WAN setting, so I'm not sure how realistic these numbers are. Still, I think my conclusions are roughly the same. > The CUT made a much larger difference in bandwidth with compress > level=3. In this case, even some of the 3D datasets realized some > significant reduction in bandwidth, but the performance hit from > enabling the CUT was larger across the board as well. Your sheet has a bug in it so you're comparing the wrong cells. It referenced the G column instead of the O column. The bandwidth savings are about the same for both compression levels. This also means the CPU overhead was exaggerated. > > Here's what I would recommend for now: > > (1) Change BLOCK_SIZE to 256. This didn't seem to have any effect on > compression ratio, and it improved performance significantly whenever > the CUT was enabled. Pierre, could you re-run your high-level tests to > verify that this has no ill effects at that level, either? I'm not surprised. I suspected the 16x16 blocks had less than ideal cache usage. I see no problems with this change, but I'll double check with some tests. > > (2) Enable the CUT by default only when compress level > 1. Disable it > by default for compress level <= 1. The compress level and quality > level are designed precisely so that users can make such bandwidth vs. > CPU usage trade-offs as this. The default TigerVNC settings are > appropriate for LAN use, in which the benefits of the CUT do not > outweigh the performance costs. > Maybe. Given your current numbers, this might make some sense. But since the JPEG quality is unrealistically low (IMO), the numbers are currently showing off the CUT at its worst. This also made me take another look at the compression setting. I have to admit I might have read through your previous report a bit too hastily. This new one had more data though, which allowed a more detailed analysis. Looking at the first few tests (the "normal" applications), the bandwidth savings of dialing up the compression is somewhere around 20%. CPU usage varies, but seems to be roughly that for every percentage bandwidth saved, you lose the same percentage of CPU. The 3D applications fare worse, getting generally less savings and eating more CPU. Given this, I'm no longer convinced that having a default compression level of 1 is so clear cut. "Normal" usage seems to have quite a bit of potential gain here. > If Cendio wants the CUT always enabled for their product, then that is > easily accomplished by modifying the vncserver startup script, which I > assume is something they already do. We could, but we generally would like not to. We prefer if our goals align with the upstream projects we use. There is less friction when it comes to long term plans that way, and having our users running basically the same product as the project's users benefits both when it comes to finding and fixing bugs. > I do not think that enabling it by > default for the open source product is appropriate unless the user sets > compress level > 1, indicating that they are in an environment in which > reducing bandwidth is more likely to improve performance than reducing > CPU usage. And I'd argue the opposite that users should indicate that they are in an environment where bandwidth is of little relevance and that CPU usage should be prioritised. Bug again, this boils down to which users we are targeting for TigerVNC. Let's be very clear. Cendio is not looking for a direct replacement of TurboVNC. Our hopes for TigerVNC is for it to become the standard VNC implementation, appealing to a very broad range of users. LAN users, including high-performance 3D users, are certainly a part of this. But it is not our belief that they are the majority and the project should by default be geared towards more average users. That means applications such as Firefox and LibreOffice generally carry more weight than Catia or Maya. We have always had a hope that TigerVNC could replace TurboVNC, but not necessarily out-of-box. If we cannot make the system clever enough to work for everyone, then it is the niche users (like high performance 3D) that will have to tweak things. The average joes should just be able to install and run. This tweaking could of course be handled by custom packing, like "TigerVNC - VirtualGL Edition" or such. We could also look at having the vncserver script do some magic like seeing if VirtualGL is configured on the machine. Working for a large user base has the best chances for a thriving project that will attract not only users, but also developers which in turn gives us even more resources to produce a fantastic product. But this is just Cendio's view, which up until now we though was shared with the rest of the project. Evidently that isn't entirely so. So I'd like to hear from our other developers, and users, what they are hoping to get from TigerVNC. We haven't heard anything from Adam. What are Red Hat's goals with this project? Rgds -- Pierre Ossman OpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
