Hi guys, I am second here for pleading ignorance, so bear with me please. My question as follows: (hope someone from VDI team would put all my ignorance to rest :-) I have quiet powerful 4600 M2 with 256GB of ram and build in ATI graphic adapter serving 50 VM's (mostly Linux, but there are some windows) in a single server configuration. a) Is there any point to upgrade and install top of the range supported nVidia adapter and run it in Multi-GPU FrameRendering or CLI ? b) will it affect VB/srs performance or is it all irrelevant ? I still have the presentation Sun-visualization.ppt from not so distant past. One of the slides had a sample configuration using 4600 M2 and 2 nVidia Model 4 Quadro Plexes with 6GB of total frame buffer. I was wondering if a similar type of configuration could be applicable (Solaris 10 and VDI 3.2) Thanks
On Thursday 02 September 2010 01:07:28 [email protected] wrote: > Send SunRay-Users mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.filibeto.org/mailman/listinfo/sunray-users > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of SunRay-Users digest..." > > > Today's Topics: > > 1. Re: Top 3 of new Sun Ray features (Craig Bender) > 2. Re: Top 3 of new Sun Ray features (Ivar Janmaat) > 3. Re: Top 3 of new Sun Ray features (Wim Coekaerts) > 4. Server Side Graphics Processing (was: Top 3 of new Sun Ray > features) (David Bullock) > 5. Regarding Flash 10 Content (Craig Bender) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 01 Sep 2010 12:57:48 -0700 > From: Craig Bender <[email protected]> > To: SunRay-Users mailing list <[email protected]> > Subject: Re: [SunRay-Users] Top 3 of new Sun Ray features > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Folks, > I apologize if anyone took this to mean we are not pursuing local decode > solutions, or that I was trying to push Ivar away from wanting local > decode. That is neither the case, or my intent. > > I was simply trying was to highlight that while RCA may be more > "expensive" in terms of scalability, it has it's place when usability is > a concern. > > At the very least, RCA buys us time to further develop and enhance our > existing technologies such as direct decode without impacting end user > experience. > > On 9/1/10 10:11 AM, Craig Bender wrote: > > On paper direct decode looks like a better option, and in some cases it > > is indeed the better option. Like: > > > > A purpose built hardware device, or features in an existing devices > > chipset, dedicated to video processing. Typically these only support a > > few formats due to putting codec either in the hardware on in the RTOS. > > Rarely do the codecs in the device support every possible encoding > > option, so even video that is "supported" at the higher level of the > > spec, might not play on device. Codec development takes time, and in > > many cases the vendors of the purpose built device need to license > > technology from 3rd parties even though there is a free (to use) Windows > > codec. The biggest problem with the purpose built device though, is it > > usually does only one thing. And if it does more than one well it > > usually costs as much as a PC, but doesn't exactly replace your PC. > > > > The other would A device that allows the somewhat easy installation of > > readily available codecs. Usually this means windows, but definitely > > means a fat OS. I say somewhat easy installation because things rarely > > just work. You might get prompted to install a codec, you might have to > > manually research what codec is needed. There might not be a codec for > > your OS available, or it might not be free. > > > > Then you take thin clients. They have the problems of the purpose built > > device, with the added the complexity that they really weren't built for > > video. Sure the chipset may have some codec support (usually parts of a > > codec that are "free") but not only do you have to write firmware to > > access the codec and software to stream it down to them, but you have a > > problem with updates to the video format spec itself. They are > > constantly changing and you wind up having to either replace the > > hardware or someone has to start writing software drivers, and > > eventually you have locked down PC. > > > > Just like the Sun Ray "future proofs" the device from desktop (i.e. > > display almost any desktop on the same device), RCA future proofs the > > multimedia from the codec required on the display device. > > > > It may require more processing at the hypervisor layer, or some cases > > the Sun Ray Server layer, and it may not be as efficient bandwidth wise > > as direct decode, but it makes things usable. And at the end of day, > > it's not usable, it's not worth buying. > > > > > > > > > > The problem with purpose built hardware is that > > > > On 9/1/10 8:33 AM, Ivar Janmaat wrote: > >> Hello, > >> > >> The advantage of MMR is that it uses less resources on the server since > >> it is offloading the decoding to the Sun Ray. > >> This will scale better then vrdp. Although not yet tested I suspect MMR > >> will use less bandwidth which would give better performance over WAN. > >> > >> #3 means indeed a separation between the system disk c: and the > >> documents and settings disk d: > >> I used this a lot in implementations with Virtual Bridges since they > >> have had this feature already 10 years ago. > >> I noticed that you can not select this feature if you use LDAP or Novell > >> directory servers. It can only be used in combination with AD. > >> > >> Kind regards, > >> > >> Ivar > >> > >> Wim Coekaerts schreef: > >>> have you tried vdi3.2 with vb as the hypervisor and vrdp ? > >>> > >>> it plays flash just fine for windows xp,7, linux etc > >>> > >>> not sure what #3 means. I guess you mean the new feature in 3.2 where > >>> you can replace only the system disk and keep the user disk. I didn't > >>> realize that didn't work with ldap > >>> > >>>> Number 1: > >>>> Flash 10 content support in MMR on Windows XP. > >>>> > >>>> Number 2: > >>>> MMR support for Windows 7 > >>>> > >>>> Number 3: > >>>> Personal data disk for other directories than AD. > >>>> > >>>> I hope this helps to give some direction for future development. > >>>> > >>>> Kind regards, > >>>> > >>>> Ivar Janmaat > >>>> _______________________________________________ > >>>> SunRay-Users mailing list > >>>> [email protected] > >>>> http://www.filibeto.org/mailman/listinfo/sunray-users > >>> > >>> _______________________________________________ > >>> SunRay-Users mailing list > >>> [email protected] > >>> http://www.filibeto.org/mailman/listinfo/sunray-users > >> > >> _______________________________________________ > >> SunRay-Users mailing list > >> [email protected] > >> http://www.filibeto.org/mailman/listinfo/sunray-users > > > > _______________________________________________ > > SunRay-Users mailing list > > [email protected] > > http://www.filibeto.org/mailman/listinfo/sunray-users > > ------------------------------ > > Message: 2 > Date: Thu, 02 Sep 2010 00:13:17 +0200 > From: Ivar Janmaat <[email protected]> > To: SunRay-Users mailing list <[email protected]> > Subject: Re: [SunRay-Users] Top 3 of new Sun Ray features > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello Craig, > > I appreciate your input! > > A few years ago my opinion on the implementation of MMR was rather > negative because in my opinion the ultimate ultra thin client should > only handle generic codecs not specific Flash and MS codecs of a > specific version. The RCA method is much more in line with my thoughts > on how the ultimate ultra thin client should operate. You definitely > don't want to end up with an obese client stuffed with all sorts of codecs. > > So I like the Virtualbox - RCA - Sun Ray combination. Since Virtualbox > supports 3D acceleration, this combination can be very strong. > (I would like to see some sizing figures on the 3D acceleration though) > > At this time however the VM market is still dominated by VMWare and KVM > type VDI solutions which come with all sorts of application management > tools. > If you want to position the Sun Ray as a client for those VDI > infrastructures, you need something else than vrdp (RCA). > This is where MMR kicks in. Other options are also possible like pcoip > or spice. I have discussed those before. > The problem with MMR is that it is badly crippled since there is no > Flash 10 content support at this time. > It would be a good idea to put Flash 10 content support in MMR before > Flash 11 arrives. > Then the Sun Ray would also be a good client for current VDI locations > where they don't use Virtualbox. > > So eventually it is not only a technical choice. It is also a choice > between selling Sun Rays solely with Virtualbox or selling it also with > other VM solutions. > I think the broker function of the Sun Ray is unique in the market. So I > would favor superb connection protocols to all VM/VDI solutions. This > would enhance the broker function even further and lift the product > above other offerings in the market. That is why I asked to fix the > crippled MMR functionality by supporting Flash 10. > > If Oracle however does not fix the MMR then I need to conclude that > Oracle has already decided to sell Sun Rays only with Virtualbox. > That would limit the broker function of the Sun Ray server which > basically means that the solution will become the same as all other > solutions in the market. > With head to head competition it will than be much harder to build large > volume Sun Ray sales. > > Kind regards, > > Ivar Janmaat > > Craig Bender schreef: > > Folks, > > I apologize if anyone took this to mean we are not pursuing local > > decode solutions, or that I was trying to push Ivar away from wanting > > local decode. That is neither the case, or my intent. > > > > I was simply trying was to highlight that while RCA may be more > > "expensive" in terms of scalability, it has it's place when usability > > is a concern. > > > > At the very least, RCA buys us time to further develop and enhance our > > existing technologies such as direct decode without impacting end user > > experience. > > > > On 9/1/10 10:11 AM, Craig Bender wrote: > >> On paper direct decode looks like a better option, and in some cases it > >> is indeed the better option. Like: > >> > >> A purpose built hardware device, or features in an existing devices > >> chipset, dedicated to video processing. Typically these only support a > >> few formats due to putting codec either in the hardware on in the RTOS. > >> Rarely do the codecs in the device support every possible encoding > >> option, so even video that is "supported" at the higher level of the > >> spec, might not play on device. Codec development takes time, and in > >> many cases the vendors of the purpose built device need to license > >> technology from 3rd parties even though there is a free (to use) Windows > >> codec. The biggest problem with the purpose built device though, is it > >> usually does only one thing. And if it does more than one well it > >> usually costs as much as a PC, but doesn't exactly replace your PC. > >> > >> The other would A device that allows the somewhat easy installation of > >> readily available codecs. Usually this means windows, but definitely > >> means a fat OS. I say somewhat easy installation because things rarely > >> just work. You might get prompted to install a codec, you might have to > >> manually research what codec is needed. There might not be a codec for > >> your OS available, or it might not be free. > >> > >> Then you take thin clients. They have the problems of the purpose built > >> device, with the added the complexity that they really weren't built for > >> video. Sure the chipset may have some codec support (usually parts of a > >> codec that are "free") but not only do you have to write firmware to > >> access the codec and software to stream it down to them, but you have a > >> problem with updates to the video format spec itself. They are > >> constantly changing and you wind up having to either replace the > >> hardware or someone has to start writing software drivers, and > >> eventually you have locked down PC. > >> > >> Just like the Sun Ray "future proofs" the device from desktop (i.e. > >> display almost any desktop on the same device), RCA future proofs the > >> multimedia from the codec required on the display device. > >> > >> It may require more processing at the hypervisor layer, or some cases > >> the Sun Ray Server layer, and it may not be as efficient bandwidth wise > >> as direct decode, but it makes things usable. And at the end of day, > >> it's not usable, it's not worth buying. > >> > >> > >> > >> > >> The problem with purpose built hardware is that > > ------------------------------ > > Message: 3 > Date: Wed, 01 Sep 2010 16:07:40 -0700 > From: Wim Coekaerts <[email protected]> > To: [email protected] > Subject: Re: [SunRay-Users] Top 3 of new Sun Ray features > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > we are improving that as well... (rdp rdp7 rca etc) > > I would agree with your vmware comment but seriously disagree with the > kvm/spice stuff. that's still no where and I can tell you that there is > no interest there. > > On 09/01/2010 03:13 PM, Ivar Janmaat wrote: > > Hello Craig, > > > > I appreciate your input! > > > > A few years ago my opinion on the implementation of MMR was rather > > negative because in my opinion the ultimate ultra thin client should > > only handle generic codecs not specific Flash and MS codecs of a > > specific version. The RCA method is much more in line with my thoughts > > on how the ultimate ultra thin client should operate. You definitely > > don't want to end up with an obese client stuffed with all sorts of > > codecs. > > > > So I like the Virtualbox - RCA - Sun Ray combination. Since > > Virtualbox supports 3D acceleration, this combination can be very strong. > > (I would like to see some sizing figures on the 3D acceleration though) > > > > At this time however the VM market is still dominated by VMWare and > > KVM type VDI solutions which come with all sorts of application > > management tools. > > If you want to position the Sun Ray as a client for those VDI > > infrastructures, you need something else than vrdp (RCA). > > This is where MMR kicks in. Other options are also possible like pcoip > > or spice. I have discussed those before. > > The problem with MMR is that it is badly crippled since there is no > > Flash 10 content support at this time. > > It would be a good idea to put Flash 10 content support in MMR before > > Flash 11 arrives. > > Then the Sun Ray would also be a good client for current VDI locations > > where they don't use Virtualbox. > > > > So eventually it is not only a technical choice. It is also a choice > > between selling Sun Rays solely with Virtualbox or selling it also > > with other VM solutions. > > I think the broker function of the Sun Ray is unique in the market. So > > I would favor superb connection protocols to all VM/VDI solutions. > > This would enhance the broker function even further and lift the > > product above other offerings in the market. That is why I asked to > > fix the crippled MMR functionality by supporting Flash 10. > > > > If Oracle however does not fix the MMR then I need to conclude that > > Oracle has already decided to sell Sun Rays only with Virtualbox. > > That would limit the broker function of the Sun Ray server which > > basically means that the solution will become the same as all other > > solutions in the market. > > With head to head competition it will than be much harder to build > > large volume Sun Ray sales. > > > > Kind regards, > > > > Ivar Janmaat > > > > Craig Bender schreef: > >> Folks, > >> I apologize if anyone took this to mean we are not pursuing local > >> decode solutions, or that I was trying to push Ivar away from wanting > >> local decode. That is neither the case, or my intent. > >> > >> I was simply trying was to highlight that while RCA may be more > >> "expensive" in terms of scalability, it has it's place when usability > >> is a concern. > >> > >> At the very least, RCA buys us time to further develop and enhance > >> our existing technologies such as direct decode without impacting end > >> user experience. > >> > >> On 9/1/10 10:11 AM, Craig Bender wrote: > >>> On paper direct decode looks like a better option, and in some cases it > >>> is indeed the better option. Like: > >>> > >>> A purpose built hardware device, or features in an existing devices > >>> chipset, dedicated to video processing. Typically these only support a > >>> few formats due to putting codec either in the hardware on in the RTOS. > >>> Rarely do the codecs in the device support every possible encoding > >>> option, so even video that is "supported" at the higher level of the > >>> spec, might not play on device. Codec development takes time, and in > >>> many cases the vendors of the purpose built device need to license > >>> technology from 3rd parties even though there is a free (to use) > >>> Windows > >>> codec. The biggest problem with the purpose built device though, is it > >>> usually does only one thing. And if it does more than one well it > >>> usually costs as much as a PC, but doesn't exactly replace your PC. > >>> > >>> The other would A device that allows the somewhat easy installation of > >>> readily available codecs. Usually this means windows, but definitely > >>> means a fat OS. I say somewhat easy installation because things rarely > >>> just work. You might get prompted to install a codec, you might have to > >>> manually research what codec is needed. There might not be a codec for > >>> your OS available, or it might not be free. > >>> > >>> Then you take thin clients. They have the problems of the purpose built > >>> device, with the added the complexity that they really weren't built > >>> for > >>> video. Sure the chipset may have some codec support (usually parts of a > >>> codec that are "free") but not only do you have to write firmware to > >>> access the codec and software to stream it down to them, but you have a > >>> problem with updates to the video format spec itself. They are > >>> constantly changing and you wind up having to either replace the > >>> hardware or someone has to start writing software drivers, and > >>> eventually you have locked down PC. > >>> > >>> Just like the Sun Ray "future proofs" the device from desktop (i.e. > >>> display almost any desktop on the same device), RCA future proofs the > >>> multimedia from the codec required on the display device. > >>> > >>> It may require more processing at the hypervisor layer, or some cases > >>> the Sun Ray Server layer, and it may not be as efficient bandwidth wise > >>> as direct decode, but it makes things usable. And at the end of day, > >>> it's not usable, it's not worth buying. > >>> > >>> > >>> > >>> > >>> The problem with purpose built hardware is that > > > > _______________________________________________ > > SunRay-Users mailing list > > [email protected] > > http://www.filibeto.org/mailman/listinfo/sunray-users > > ------------------------------ > > Message: 4 > Date: Thu, 2 Sep 2010 09:53:27 +1000 > From: David Bullock <[email protected]> > To: SunRay-Users mailing list <[email protected]> > Subject: [SunRay-Users] Server Side Graphics Processing (was: Top 3 of > new Sun Ray features) > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > Craig Bender wrote that decoding video under some scenarios may require: > > processing at the hypervisor layer, or some cases the Sun Ray Server layer, > > > Just to parade my general ignorance on such things, when the hypervisor/SRS > is compositing screen updates (or decoding video) for its myriad clients, > is there any benefit from throwing extra graphics cards/GPU's at the > server? Or is this not a bottleneck in practice? > > thanks, > David. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://www.filibeto.org/pipermail/sunray-users/attachments/20100902/e69b4 > b37/attachment-0001.html> > > ------------------------------ > > Message: 5 > Date: Wed, 01 Sep 2010 17:06:30 -0700 > From: Craig Bender <[email protected]> > To: SunRay-Users mailing list <[email protected]> > Subject: [SunRay-Users] Regarding Flash 10 Content > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 9/1/10 3:13 PM, Ivar Janmaat wrote: > > The problem with MMR is that it is badly crippled since there is no > > Flash 10 content support at this time. > > It would be a good idea to put Flash 10 content support in MMR before > > Flash 11 arrives. > > I'm not sure I've covered this before or not, but previous discussions > concerning our lack of support for Flash v10 content, or perhaps better > stated, the versions of Flash content (v8, v9) that we state support > for, may be painting our ability to handle Flash v10 content with a bit > too broad of a brush. Perhaps we need state we support Flash v10 > content with a footnote based on the following. > > In short there are two "New modes" that Flash can use to push content to > the screen. These are in *addition* to the three that have been > available in the past, and are still the most widely used methods. > > The first is called "Direct" with uses DirectDraw and Direct3D on > Windows platforms, and OpenGL on Linux and OSX. > > The second is called "gpu" and does full fledged compositing using, you > guessed it, the gpu on the client. > > While that does indeed seem like scary stuff, I believe our fear of this > feature would seem to be more theoretical than based on reality. > > Most Flash content developers don't seem to be using it, unless they are > developing a solution based around specific hardware, and not for what I > would say "normal consumption". Suppose you had a flash front end to > your bank. While they may be comfortable to tell you to install Flash, > I think the Last thing they would want would be to tell people to update > to the latest Direct3D driver or OpenGL. > > I'm sure there is some direct mode stuff out there, but I still can't > find an example of any GPU accelerated Flash content "in the wild". > > I think most of the issues people are seeing with our Flash solution are > because of the size limitation, which is something we are addressing. > Granted 1024x768 is a fairly small area, and we've all seen more than > our fair share of out of control Flash based sites (http://www.sobe.com/ > for instance. > > More info here on the two new modes from an engineer from Adobe, a bit > dated, but explains the features. > > http://www.kaourantin.net/2008/05/what-does-gpu-acceleration-mean.html > > Finally, our Flash solution is pretty the same at a higher level as RCA. > Both use motion jpeg. We don't have a "Flash" codec in the the Sun Ray, > so it's not "MMR", or at least it's not local decode of Flash content. > > I believe by the time you actually see Direct or GPU mode as a standard > or normal way of writing Flash based content (if HTML5 doesn't kill > Flash), we should have a solution. > > > > > ------------------------------ > > _______________________________________________ > SunRay-Users mailing list > [email protected] > http://www.filibeto.org/mailman/listinfo/sunray-users > > > End of SunRay-Users Digest, Vol 80, Issue 3 > ******************************************* > -- ======================================= Alex Brulo Senior Server Engineer (HPC) Information Systems Aston (ISA) Aston University, Aston Triangle, Birmingham, B4 7ET Tel: 0121 204 3673 ISA "Aiming for Excellence in ICT Services" ======================================= Please consider the environment before printing this e-mail ======================================= _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
