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.)
What I observe is that enabling the CUT with compress level=1 only shows a significant low-level improvement for a few 2D tests: "bugzilla" (web browsing): 57% B/W reduction with LAN settings 42% B/W reduction with WAN settings "kde-hearts" (manipulating file manager windows in KDE): 31% B/W reduction with LAN settings 17% B/W reduction with WAN settings "photos" (viewing a photo in GIMP): 40% B/W reduction with LAN settings 22% B/W reduction with WAN settings The improvement is greatly reduced as the JPEG quality is reduced. This makes sense, because with lower-quality JPEG, less bandwidth is required for each rectangle, on average, and thus the bandwidth that one can save by enabling the CUT is reduced, on average. For the other 2D tests, only a modest (~5-10%) bandwidth reduction was observed with compress level=1. For the 3D tests, no significant bandwidth reduction was achieved with compress level=1 (not surprising at all), but enabling the CUT decreased the performance by very significant amounts (as much as 45% reduction in throughput with the LAN settings.) That is definitely unacceptable, since 3D apps are performance-critical. I would argue that a 45% reduction in frame rate for a user of a CAD application on a LAN is going to make a much larger impact in their ability to use the app than would a 45% reduction in Firefox's update rate on a WAN. Increasing the CUT block size to 256 x 256 improved matters-- surprisingly, no loss in bandwidth was observed relative to the 16 x 16 tests, and now the 3D tests slowed down by a max. of 26% when enabling the CUT with LAN settings. Still an unacceptable slow-down, but better. 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. 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? (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. This is a compromise that I would hope would make both parties happy for now. The CUT still needs optimizing, because even with the larger block size, the relative loss in throughput for 2D apps often exceeds the relative reduction in bandwidth. I could easily conceive of scenarios in which applications that were bandwidth-limited with the CUT disabled would become CPU-limited with it enabled. 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. 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.
lowlevelcutperf.ods
Description: application/vnd.oasis.opendocument.spreadsheet
------------------------------------------------------------------------------ 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
