Re: [Tigervnc-devel] Xvnc performance optimizations completed
On 9/12/11 7:25 AM, Pierre Ossman wrote: > Your analysis mentioned that the compression levels also affected > the sub-rectangle logic, and it wasn't entirely clear to me how > important that knob was. Not anymore they don't. In prior versions of TigerVNC, they did. The analysis clearly shows, however, that even when the compression levels did affect the subrectangle encoding logic, anything above 6 was still useless. We're not just talking about one app, either. The tests encompassed 20 very different sample workloads, both from 3D and 2D applications. >> Your proposal doesn't make sense, because it changes the behavior of the >> server relative to other servers (including our own 1.1 server.) It >> will only cause confusion. > > That ship has already sailed as you made some changes what the > compression levels mean with regard to sub-rectangles, as well as > changes to the general compression method logic. > > In my world, the settings on the client express an intent with regards > to relative trade-offs between CPU, bandwidth and quality. It does not > express an expectation of specific actions on the server. This is exactly why your proposal doesn't make sense to me. If a user selects compression level 0, they intend for the behavior to be different from selecting compression level 2. In your proposal, compression levels 0-2 would be the same if they were using a TigerVNC server, but they would be different if using another type of VNC server. Further, my study did not encompass other methods of encoding, such as plain Zlib, that also use compression levels 0-9. It is unknown whether 7-9 are useless for those encoding methods, so I don't want to remove them altogether in case there are fringe scenarios in which they may be useful. > I'm not arguing the results of your findings, just how the interface > should be presented to the user. I'd like these two goals to be met: > > a) Users upgrading shouldn't be punished because of older defaults. > > b) Users shouldn't have to tweak their settings when switching between > a TigerVNC server and other ones. > > I'm hoping these aren't conflicting goals. I don't see how users are "punished" because of anything. As the report states, in almost all cases, the new encoder is both tighter and faster for each compression level than the old encoder. For the corner cases in which that is not true, bumping up the compression level by one restored the previous compression ratio. As far as tweaking their settings, of course users have to tweak their settings when switching between TigerVNC and other servers. That has always been the case and always will be. Only our server and TurboVNC support high-speed Tight encoding. If the user is using a RealVNC server, for instance, the compression level may not even be relevant. -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Xvnc performance optimizations completed
On Wed, 07 Sep 2011 11:52:09 -0500 DRC wrote: > > Hi, Pierre. You may have missed that part of my analysis, but levels > above 6 are equally as useless on older TigerVNC versions, as well as > TightVNC (and TurboVNC doesn't use anything above level 1.) > Your analysis mentioned that the compression levels also affected the sub-rectangle logic, and it wasn't entirely clear to me how important that knob was. > Additionally, this change is only to the GUI. You can still select > levels 7-9 from the command line. That's because I don't want to take > those levels away from the user, in case there is some extremely rare > corner case in which they might be beneficial. However, until/unless > someone comes forward with a strong case showing where 7-9 are > beneficial, I want to heavily discourage the use of those levels. My > extensive testing revealed that 4-6 are very rarely useful, and 7-9 > never are. I'm fine with removing support for fringe scenarios if it means a simpler interface for the majority of users. > Your proposal doesn't make sense, because it changes the behavior of the > server relative to other servers (including our own 1.1 server.) It > will only cause confusion. That ship has already sailed as you made some changes what the compression levels mean with regard to sub-rectangles, as well as changes to the general compression method logic. In my world, the settings on the client express an intent with regards to relative trade-offs between CPU, bandwidth and quality. It does not express an expectation of specific actions on the server. Since your findings have concluded that 6 (or possibly 3) is the point where more CPU doesn't really give a reduction in bandwidth, that should be the maximum for the CPU/bandwidth trade-off IMO. > > If I really had my way, we'd hide 4-6 as well, as those are only useful > in very rare corner cases. Hiding only 7-9 is a compromise. > > I spent hundreds of hours coming to my conclusion, so it's going to take > more than a few minutes of reasoning for you to convince me otherwise. I'm not arguing the results of your findings, just how the interface should be presented to the user. I'd like these two goals to be met: a) Users upgrading shouldn't be punished because of older defaults. b) Users shouldn't have to tweak their settings when switching between a TigerVNC server and other ones. I'm hoping these aren't conflicting goals. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: 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 -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Xvnc performance optimizations completed
On 9/7/11 7:54 AM, Pierre Ossman wrote: >> The viewer GUI has also been modified to reflect the findings from the >> low-level performance study (specifically, that compression levels >> higher than 3 rarely have any benefit and compression levels higher than >> 6 never do. Also, compression level 1 is now the default, since it >> offers the best "bang for the buck.") It is still possible to enter >> level 7-9 in the GUI or specify it from the command line, but IMHO, we >> should pretend as if those levels don't officially exist anymore. If >> someone can show a case in which levels 7-9 produce a demonstrably >> better result than 6, I am eager to examine it. > > I'm thinking that changing the client might not be the best way to deal > with this, for two reasons: > > a) Trade-offs between CPU and bandwidth are now different for our > server than others, making it impossible for users to have a good > default setting. > > b) We're wasting part of the compression configuration range. Minor > issue right now though as I guess we currently have no use for extra > steps. > > I suggest we revert the change on the client and change how the server > interprets the compression setting. A crude example: > > 0-2 => zlib level 0 > 3-6 => zlib level 1 > 7 => zlib level 2 > 8 => zlib level 4 > 9 => zlib level 6 > > This would make sure that a good setting for connecting to the new > TigerVNC server would also be a good setting for older versions, as > well as other implementations. And existing clients wouldn't be > punished for the previous default value. > > Downside would be that we lose access to higher zlib levels, but if > your analysis is correct then we aren't losing anything of value. > > (We could of course add more meaning to the lower levels in the future > to differentiate them, like how aggressively we look for solid rects > or using the comparing update tracker) Hi, Pierre. You may have missed that part of my analysis, but levels above 6 are equally as useless on older TigerVNC versions, as well as TightVNC (and TurboVNC doesn't use anything above level 1.) Additionally, this change is only to the GUI. You can still select levels 7-9 from the command line. That's because I don't want to take those levels away from the user, in case there is some extremely rare corner case in which they might be beneficial. However, until/unless someone comes forward with a strong case showing where 7-9 are beneficial, I want to heavily discourage the use of those levels. My extensive testing revealed that 4-6 are very rarely useful, and 7-9 never are. Your proposal doesn't make sense, because it changes the behavior of the server relative to other servers (including our own 1.1 server.) It will only cause confusion. If I really had my way, we'd hide 4-6 as well, as those are only useful in very rare corner cases. Hiding only 7-9 is a compromise. I spent hundreds of hours coming to my conclusion, so it's going to take more than a few minutes of reasoning for you to convince me otherwise. -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Xvnc performance optimizations completed
On 09/07/2011 08:54 AM, Pierre Ossman wrote: On Wed, 17 Aug 2011 01:40:48 -0500 DRC wrote: As of now, with the ComparingUpdateTracker disabled and using our FLTK viewer, the performance is at about 85-90% of TurboVNC at the high levels, and the remaining gap is entirely due to the viewer. The server CPU usage is now almost exactly the same as TurboVNC. That is great work! I'm thinking that changing the client might not be the best way to deal with this, for two reasons: a) Trade-offs between CPU and bandwidth are now different for our server than others, making it impossible for users to have a good default setting. b) We're wasting part of the compression configuration range. Minor issue right now though as I guess we currently have no use for extra steps. I suggest we revert the change on the client and change how the server interprets the compression setting. A crude example: 0-2 => zlib level 0 3-6 => zlib level 1 7 => zlib level 2 8 => zlib level 4 9 => zlib level 6 This would make sure that a good setting for connecting to the new TigerVNC server would also be a good setting for older versions, as well as other implementations. And existing clients wouldn't be punished for the previous default value. I really don't like the idea of mapping these literal values. It makes the numbers used for zlib non specific and prevents access to the higher levels at all. I understand the need to have client defaults and that you are trying to force a default on 3rd party clients. I will admit that I don't have a good alternative to it either. I would much rather see these changes in the viewer than on the server. I really liked how TightVNC had three radio button options for quick connection settings. They were the default, low bandwidth and high bandwidth. These automatically changed the encoding type, zlib compression and jpeg quality settings. Downside would be that we lose access to higher zlib levels, but if your analysis is correct then we aren't losing anything of value. (We could of course add more meaning to the lower levels in the future to differentiate them, like how aggressively we look for solid rects or using the comparing update tracker) Rgds -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel -- Robert Goley FOSS Implementation Specialist Toll Free: (800) 338-4984 Local: (770) 479-7933 Fax: (770) 479-4076 www.openrda.com America's only Free & Open Source fund accounting software company. -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Xvnc performance optimizations completed
On Wed, 17 Aug 2011 01:40:48 -0500 DRC wrote: > As of now, with the ComparingUpdateTracker disabled and using our FLTK > viewer, the performance is at about 85-90% of TurboVNC at the high > levels, and the remaining gap is entirely due to the viewer. The server > CPU usage is now almost exactly the same as TurboVNC. That's just fantastic. Awesome work! > The viewer GUI has also been modified to reflect the findings from the > low-level performance study (specifically, that compression levels > higher than 3 rarely have any benefit and compression levels higher than > 6 never do. Also, compression level 1 is now the default, since it > offers the best "bang for the buck.") It is still possible to enter > level 7-9 in the GUI or specify it from the command line, but IMHO, we > should pretend as if those levels don't officially exist anymore. If > someone can show a case in which levels 7-9 produce a demonstrably > better result than 6, I am eager to examine it. I'm thinking that changing the client might not be the best way to deal with this, for two reasons: a) Trade-offs between CPU and bandwidth are now different for our server than others, making it impossible for users to have a good default setting. b) We're wasting part of the compression configuration range. Minor issue right now though as I guess we currently have no use for extra steps. I suggest we revert the change on the client and change how the server interprets the compression setting. A crude example: 0-2 => zlib level 0 3-6 => zlib level 1 7 => zlib level 2 8 => zlib level 4 9 => zlib level 6 This would make sure that a good setting for connecting to the new TigerVNC server would also be a good setting for older versions, as well as other implementations. And existing clients wouldn't be punished for the previous default value. Downside would be that we lose access to higher zlib levels, but if your analysis is correct then we aren't losing anything of value. (We could of course add more meaning to the lower levels in the future to differentiate them, like how aggressively we look for solid rects or using the comparing update tracker) Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: 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 -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Xvnc performance optimizations completed
OK, I'm an idiot. The TigerVNC Server with the ComparingUpdateTracker disabled was not generating twice the data when the TurboVNC Viewer connected. I had simply forgotten the way that TurboVNC maps its 1-100 quality scale to TigerVNC's 1-9 quality scale, so in fact I was comparing JPEG quality 92 with JPEG quality 100, which is a difference in compression ratio of about 2x. Blerg. We now return you to your regularly-scheduled program. So, in short, with the right settings, I can now produce exactly the same performance with the TurboVNC Viewer connecting to the TigerVNC Server and the TurboVNC Server. I think our Unix server is pretty much golden performance-wise, unless someone discovers any other issues. To the latter end, I've generated a new trunk build with the Xvnc perf. enhancements and new default viewer settings: http://www.virtualgl.org/DeveloperInfo/TigerVNCPreReleases This also has the "custom compression level" bug fix that went into 1.1.0. On 8/17/11 1:40 AM, DRC wrote: > Under sponsorship by Cendio, I have completed an extensive (as in 100+ > hours) set of performance optimizations to the TigerVNC Server in trunk, > which should bring its performance completely in line with TurboVNC, > provided that the ComparingUpdateTracker is disabled. I am > investigating the afore-mentioned issue with that whereby it is sending > twice as much data as it should when legacy clients are connected, and > pending a fix for that, I will likely recommend disabling the tracker as > the default. > > The process of optimizing the server involved the following steps: > > (1) High-level benchmarking and differential performance analysis to > determine the baseline relative to TurboVNC. TigerVNC trunk was > determined to be about 30-40% slower at the high level, and at the low > level, the server was using about 65% more CPU time to encode the same > data as TurboVNC. > > (2) Low-level analysis of the encoder using the processes described in > the following reports: > > http://www.virtualgl.org/pmwiki/uploads/About/turbototiger.pdf > http://www.virtualgl.org/pmwiki/uploads/About/tighttoturbo.pdf > > In a nutshell, the encoder was studied in isolation using a set of > low-level RFB performance tools and protocol captures. The link to the > code for these tools, including the isolated TigerVNC 1.1 and 1.2 > encoders, is provided in the reports. The isolated encoder has already > proven its usefulness in other areas (I used it to isolate the Zlib bug > and verify the low-level stability of the fix.) > > (3) After the low-level analysis was complete, I started integrating the > modified encoder back into TigerVNC, only to discover that one of the > main performance features that was added to it-- the pre-computation of > solid rectangles-- required another feature: last rectangle encoding. > Thus, I had to implement last rectangle encoding in the TigerVNC > transport layers. > > (4) At this point, we had an encoder that produced the same output as > TurboVNC and performed similarly to TurboVNC at the low levels, but the > high-level performance was still lacking. This was due to two factors: > (a) the afore-mentioned ComparingUpdateTracker, and (b) the image > getter. The process of getting the images from the framebuffer to the > encoder was very inefficient. Thus, I went back and overhauled the > encoder again, this time porting in the code from TurboVNC that allows > the encoder to compute solid rectangles, count colors, and compress JPEG > directly from the framebuffer without transforming the pixels first. > This involved some re-architecture to several of the classes in librfb > to allow access to the virtual FB from within the encoders. There is > probably a cleaner way to do what I did, but IMHO, it's at least cleaner > now than it was. > > > As of now, with the ComparingUpdateTracker disabled and using our FLTK > viewer, the performance is at about 85-90% of TurboVNC at the high > levels, and the remaining gap is entirely due to the viewer. The server > CPU usage is now almost exactly the same as TurboVNC. Whereas the FLTK > viewer is a bit more efficient than the old X viewer, it still needs > some optimization work, which I'll begin looking at next month. > > > In the meantime, please be on the lookout for potential performance > pitfalls in the new encoder, particularly on low-bandwidth networks. If > you discover situations in which the new Xvnc appears to produce worse > performance than the old Xvnc, please try your best to quantify the > difference and verify whether jacking up the compression level a notch > or two restores the performance you expect (it should, unless I miss my > guess.) > > > The viewer GUI has also been modified to reflect the findings from the > low-level performance study (specifically, that compression levels > higher than 3 rarely have any benefit and compression levels higher than > 6 never do. Also, compression level 1 is now
[Tigervnc-devel] Xvnc performance optimizations completed
Under sponsorship by Cendio, I have completed an extensive (as in 100+ hours) set of performance optimizations to the TigerVNC Server in trunk, which should bring its performance completely in line with TurboVNC, provided that the ComparingUpdateTracker is disabled. I am investigating the afore-mentioned issue with that whereby it is sending twice as much data as it should when legacy clients are connected, and pending a fix for that, I will likely recommend disabling the tracker as the default. The process of optimizing the server involved the following steps: (1) High-level benchmarking and differential performance analysis to determine the baseline relative to TurboVNC. TigerVNC trunk was determined to be about 30-40% slower at the high level, and at the low level, the server was using about 65% more CPU time to encode the same data as TurboVNC. (2) Low-level analysis of the encoder using the processes described in the following reports: http://www.virtualgl.org/pmwiki/uploads/About/turbototiger.pdf http://www.virtualgl.org/pmwiki/uploads/About/tighttoturbo.pdf In a nutshell, the encoder was studied in isolation using a set of low-level RFB performance tools and protocol captures. The link to the code for these tools, including the isolated TigerVNC 1.1 and 1.2 encoders, is provided in the reports. The isolated encoder has already proven its usefulness in other areas (I used it to isolate the Zlib bug and verify the low-level stability of the fix.) (3) After the low-level analysis was complete, I started integrating the modified encoder back into TigerVNC, only to discover that one of the main performance features that was added to it-- the pre-computation of solid rectangles-- required another feature: last rectangle encoding. Thus, I had to implement last rectangle encoding in the TigerVNC transport layers. (4) At this point, we had an encoder that produced the same output as TurboVNC and performed similarly to TurboVNC at the low levels, but the high-level performance was still lacking. This was due to two factors: (a) the afore-mentioned ComparingUpdateTracker, and (b) the image getter. The process of getting the images from the framebuffer to the encoder was very inefficient. Thus, I went back and overhauled the encoder again, this time porting in the code from TurboVNC that allows the encoder to compute solid rectangles, count colors, and compress JPEG directly from the framebuffer without transforming the pixels first. This involved some re-architecture to several of the classes in librfb to allow access to the virtual FB from within the encoders. There is probably a cleaner way to do what I did, but IMHO, it's at least cleaner now than it was. As of now, with the ComparingUpdateTracker disabled and using our FLTK viewer, the performance is at about 85-90% of TurboVNC at the high levels, and the remaining gap is entirely due to the viewer. The server CPU usage is now almost exactly the same as TurboVNC. Whereas the FLTK viewer is a bit more efficient than the old X viewer, it still needs some optimization work, which I'll begin looking at next month. In the meantime, please be on the lookout for potential performance pitfalls in the new encoder, particularly on low-bandwidth networks. If you discover situations in which the new Xvnc appears to produce worse performance than the old Xvnc, please try your best to quantify the difference and verify whether jacking up the compression level a notch or two restores the performance you expect (it should, unless I miss my guess.) The viewer GUI has also been modified to reflect the findings from the low-level performance study (specifically, that compression levels higher than 3 rarely have any benefit and compression levels higher than 6 never do. Also, compression level 1 is now the default, since it offers the best "bang for the buck.") It is still possible to enter level 7-9 in the GUI or specify it from the command line, but IMHO, we should pretend as if those levels don't officially exist anymore. If someone can show a case in which levels 7-9 produce a demonstrably better result than 6, I am eager to examine it. DRC -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
