Re: [Tigervnc-devel] Cendio preparing for new release
On Dec 28, 2011, at 9:25 AM, Peter Åstrand wrote: >> On 12/22/11 2:41 AM, Peter Åstrand wrote: >>> I'll let Pierre give you the details of the -DeferUpdate values, but if >>> it turns out that it's not possible to find a default that fits >>> everyone, then I'm suggesting that we create a special script >>> "turbovncserver", "vglvncserver" or something like that. It can then >>> have defaults that are optimal for the 3D-on-LAN case. >> >> Except that that still requires a user to explicitly do something >> different on the server than they would normally do, and users forget to >> do that. Maybe there is no way to reconcile the differences between 2D >> and 3D apps, but we haven't really tried. I've provided tons of data >> regarding 3D and video app performance, but the equivalent data does not >> exist for 2D apps, so we really don't know what's best for those apps, >> and we can't make that judgment just based on gut feelings or quick & >> dirty benchmarks. We need something more quantifiable. > > I think we have provided quantifiable data. If you did, I never saw it. > I agree that additional tests would be useful though, but there are also > other things that needs attention. I think the core of the problem is there > will always be some kind of tradeoff/compromise, and if I understand the > VirtualGL/TurboVNC perspective correctly, there's no interest in this. > Anything that, say, increases the CPU, even so little, is a no-no. Given > these priorities, it seems difficult to find a solution that fits both use > cases by default. Not difficult at all. We have a solution that fits both use cases by default: it's the same solution we used with 1.1.0 and are now using with 1.2 beta1, which is setting DeferUpdate to 1 ms. You and Pierre have not provided any test cases which demonstrate that 10 ms is beneficial, and Pierre admitted that the choice of that value was more of a gut instinct, which is why we changed it back until further information can be gathered. Pierre and I have reached at least a temporary agreement regarding this, so I'm not sure what you hope to gain by continuing to argue the point. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Cendio preparing for new release
On 12/22/11 2:41 AM, Peter Åstrand wrote: I'll let Pierre give you the details of the -DeferUpdate values, but if it turns out that it's not possible to find a default that fits everyone, then I'm suggesting that we create a special script "turbovncserver", "vglvncserver" or something like that. It can then have defaults that are optimal for the 3D-on-LAN case. Except that that still requires a user to explicitly do something different on the server than they would normally do, and users forget to do that. Maybe there is no way to reconcile the differences between 2D and 3D apps, but we haven't really tried. I've provided tons of data regarding 3D and video app performance, but the equivalent data does not exist for 2D apps, so we really don't know what's best for those apps, and we can't make that judgment just based on gut feelings or quick & dirty benchmarks. We need something more quantifiable. I think we have provided quantifiable data. I agree that additional tests would be useful though, but there are also other things that needs attention. I think the core of the problem is there will always be some kind of tradeoff/compromise, and if I understand the VirtualGL/TurboVNC perspective correctly, there's no interest in this. Anything that, say, increases the CPU, even so little, is a no-no. Given these priorities, it seems difficult to find a solution that fits both use cases by default. This is why I'm suggesting a wrapper script. Assuming that you will no longer ship the file /opt/TurboVNC/bin/vncserver, users will need to learn another path/command in any case. I don't think 3D users will find it more difficult to learn to run, say, /opt/TigerVNC/bin/vncserver-vgl than /opt/TigerVNC/bin/vncserver, at least not much more difficult. Btw, wrt the latency work, we have done extensive testing, and it turns out that Pierres work gives a huge improvement. Common usage cases such as writing text in OpenOffice is now much faster on high latency links. The typing "lag" is basically gone. I don't know about that-- I certainly still see a lag when typing (I mean, latency is still latency, and the time between typing a character on the screen and seeing it on your client is still equal to RTT), but the extensions have definitely eliminated the latency-dependent update rate cap. The extensions allow you to now "type ahead" of the latency, which makes it less apparent, but I can still feel it on a 200 ms connection. Of course you can never get rid of the RTT latency; that's why I said "basically gone". What is the status of getting the extensions "officially" adopted as part of the RFB spec? As far as I can tell, all extensions have official numbers. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Cendio preparing for new release
On Thu, Dec 22, 2011 at 10:59 AM, DRC wrote: > > OK, that's fine by me. I'm not interested in officially going into beta > before January 1, because most people are probably out of the office > this week and next, but we can consider r4825 to be a "soft beta" within > the project. I want to make sure Brian is OK with putting the Java > stuff in beta as well before we go forward with it and branch the code. No Objections here. In fact it's probably a good time since I'm preparing to check in some major changes that have not had extensive testing yet. -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Cendio preparing for new release
On 12/22/11 2:41 AM, Peter Åstrand wrote: > I'll let Pierre give you the details of the -DeferUpdate values, but if > it turns out that it's not possible to find a default that fits > everyone, then I'm suggesting that we create a special script > "turbovncserver", "vglvncserver" or something like that. It can then > have defaults that are optimal for the 3D-on-LAN case. Except that that still requires a user to explicitly do something different on the server than they would normally do, and users forget to do that. Maybe there is no way to reconcile the differences between 2D and 3D apps, but we haven't really tried. I've provided tons of data regarding 3D and video app performance, but the equivalent data does not exist for 2D apps, so we really don't know what's best for those apps, and we can't make that judgment just based on gut feelings or quick & dirty benchmarks. We need something more quantifiable. Ultimately, if TigerVNC decides not to be performant by default for 3D apps, then so be it, but I want that decision to be justified based on solid data. TurboVNC will continue to move forward and focus on peak 3D app performance and 3D-specific features, but my preference would be for people to make the choice of Turbo vs. Tiger based on features and not performance. I really want the solutions to be fully interchangeable, as much as possible. It's really easy for me to document something to the effect of "use TigerVNC with compression level 1 to get TurboVNC-like performance", but as the number of steps required to obtain TurboVNC-like performance increases, it starts getting more and more difficult to document and more prone to user error. The problem with performance issues is that they aren't like hard errors. People will notice a drop in performance, but they won't assume that there is any way to improve it, so you don't really hear about performance issues until you get beaten up in the press. > Btw, wrt the latency work, we have done extensive testing, and it turns > out that Pierres work gives a huge improvement. Common usage cases such > as writing text in OpenOffice is now much faster on high latency links. > The typing "lag" is basically gone. I don't know about that-- I certainly still see a lag when typing (I mean, latency is still latency, and the time between typing a character on the screen and seeing it on your client is still equal to RTT), but the extensions have definitely eliminated the latency-dependent update rate cap. The extensions allow you to now "type ahead" of the latency, which makes it less apparent, but I can still feel it on a 200 ms connection. What is the status of getting the extensions "officially" adopted as part of the RFB spec? -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Cendio preparing for new release
On 12/22/11 3:50 AM, Pierre Ossman wrote: > Testing and preparing for release here has meant that I haven't had > time to look at this properly yet. My current attitude towards it right > now though is that, yes, a regression of the magnitude you're seeing is > not desired and should be fixed. I would like to explore the whole > issue of the deferred updates further though. But there is probably not > time for that right now. So we can change it to 1 ms and get a release > out, and then revisit the issue after the release. OK, that's fine by me. I'm not interested in officially going into beta before January 1, because most people are probably out of the office this week and next, but we can consider r4825 to be a "soft beta" within the project. I want to make sure Brian is OK with putting the Java stuff in beta as well before we go forward with it and branch the code. -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Cendio preparing for new release
On Wed, 21 Dec 2011 10:11:56 -0600 DRC wrote: > I would still like to see a quantifiable test case that demonstrates the > efficacy of setting the deferred update timer to 10 ms. Testing and preparing for release here has meant that I haven't had time to look at this properly yet. My current attitude towards it right now though is that, yes, a regression of the magnitude you're seeing is not desired and should be fixed. I would like to explore the whole issue of the deferred updates further though. But there is probably not time for that right now. So we can change it to 1 ms and get a release out, and then revisit the issue after the release. 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 -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Cendio preparing for new release
On Wed, 21 Dec 2011, DRC wrote: We are currently based on TigerVNC revision 4816, but we might make a new code drop if we find any major bugs. Cool. This is very good info. AFAIC, we could enter beta with the project as well, and probably should so we can leverage your bug squashing. It would be nice to get out some official project builds that contain the performance improvements. Sounds good. Note however that we will likely have a short beta period, since we are aiming for a stable ThinLinc release before the end of the year. I would still like to see a quantifiable test case that demonstrates the efficacy of setting the deferred update timer to 10 ms. Barring that, if you're insistent that 10 is what you want as a default, I would like to modify the build system such that that value can be tweaked using a #define or something like that, so my builds can use 1 ms as the default. It's pretty easy to tell people "if you want TurboVNC-like performance, set the compress level to 1", but telling them that they also have to remember to add -DeferUpdate=1 every time they launch vncserver makes things difficult. I'll let Pierre give you the details of the -DeferUpdate values, but if it turns out that it's not possible to find a default that fits everyone, then I'm suggesting that we create a special script "turbovncserver", "vglvncserver" or something like that. It can then have defaults that are optimal for the 3D-on-LAN case. Btw, wrt the latency work, we have done extensive testing, and it turns out that Pierres work gives a huge improvement. Common usage cases such as writing text in OpenOffice is now much faster on high latency links. The typing "lag" is basically gone. Regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Cendio preparing for new release
On 12/21/11 4:30 AM, Pierre Ossman wrote: > There was a request to let the community know a bit more about what > Cendio is up to with regard to releases. So I'd like to take this > opportunity to mention that we are releasing a beta for our next > release, meaning we are going into pure bug squashing mode now. > > If you'd like to test our build, then send a mail to support at > cendio.com and we'll give you a download link. > > We are currently based on TigerVNC revision 4816, but we might make a > new code drop if we find any major bugs. Cool. This is very good info. AFAIC, we could enter beta with the project as well, and probably should so we can leverage your bug squashing. It would be nice to get out some official project builds that contain the performance improvements. I would still like to see a quantifiable test case that demonstrates the efficacy of setting the deferred update timer to 10 ms. Barring that, if you're insistent that 10 is what you want as a default, I would like to modify the build system such that that value can be tweaked using a #define or something like that, so my builds can use 1 ms as the default. It's pretty easy to tell people "if you want TurboVNC-like performance, set the compress level to 1", but telling them that they also have to remember to add -DeferUpdate=1 every time they launch vncserver makes things difficult. -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
