On 11/16/11 5:25 AM, Pierre Ossman wrote: > 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.
Well, then, what are you considering to be appropriate WAN settings? When my users connect over a 5 Mbps link, they will typically dial down the quality in TurboVNC to the "Low-Quality JPEG" preset and then use automatic lossless refresh to send a lossless image during periods of inactivity. This is the only way to get interactive frame rates with 3D applications over such a connection. > 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. Sorry about that. So ignore my comments regarding CL=3. The relative B/W and speedup were not far off from the CL=1 tests. > 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. I don't know how you justify that statement. I tested both a low-quality and high-quality JPEG scenario and reported both. > 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. Here are the relative compression ratios and speedups for the 2D datasets when moving from CL=1 to CL=2 (I will add these numbers to the next iteration of the spreadsheet): bugzilla: -6.1% CR, -1.1% speedup compilation: -19% CR, 3.1% speedup bars: -1.6% CR, -8.1% speedup kde-hearts-16: -0.46% CR, -2.2% speedup freshmeat: -4.9% CR, -4.3% speedup slashdot: -6.7% CR, -25% speedup photos: -0.63% CR, 4.9% speedup kde-hearts-24: -0.39% CR, -3.3% speedup The 3D apps almost always suffer a much worse speedup (in the range of 10-20%) with very little gain in compression ratio. CL=1 is definitely the most "efficient" compression level in terms of CPU usage. > 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'm trying hard not to laugh. Let's be realistic-- besides Cendio, Brian and I are the only ones doing any significant development in recent months. Thus, I'm not sure we really have an "upstream project" here. It seems like the project goals are largely what Cendio wants them to be, and friction arises whenever someone (usually me) disagrees with that. > 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. Yes, you should talk to your marketing department about this, since they are the ones who hired me to make TigerVNC into a TurboVNC replacement. If that was never the goal, then I need to reset my expectations regarding this project. > 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 Again, talk to your marketing department, as I was told otherwise. If you aren't looking to replace TurboVNC, then the question becomes whether it is best for The VirtualGL Project to work within the confines of the TigerVNC Project or whether I should just move forward within my own project. I don't want to invest any more significant time in a project that will ultimately be moving in a direction that is not aligned with the goal of achieving peak performance for 3D apps. > 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. I don't believe that there are generally one "golden" set of configuration parameters that can make everyone happy, which is why we have knobs that users can tweak. Ideally, some of this stuff should be set automatically based on the network conditions, but we don't have that technology yet, so the default settings will either be LAN-friendly or WAN-friendly. I don't think they can be both. If you're more interested in Firefox and LibreOffice, then why did you hire me to re-factor the Tight Encoder to make it behave like TurboVNC? It goes without saying that this re-design was targeted more toward 3D and video apps and may have sacrificed some "tightness" for 2D apps. There is always a balance that has to be struck. You can throw every trick in the book at reducing bandwidth, but ultimately you use so much CPU time that your performance is down to 1 Megapixel/second and is no longer bandwidth-limited anyhow. Then there is the opposite approach: throwing every trick in the book at increasing performance, but ultimately you use so much bandwidth that your performance is no longer CPU-limited, even on a gigabit network. I struck an appropriate balance for the types of apps I care about, but if that differs from the types of apps Cendio cares about, then you guys would need to repeat the analysis using session captures that are more reflective of what you think your users will be doing. I was hired to make TigerVNC an out-of-the-box replacement for TurboVNC, so that's what I've been trying to do since July. If that was never a goal, then Cendio really needs to reset and figure out what you guys want. > 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. My goals are a direct out-of-box replacement for TurboVNC. I would hope we can come to a solution that achieves that goal while still maintaining the goal of making TigerVNC a general-purpose VNC solution. If we can't, then my best path forward is a "VirtualGL edition", as you suggested above, but whether or not that product is best built using the TigerVNC code base or by using a hybrid of TigerVNC and TurboVNC technologies remains to be seen. Some of the features in TigerVNC-- such as the ability to build with multiple X server code bases-- require a lot of time to support but are completely irrelevant to my market. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
