Re: [Opensim-dev] oddities with asset storage
Ryan McDougall wrote: > In a non-SL context, that asset storage is ameliorated over a > distributed asset system, whether it be P2P, or my own local asset > server. > > There is a ceiling on the growth of asset copies: any given avatar has > a fixed number of things to wear, a region a fixed number of things to > display, or a human a fixed number of things they can effectively > manage in an inventory. > > If you factor in nose-diving hardware costs per gigabyte, and > distributed placement of that storage, the picture doesn't remain > quite as clear as before. > > My point is: if OpenSim is interested in out growing SL, they may need > to take a look at how one might theoretically handle various > non-traditional caching schemes. agree. it's just not as clear cut as it seems when looking at it from the ship... -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] oddities with asset storage
Dirk Krause wrote:
> Glad you asked :-).
>
> I would do a mixture of the following (and admit that I didn't think it all
> through to the very end).
>
> - introduce grid wide, region wide and personal (user) asset domains
> - introduce quotas for these
> - allow clones ('byref') assets, and copies that go into one of the domains,
> resp.
>
> I then would expect to have grid wide assets that are 'always on', region
> wide assets that only are important when the region is connected, and
> personal assets that are only visible when the user is online (could even be
> an FTP server behind a cable beach server).
>
> It boils down to: if someone treasures something, she better keeps it in her
> treasure chest, in her responsibility (and maintenance cost).
>
ok. so i now buy something in your region, take it with me, rezz it on my
region. how would that work and how would that address your concerns? oh, and my
region is rather volatile, it might be there one moment, it might be off-line
the next.
DrS/dirk
--
dr dirk husemann virtual worlds research ibm zurich research lab
SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OpenSim Hardware Requeriments
On Thu, Feb 19, 2009 at 05:23:04AM +, Melanie wrote: > You can't currently hard-limit anything. We have seen 20+ avatars in > regions with 6000+ prims on less memory than that. Was that Mono, or .Net? > Generally, avatars take more memory than prims. -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OpenSim Hardware Requeriments
On Thu, Feb 19, 2009 at 03:46:58AM +, Melanie wrote: > As a rule of thumb, 256MB per sim is an operative minimum, but mono > really likes to see 1GB per region to be happy. > > Some people use VPS to run OpenSim in, I don't recommend that,though. Depends on the virtualization technology. Linux VServer seems to do fine. -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OpenSim Hardware Requeriments
Hi Geetika, Also sprach Geetika S (geetik...@tcs.com): > I wonder if anyone has tried composing multiple streams into a single > stream like a grid of videos and streaming that to the client. Would > introduce a slightly greater lag but then everyone would be at the same > lag. We have done that for slideshows on ZKM in Second Life. Sequences of Jpegs were composed with imagemagick, encoded into MJpeg and MP4 for streaming, with a slow framerate of 1fps or so. If you want to stream "real" video with higher framerates, you could probably try to compose the (4) videos on a screen and framegrab the composed signal from there. There are also video mixing cards with several inputs, but these are expensive. Cheers, Torrid -- "Ich wünsche mir das Lied 'Frogger' von der Gruppe 'Atari'." -- Fischmob ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OpenSim Hardware Requeriments
I wonder if anyone has tried composing multiple streams into a single stream like a grid of videos and streaming that to the client. Would introduce a slightly greater lag but then everyone would be at the same lag. Geetika Sharma opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 11:55:51 AM: > Buckaroo Mu > Sent by: opensim-dev-boun...@lists.berlios.de > > 02/19/2009 11:55 AM > > Please respond to > opensim-dev@lists.berlios.de > > To > > opensim-dev@lists.berlios.de > > cc > > Subject > > Re: [Opensim-dev] OpenSim Hardware Requeriments > > Dirk Krause wrote: > > But I don't know if the client can display multiple streams, or > whether it just plays the stream of the very parcel you stand in. > > > > > The client will only show the stream that is associated with the parcel > you currently occupy. If you have the same media texture for all > parcels, it will show on every prim with that texture - so a region > split into 20 parcels, each with identical screens but different media > streams, would show 20 identical streams - one per screen - changing all > of them as you move from parcel to parcel. > > Indeed I would expect that > > - the number of concurrent streams is limited by the clients connection > > - the client probably will have problems displaying more than say > 3 streams (wild guess) > > > > Just open several streams in a browser and you will find the > practical limit. > > > > -Ursprüngliche Nachricht- > > Von: opensim-dev-boun...@lists.berlios.de im Auftrag von Geetika S > > Gesendet: Do 19.02.2009 07:04 > > An: opensim-dev@lists.berlios.de > > Betreff: Re: [Opensim-dev] OpenSim Hardware Requeriments > > > > Thanks Dirk. But how does one do multiple simultaneous streams cause the > > media url can point to only one address? Also, would multiple simultaneous > > streams slow down the client? > > > > Geetika Sharma > > > > opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 11:22:27 AM: > > > > > >> "Dirk Krause" > >> Sent by: opensim-dev-boun...@lists.berlios.de > >> > >> 02/19/2009 11:22 AM > >> > >> Please respond to > >> opensim-dev@lists.berlios.de > >> > >> To > >> > >> > >> > >> cc > >> > >> Subject > >> > >> Re: [Opensim-dev] OpenSim Hardware Requeriments > >> > >> > >> Since the display of the media streams are totally unrelated to > >> OpenSim (except invocation and termination), meaning OpenSim only > >> knows the link and the streaming is between the viewer and the > >> streaming server, it shouldn't affect the avatar limit at all, esp > >> when the streaming server is on a different machine. > >> > >> -Ursprüngliche Nachricht- > >> Von: opensim-dev-boun...@lists.berlios.de im Auftrag von Geetika S > >> Gesendet: Do 19.02.2009 06:41 > >> An: opensim-dev@lists.berlios.de > >> Cc: opensim-dev@lists.berlios.de; opensim-dev-boun...@lists.berlios.de > >> Betreff: Re: [Opensim-dev] OpenSim Hardware Requeriments > >> > >> Is it possible to do multiple webcam streams in a single region? How does > >> that affect the avatar limit? I want to set it up using Darwin. > >> > >> Thanks > >> > >> Geetika Sharma > >> > >> opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 11:05:09 AM: > >> > >> > >>> Melanie > >>> Sent by: opensim-dev-boun...@lists.berlios.de > >>> > >>> 02/19/2009 11:05 AM > >>> > >>> Please respond to > >>> opensim-dev@lists.berlios.de > >>> > >>> To > >>> > >>> opensim-dev@lists.berlios.de > >>> > >>> cc > >>> > >>> Subject > >>> > >>> Re: [Opensim-dev] OpenSim Hardware Requeriments > >>> > >>> No one has ever gotten there. It has always crashed. > >>> > >>> Melanie > >>> > >>> Geetika S wrote: > >>> > But in any case doing 50+ avatars would be murder, right? > > Geetika Sharma > > opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 10:53:04 AM: > > > > Melanie > > Sent by: opensim-dev-boun...@lists.berlios.de > > > > 02/19/2009 10:53 AM > > > > Please respond to > > opensim-dev@lists.berlios.de > > > > To > > > > opensim-dev@lists.berlios.de > > > > cc > > > > Subject > > > > Re: [Opensim-dev] OpenSim Hardware Requeriments > > > > You can't currently hard-limit anything. We have seen 20+ avatars in > > regions with 6000+ prims on less memory than that. > > Generally, avatars take more memory than prims. > > > > Melanie > > > > Geetika S wrote: > > > >> Hi > >> > >> If you do provide 1GB per region, what limits does one need to > >> > >> impose > >> > on > > >> number of avatars, scripts objects etc.? > >> > >> Thanks > >> > >> Geetika Sharma > >> > >> opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 09:52:30 > >> > >> AM: > >> > >>> Dahlia Trimble > >>> Sent by: opensim-dev-boun...@lists.berlios.de > >>> > >>> 02/19/2009 09:52 AM > >>> > >>> Please respond to > >>> opensim-dev@lists.berlios.de > >>
Re: [Opensim-dev] OpenSim Hardware Requeriments
Dirk Krause wrote: > But I don't know if the client can display multiple streams, or whether it > just plays the stream of the very parcel you stand in. > > The client will only show the stream that is associated with the parcel you currently occupy. If you have the same media texture for all parcels, it will show on every prim with that texture - so a region split into 20 parcels, each with identical screens but different media streams, would show 20 identical streams - one per screen - changing all of them as you move from parcel to parcel. > Indeed I would expect that > - the number of concurrent streams is limited by the clients connection > - the client probably will have problems displaying more than say 3 streams > (wild guess) > > Just open several streams in a browser and you will find the practical limit. > > -Ursprüngliche Nachricht- > Von: opensim-dev-boun...@lists.berlios.de im Auftrag von Geetika S > Gesendet: Do 19.02.2009 07:04 > An: opensim-dev@lists.berlios.de > Betreff: Re: [Opensim-dev] OpenSim Hardware Requeriments > > Thanks Dirk. But how does one do multiple simultaneous streams cause the > media url can point to only one address? Also, would multiple simultaneous > streams slow down the client? > > Geetika Sharma > > opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 11:22:27 AM: > > >> "Dirk Krause" >> Sent by: opensim-dev-boun...@lists.berlios.de >> >> 02/19/2009 11:22 AM >> >> Please respond to >> opensim-dev@lists.berlios.de >> >> To >> >> >> >> cc >> >> Subject >> >> Re: [Opensim-dev] OpenSim Hardware Requeriments >> >> >> Since the display of the media streams are totally unrelated to >> OpenSim (except invocation and termination), meaning OpenSim only >> knows the link and the streaming is between the viewer and the >> streaming server, it shouldn't affect the avatar limit at all, esp >> when the streaming server is on a different machine. >> >> -Ursprüngliche Nachricht- >> Von: opensim-dev-boun...@lists.berlios.de im Auftrag von Geetika S >> Gesendet: Do 19.02.2009 06:41 >> An: opensim-dev@lists.berlios.de >> Cc: opensim-dev@lists.berlios.de; opensim-dev-boun...@lists.berlios.de >> Betreff: Re: [Opensim-dev] OpenSim Hardware Requeriments >> >> Is it possible to do multiple webcam streams in a single region? How does >> that affect the avatar limit? I want to set it up using Darwin. >> >> Thanks >> >> Geetika Sharma >> >> opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 11:05:09 AM: >> >> >>> Melanie >>> Sent by: opensim-dev-boun...@lists.berlios.de >>> >>> 02/19/2009 11:05 AM >>> >>> Please respond to >>> opensim-dev@lists.berlios.de >>> >>> To >>> >>> opensim-dev@lists.berlios.de >>> >>> cc >>> >>> Subject >>> >>> Re: [Opensim-dev] OpenSim Hardware Requeriments >>> >>> No one has ever gotten there. It has always crashed. >>> >>> Melanie >>> >>> Geetika S wrote: >>> But in any case doing 50+ avatars would be murder, right? Geetika Sharma opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 10:53:04 AM: > Melanie > Sent by: opensim-dev-boun...@lists.berlios.de > > 02/19/2009 10:53 AM > > Please respond to > opensim-dev@lists.berlios.de > > To > > opensim-dev@lists.berlios.de > > cc > > Subject > > Re: [Opensim-dev] OpenSim Hardware Requeriments > > You can't currently hard-limit anything. We have seen 20+ avatars in > regions with 6000+ prims on less memory than that. > Generally, avatars take more memory than prims. > > Melanie > > Geetika S wrote: > >> Hi >> >> If you do provide 1GB per region, what limits does one need to >> >> impose >> on >> number of avatars, scripts objects etc.? >> >> Thanks >> >> Geetika Sharma >> >> opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 09:52:30 >> >> AM: >> >>> Dahlia Trimble >>> Sent by: opensim-dev-boun...@lists.berlios.de >>> >>> 02/19/2009 09:52 AM >>> >>> Please respond to >>> opensim-dev@lists.berlios.de >>> >>> To >>> >>> opensim-dev@lists.berlios.de >>> >>> cc >>> >>> Subject >>> >>> Re: [Opensim-dev] OpenSim Hardware Requeriments >>> >>> It really matters how much memory the region is using. If you >>> > don't > >>> have enough, the system will need to use swap space and that will >>> >> be >> >>> perceived as lag spurts. How much memory you use is dependent on >>> >> how >> >>> many avatars are online, how many prims and how complex they are, >>> and how many scripts are running, among other factors. You can do >>> fine with 512 MB if you control those factors. >>> >>> On Wed, Feb 18, 2009 at 8:17 PM, Bernardo Do
Re: [Opensim-dev] OpenSim Hardware Requeriments
Thanks Dirk and Melanie! Will let you know how my experiments come out. Geetika Sharma opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 11:45:12 AM: > "Dirk Krause" > Sent by: opensim-dev-boun...@lists.berlios.de > > 02/19/2009 11:45 AM > > Please respond to > opensim-dev@lists.berlios.de > > To > > > > cc > > Subject > > Re: [Opensim-dev] OpenSim Hardware Requeriments > > I always had that on my list to try this, but didn't try it yet :-). > > As far as I understood you should be able to divide your region in > parcels. Each parcel can have a different media stream. So what I > wanted to try was to divide one big conference room into N parcels > each with a media stream of the participant. This should work with > N = not too high :-). > > But I don't know if the client can display multiple streams, or > whether it just plays the stream of the very parcel you stand in. > > Indeed I would expect that > - the number of concurrent streams is limited by the clients connection > - the client probably will have problems displaying more than say 3 > streams (wild guess) > > Just open several streams in a browser and you will find the practical limit. > > -Ursprüngliche Nachricht- > Von: opensim-dev-boun...@lists.berlios.de im Auftrag von Geetika S > Gesendet: Do 19.02.2009 07:04 > An: opensim-dev@lists.berlios.de > Betreff: Re: [Opensim-dev] OpenSim Hardware Requeriments > > Thanks Dirk. But how does one do multiple simultaneous streams cause the > media url can point to only one address? Also, would multiple simultaneous > streams slow down the client? > > Geetika Sharma > > opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 11:22:27 AM: > > > "Dirk Krause" > > Sent by: opensim-dev-boun...@lists.berlios.de > > > > 02/19/2009 11:22 AM > > > > Please respond to > > opensim-dev@lists.berlios.de > > > > To > > > > > > > > cc > > > > Subject > > > > Re: [Opensim-dev] OpenSim Hardware Requeriments > > > > > > Since the display of the media streams are totally unrelated to > > OpenSim (except invocation and termination), meaning OpenSim only > > knows the link and the streaming is between the viewer and the > > streaming server, it shouldn't affect the avatar limit at all, esp > > when the streaming server is on a different machine. > > > > -Ursprüngliche Nachricht- > > Von: opensim-dev-boun...@lists.berlios.de im Auftrag von Geetika S > > Gesendet: Do 19.02.2009 06:41 > > An: opensim-dev@lists.berlios.de > > Cc: opensim-dev@lists.berlios.de; opensim-dev-boun...@lists.berlios.de > > Betreff: Re: [Opensim-dev] OpenSim Hardware Requeriments > > > > Is it possible to do multiple webcam streams in a single region? How does > > that affect the avatar limit? I want to set it up using Darwin. > > > > Thanks > > > > Geetika Sharma > > > > opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 11:05:09 AM: > > > > > Melanie > > > Sent by: opensim-dev-boun...@lists.berlios.de > > > > > > 02/19/2009 11:05 AM > > > > > > Please respond to > > > opensim-dev@lists.berlios.de > > > > > > To > > > > > > opensim-dev@lists.berlios.de > > > > > > cc > > > > > > Subject > > > > > > Re: [Opensim-dev] OpenSim Hardware Requeriments > > > > > > No one has ever gotten there. It has always crashed. > > > > > > Melanie > > > > > > Geetika S wrote: > > > > But in any case doing 50+ avatars would be murder, right? > > > > > > > > Geetika Sharma > > > > > > > > opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 10:53:04 AM: > > > > > > > >> Melanie > > > >> Sent by: opensim-dev-boun...@lists.berlios.de > > > >> > > > >> 02/19/2009 10:53 AM > > > >> > > > >> Please respond to > > > >> opensim-dev@lists.berlios.de > > > >> > > > >> To > > > >> > > > >> opensim-dev@lists.berlios.de > > > >> > > > >> cc > > > >> > > > >> Subject > > > >> > > > >> Re: [Opensim-dev] OpenSim Hardware Requeriments > > > >> > > > >> You can't currently hard-limit anything. We have seen 20+ avatars in > > > >> regions with 6000+ prims on less memory than that. > > > >> Generally, avatars take more memory than prims. > > > >> > > > >> Melanie > > > >> > > > >> Geetika S wrote: > > > >> > Hi > > > >> > > > > >> > If you do provide 1GB per region, what limits does one need to > > impose > > > > on > > > >> > number of avatars, scripts objects etc.? > > > >> > > > > >> > Thanks > > > >> > > > > >> > Geetika Sharma > > > >> > > > > >> > opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 09:52:30 > > AM: > > > >> > > > > >> >> Dahlia Trimble > > > >> >> Sent by: opensim-dev-boun...@lists.berlios.de > > > >> >> > > > >> >> 02/19/2009 09:52 AM > > > >> >> > > > >> >> Please respond to > > > >> >> opensim-dev@lists.berlios.de > > > >> >> > > > >> >> To > > > >> >> > > > >> >> opensim-dev@lists.berlios.de > > > >> >> > > > >> >> cc > > > >> >> > > > >> >> Subject > > > >> >> > > > >> >> Re: [Opensim-dev] OpenSim Hardware Requeriments > > > >> >> > > > >> >> It really matters how much memory the region is using. If you > don't > >
Re: [Opensim-dev] OpenSim Hardware Requeriments
I always had that on my list to try this, but didn't try it yet :-). As far as I understood you should be able to divide your region in parcels. Each parcel can have a different media stream. So what I wanted to try was to divide one big conference room into N parcels each with a media stream of the participant. This should work with N = not too high :-). But I don't know if the client can display multiple streams, or whether it just plays the stream of the very parcel you stand in. Indeed I would expect that - the number of concurrent streams is limited by the clients connection - the client probably will have problems displaying more than say 3 streams (wild guess) Just open several streams in a browser and you will find the practical limit. -Ursprüngliche Nachricht- Von: opensim-dev-boun...@lists.berlios.de im Auftrag von Geetika S Gesendet: Do 19.02.2009 07:04 An: opensim-dev@lists.berlios.de Betreff: Re: [Opensim-dev] OpenSim Hardware Requeriments Thanks Dirk. But how does one do multiple simultaneous streams cause the media url can point to only one address? Also, would multiple simultaneous streams slow down the client? Geetika Sharma opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 11:22:27 AM: > "Dirk Krause" > Sent by: opensim-dev-boun...@lists.berlios.de > > 02/19/2009 11:22 AM > > Please respond to > opensim-dev@lists.berlios.de > > To > > > > cc > > Subject > > Re: [Opensim-dev] OpenSim Hardware Requeriments > > > Since the display of the media streams are totally unrelated to > OpenSim (except invocation and termination), meaning OpenSim only > knows the link and the streaming is between the viewer and the > streaming server, it shouldn't affect the avatar limit at all, esp > when the streaming server is on a different machine. > > -Ursprüngliche Nachricht- > Von: opensim-dev-boun...@lists.berlios.de im Auftrag von Geetika S > Gesendet: Do 19.02.2009 06:41 > An: opensim-dev@lists.berlios.de > Cc: opensim-dev@lists.berlios.de; opensim-dev-boun...@lists.berlios.de > Betreff: Re: [Opensim-dev] OpenSim Hardware Requeriments > > Is it possible to do multiple webcam streams in a single region? How does > that affect the avatar limit? I want to set it up using Darwin. > > Thanks > > Geetika Sharma > > opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 11:05:09 AM: > > > Melanie > > Sent by: opensim-dev-boun...@lists.berlios.de > > > > 02/19/2009 11:05 AM > > > > Please respond to > > opensim-dev@lists.berlios.de > > > > To > > > > opensim-dev@lists.berlios.de > > > > cc > > > > Subject > > > > Re: [Opensim-dev] OpenSim Hardware Requeriments > > > > No one has ever gotten there. It has always crashed. > > > > Melanie > > > > Geetika S wrote: > > > But in any case doing 50+ avatars would be murder, right? > > > > > > Geetika Sharma > > > > > > opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 10:53:04 AM: > > > > > >> Melanie > > >> Sent by: opensim-dev-boun...@lists.berlios.de > > >> > > >> 02/19/2009 10:53 AM > > >> > > >> Please respond to > > >> opensim-dev@lists.berlios.de > > >> > > >> To > > >> > > >> opensim-dev@lists.berlios.de > > >> > > >> cc > > >> > > >> Subject > > >> > > >> Re: [Opensim-dev] OpenSim Hardware Requeriments > > >> > > >> You can't currently hard-limit anything. We have seen 20+ avatars in > > >> regions with 6000+ prims on less memory than that. > > >> Generally, avatars take more memory than prims. > > >> > > >> Melanie > > >> > > >> Geetika S wrote: > > >> > Hi > > >> > > > >> > If you do provide 1GB per region, what limits does one need to > impose > > > on > > >> > number of avatars, scripts objects etc.? > > >> > > > >> > Thanks > > >> > > > >> > Geetika Sharma > > >> > > > >> > opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 09:52:30 > AM: > > >> > > > >> >> Dahlia Trimble > > >> >> Sent by: opensim-dev-boun...@lists.berlios.de > > >> >> > > >> >> 02/19/2009 09:52 AM > > >> >> > > >> >> Please respond to > > >> >> opensim-dev@lists.berlios.de > > >> >> > > >> >> To > > >> >> > > >> >> opensim-dev@lists.berlios.de > > >> >> > > >> >> cc > > >> >> > > >> >> Subject > > >> >> > > >> >> Re: [Opensim-dev] OpenSim Hardware Requeriments > > >> >> > > >> >> It really matters how much memory the region is using. If you don't > > >> >> have enough, the system will need to use swap space and that will > be > > >> >> perceived as lag spurts. How much memory you use is dependent on > how > > >> >> many avatars are online, how many prims and how complex they are, > > >> >> and how many scripts are running, among other factors. You can do > > >> >> fine with 512 MB if you control those factors. > > >> > > > >> >> On Wed, Feb 18, 2009 at 8:17 PM, Bernardo Donadio > > > > >> >> > wrote: > > >> >> Thanks for the quick response, but what can happens if i run for > > >> >> example with 512MB? The server will have a high ping or what? > > >> >> Thanks again for all! > > >> >> > > >> >> >As a rule of thumb, 256MB per sim
Re: [Opensim-dev] OpenSim Hardware Requeriments
Thanks Dirk. But how does one do multiple simultaneous streams cause the media url can point to only one address? Also, would multiple simultaneous streams slow down the client? Geetika Sharma opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 11:22:27 AM: > "Dirk Krause" > Sent by: opensim-dev-boun...@lists.berlios.de > > 02/19/2009 11:22 AM > > Please respond to > opensim-dev@lists.berlios.de > > To > > > > cc > > Subject > > Re: [Opensim-dev] OpenSim Hardware Requeriments > > > Since the display of the media streams are totally unrelated to > OpenSim (except invocation and termination), meaning OpenSim only > knows the link and the streaming is between the viewer and the > streaming server, it shouldn't affect the avatar limit at all, esp > when the streaming server is on a different machine. > > -Ursprüngliche Nachricht- > Von: opensim-dev-boun...@lists.berlios.de im Auftrag von Geetika S > Gesendet: Do 19.02.2009 06:41 > An: opensim-dev@lists.berlios.de > Cc: opensim-dev@lists.berlios.de; opensim-dev-boun...@lists.berlios.de > Betreff: Re: [Opensim-dev] OpenSim Hardware Requeriments > > Is it possible to do multiple webcam streams in a single region? How does > that affect the avatar limit? I want to set it up using Darwin. > > Thanks > > Geetika Sharma > > opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 11:05:09 AM: > > > Melanie > > Sent by: opensim-dev-boun...@lists.berlios.de > > > > 02/19/2009 11:05 AM > > > > Please respond to > > opensim-dev@lists.berlios.de > > > > To > > > > opensim-dev@lists.berlios.de > > > > cc > > > > Subject > > > > Re: [Opensim-dev] OpenSim Hardware Requeriments > > > > No one has ever gotten there. It has always crashed. > > > > Melanie > > > > Geetika S wrote: > > > But in any case doing 50+ avatars would be murder, right? > > > > > > Geetika Sharma > > > > > > opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 10:53:04 AM: > > > > > >> Melanie > > >> Sent by: opensim-dev-boun...@lists.berlios.de > > >> > > >> 02/19/2009 10:53 AM > > >> > > >> Please respond to > > >> opensim-dev@lists.berlios.de > > >> > > >> To > > >> > > >> opensim-dev@lists.berlios.de > > >> > > >> cc > > >> > > >> Subject > > >> > > >> Re: [Opensim-dev] OpenSim Hardware Requeriments > > >> > > >> You can't currently hard-limit anything. We have seen 20+ avatars in > > >> regions with 6000+ prims on less memory than that. > > >> Generally, avatars take more memory than prims. > > >> > > >> Melanie > > >> > > >> Geetika S wrote: > > >> > Hi > > >> > > > >> > If you do provide 1GB per region, what limits does one need to > impose > > > on > > >> > number of avatars, scripts objects etc.? > > >> > > > >> > Thanks > > >> > > > >> > Geetika Sharma > > >> > > > >> > opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 09:52:30 > AM: > > >> > > > >> >> Dahlia Trimble > > >> >> Sent by: opensim-dev-boun...@lists.berlios.de > > >> >> > > >> >> 02/19/2009 09:52 AM > > >> >> > > >> >> Please respond to > > >> >> opensim-dev@lists.berlios.de > > >> >> > > >> >> To > > >> >> > > >> >> opensim-dev@lists.berlios.de > > >> >> > > >> >> cc > > >> >> > > >> >> Subject > > >> >> > > >> >> Re: [Opensim-dev] OpenSim Hardware Requeriments > > >> >> > > >> >> It really matters how much memory the region is using. If you don't > > >> >> have enough, the system will need to use swap space and that will > be > > >> >> perceived as lag spurts. How much memory you use is dependent on > how > > >> >> many avatars are online, how many prims and how complex they are, > > >> >> and how many scripts are running, among other factors. You can do > > >> >> fine with 512 MB if you control those factors. > > >> > > > >> >> On Wed, Feb 18, 2009 at 8:17 PM, Bernardo Donadio > > > > >> >> > wrote: > > >> >> Thanks for the quick response, but what can happens if i run for > > >> >> example with 512MB? The server will have a high ping or what? > > >> >> Thanks again for all! > > >> >> > > >> >> >As a rule of thumb, 256MB per sim is an operative minimum, but > mono > > >> >> >really likes to see 1GB per region to be happy. > > >> >> > > > >> >> > > > >> > > > >> >> >2009/2/19 Bernardo Donadio > > >> >> > > > >> >> > Hi! > > >> >> > I'm new on OpenSim and I want to make a server. But I don't know > > >> >> what I will need to do one, for a server with only one 256x256 > > >> >> region, and something about 8~10 users at same time, what I will > need? > > >> >> > The server will run Linux Debian 5.0, probably with an optimized > > >> >> kernel and in a Virtual Machine. > > >> >> > Thanks for all! > > >> >> > > > >> >> > -- > > >> >> > Bernardo Donadio > > >> >> > > >> >> > > >> > > > >> >> -- > > >> >> Bernardo Donadio > > >> >> ___ > > >> >> Opensim-dev mailing list > > >> >> Opensim-dev@lists.berlios.de > > >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev > > >> >> ___ > > >> >> Opensim-dev mailing lis
Re: [Opensim-dev] OpenSim Hardware Requeriments
Since the display of the media streams are totally unrelated to OpenSim (except invocation and termination), meaning OpenSim only knows the link and the streaming is between the viewer and the streaming server, it shouldn't affect the avatar limit at all, esp when the streaming server is on a different machine. -Ursprüngliche Nachricht- Von: opensim-dev-boun...@lists.berlios.de im Auftrag von Geetika S Gesendet: Do 19.02.2009 06:41 An: opensim-dev@lists.berlios.de Cc: opensim-dev@lists.berlios.de; opensim-dev-boun...@lists.berlios.de Betreff: Re: [Opensim-dev] OpenSim Hardware Requeriments Is it possible to do multiple webcam streams in a single region? How does that affect the avatar limit? I want to set it up using Darwin. Thanks Geetika Sharma opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 11:05:09 AM: > Melanie > Sent by: opensim-dev-boun...@lists.berlios.de > > 02/19/2009 11:05 AM > > Please respond to > opensim-dev@lists.berlios.de > > To > > opensim-dev@lists.berlios.de > > cc > > Subject > > Re: [Opensim-dev] OpenSim Hardware Requeriments > > No one has ever gotten there. It has always crashed. > > Melanie > > Geetika S wrote: > > But in any case doing 50+ avatars would be murder, right? > > > > Geetika Sharma > > > > opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 10:53:04 AM: > > > >> Melanie > >> Sent by: opensim-dev-boun...@lists.berlios.de > >> > >> 02/19/2009 10:53 AM > >> > >> Please respond to > >> opensim-dev@lists.berlios.de > >> > >> To > >> > >> opensim-dev@lists.berlios.de > >> > >> cc > >> > >> Subject > >> > >> Re: [Opensim-dev] OpenSim Hardware Requeriments > >> > >> You can't currently hard-limit anything. We have seen 20+ avatars in > >> regions with 6000+ prims on less memory than that. > >> Generally, avatars take more memory than prims. > >> > >> Melanie > >> > >> Geetika S wrote: > >> > Hi > >> > > >> > If you do provide 1GB per region, what limits does one need to impose > > on > >> > number of avatars, scripts objects etc.? > >> > > >> > Thanks > >> > > >> > Geetika Sharma > >> > > >> > opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 09:52:30 AM: > >> > > >> >> Dahlia Trimble > >> >> Sent by: opensim-dev-boun...@lists.berlios.de > >> >> > >> >> 02/19/2009 09:52 AM > >> >> > >> >> Please respond to > >> >> opensim-dev@lists.berlios.de > >> >> > >> >> To > >> >> > >> >> opensim-dev@lists.berlios.de > >> >> > >> >> cc > >> >> > >> >> Subject > >> >> > >> >> Re: [Opensim-dev] OpenSim Hardware Requeriments > >> >> > >> >> It really matters how much memory the region is using. If you don't > >> >> have enough, the system will need to use swap space and that will be > >> >> perceived as lag spurts. How much memory you use is dependent on how > >> >> many avatars are online, how many prims and how complex they are, > >> >> and how many scripts are running, among other factors. You can do > >> >> fine with 512 MB if you control those factors. > >> > > >> >> On Wed, Feb 18, 2009 at 8:17 PM, Bernardo Donadio > > >> >> > wrote: > >> >> Thanks for the quick response, but what can happens if i run for > >> >> example with 512MB? The server will have a high ping or what? > >> >> Thanks again for all! > >> >> > >> >> >As a rule of thumb, 256MB per sim is an operative minimum, but mono > >> >> >really likes to see 1GB per region to be happy. > >> >> > > >> >> > > >> > > >> >> >2009/2/19 Bernardo Donadio > >> >> > > >> >> > Hi! > >> >> > I'm new on OpenSim and I want to make a server. But I don't know > >> >> what I will need to do one, for a server with only one 256x256 > >> >> region, and something about 8~10 users at same time, what I will need? > >> >> > The server will run Linux Debian 5.0, probably with an optimized > >> >> kernel and in a Virtual Machine. > >> >> > Thanks for all! > >> >> > > >> >> > -- > >> >> > Bernardo Donadio > >> >> > >> >> > >> > > >> >> -- > >> >> Bernardo Donadio > >> >> ___ > >> >> Opensim-dev mailing list > >> >> Opensim-dev@lists.berlios.de > >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> >> ___ > >> >> Opensim-dev mailing list > >> >> Opensim-dev@lists.berlios.de > >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > >> >> ForwardSourceID:NT5ECE > >> > > >> > =-=-= > >> > Notice: The information contained in this e-mail > >> > message and/or attachments to it may contain > >> > confidential or privileged information. If you are > >> > not the intended recipient, any dissemination, use, > >> > review, distribution, printing or copying of the > >> > information contained in this e-mail message > >> > and/or attachments to it are strictly prohibited. If > >> > you have received this communication in error, > >> > please notify us by reply e-mail or telephone and > >> > immediately and permanently delete the message > >> > and any attachments. Thank you > >> > > >>
Re: [Opensim-dev] OpenSim Hardware Requeriments
Is it possible to do multiple webcam streams in a single region? How does that affect the avatar limit? I want to set it up using Darwin. Thanks Geetika Sharma opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 11:05:09 AM: > Melanie > Sent by: opensim-dev-boun...@lists.berlios.de > > 02/19/2009 11:05 AM > > Please respond to > opensim-dev@lists.berlios.de > > To > > opensim-dev@lists.berlios.de > > cc > > Subject > > Re: [Opensim-dev] OpenSim Hardware Requeriments > > No one has ever gotten there. It has always crashed. > > Melanie > > Geetika S wrote: > > But in any case doing 50+ avatars would be murder, right? > > > > Geetika Sharma > > > > opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 10:53:04 AM: > > > >> Melanie > >> Sent by: opensim-dev-boun...@lists.berlios.de > >> > >> 02/19/2009 10:53 AM > >> > >> Please respond to > >> opensim-dev@lists.berlios.de > >> > >> To > >> > >> opensim-dev@lists.berlios.de > >> > >> cc > >> > >> Subject > >> > >> Re: [Opensim-dev] OpenSim Hardware Requeriments > >> > >> You can't currently hard-limit anything. We have seen 20+ avatars in > >> regions with 6000+ prims on less memory than that. > >> Generally, avatars take more memory than prims. > >> > >> Melanie > >> > >> Geetika S wrote: > >> > Hi > >> > > >> > If you do provide 1GB per region, what limits does one need to impose > > on > >> > number of avatars, scripts objects etc.? > >> > > >> > Thanks > >> > > >> > Geetika Sharma > >> > > >> > opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 09:52:30 AM: > >> > > >> >> Dahlia Trimble > >> >> Sent by: opensim-dev-boun...@lists.berlios.de > >> >> > >> >> 02/19/2009 09:52 AM > >> >> > >> >> Please respond to > >> >> opensim-dev@lists.berlios.de > >> >> > >> >> To > >> >> > >> >> opensim-dev@lists.berlios.de > >> >> > >> >> cc > >> >> > >> >> Subject > >> >> > >> >> Re: [Opensim-dev] OpenSim Hardware Requeriments > >> >> > >> >> It really matters how much memory the region is using. If you don't > >> >> have enough, the system will need to use swap space and that will be > >> >> perceived as lag spurts. How much memory you use is dependent on how > >> >> many avatars are online, how many prims and how complex they are, > >> >> and how many scripts are running, among other factors. You can do > >> >> fine with 512 MB if you control those factors. > >> > > >> >> On Wed, Feb 18, 2009 at 8:17 PM, Bernardo Donadio > > >> >> > wrote: > >> >> Thanks for the quick response, but what can happens if i run for > >> >> example with 512MB? The server will have a high ping or what? > >> >> Thanks again for all! > >> >> > >> >> >As a rule of thumb, 256MB per sim is an operative minimum, but mono > >> >> >really likes to see 1GB per region to be happy. > >> >> > > >> >> > > >> > > >> >> >2009/2/19 Bernardo Donadio > >> >> > > >> >> > Hi! > >> >> > I'm new on OpenSim and I want to make a server. But I don't know > >> >> what I will need to do one, for a server with only one 256x256 > >> >> region, and something about 8~10 users at same time, what I will need? > >> >> > The server will run Linux Debian 5.0, probably with an optimized > >> >> kernel and in a Virtual Machine. > >> >> > Thanks for all! > >> >> > > >> >> > -- > >> >> > Bernardo Donadio > >> >> > >> >> > >> > > >> >> -- > >> >> Bernardo Donadio > >> >> ___ > >> >> Opensim-dev mailing list > >> >> Opensim-dev@lists.berlios.de > >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> >> ___ > >> >> Opensim-dev mailing list > >> >> Opensim-dev@lists.berlios.de > >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > >> >> ForwardSourceID:NT5ECE > >> > > >> > =-=-= > >> > Notice: The information contained in this e-mail > >> > message and/or attachments to it may contain > >> > confidential or privileged information. If you are > >> > not the intended recipient, any dissemination, use, > >> > review, distribution, printing or copying of the > >> > information contained in this e-mail message > >> > and/or attachments to it are strictly prohibited. If > >> > you have received this communication in error, > >> > please notify us by reply e-mail or telephone and > >> > immediately and permanently delete the message > >> > and any attachments. Thank you > >> > > >> > > >> > > >> > ___ > >> > Opensim-dev mailing list > >> > Opensim-dev@lists.berlios.de > >> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > >> > > >> ___ > >> Opensim-dev mailing list > >> Opensim-dev@lists.berlios.de > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > > > >> ForwardSourceID:NT5F0E > > > > =-=-= > > Notice: The information contained in this e-mail > > message and/or attachments to it may contain > > confidential or privileged information. If you are > >
Re: [Opensim-dev] OpenSim Hardware Requeriments
Ok, and the 150Kbps that you said was of UpStream (from server to client) ou DownStream (from client to server)? Thanks! 2009/2/19 Melanie : > No one has ever gotten there. It has always crashed. > > Melanie > > Geetika S wrote: >> But in any case doing 50+ avatars would be murder, right? >> >> Geetika Sharma >> >> opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 10:53:04 AM: >> >>> Melanie >>> Sent by: opensim-dev-boun...@lists.berlios.de >>> >>> 02/19/2009 10:53 AM >>> >>> Please respond to >>> opensim-dev@lists.berlios.de >>> >>> To >>> >>> opensim-dev@lists.berlios.de >>> >>> cc >>> >>> Subject >>> >>> Re: [Opensim-dev] OpenSim Hardware Requeriments >>> >>> You can't currently hard-limit anything. We have seen 20+ avatars in >>> regions with 6000+ prims on less memory than that. >>> Generally, avatars take more memory than prims. >>> >>> Melanie >>> >>> Geetika S wrote: >>> > Hi >>> > >>> > If you do provide 1GB per region, what limits does one need to impose >> on >>> > number of avatars, scripts objects etc.? >>> > >>> > Thanks >>> > >>> > Geetika Sharma >>> > >>> > opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 09:52:30 AM: >>> > >>> >> Dahlia Trimble >>> >> Sent by: opensim-dev-boun...@lists.berlios.de >>> >> >>> >> 02/19/2009 09:52 AM >>> >> >>> >> Please respond to >>> >> opensim-dev@lists.berlios.de >>> >> >>> >> To >>> >> >>> >> opensim-dev@lists.berlios.de >>> >> >>> >> cc >>> >> >>> >> Subject >>> >> >>> >> Re: [Opensim-dev] OpenSim Hardware Requeriments >>> >> >>> >> It really matters how much memory the region is using. If you don't >>> >> have enough, the system will need to use swap space and that will be >>> >> perceived as lag spurts. How much memory you use is dependent on how >>> >> many avatars are online, how many prims and how complex they are, >>> >> and how many scripts are running, among other factors. You can do >>> >> fine with 512 MB if you control those factors. >>> > >>> >> On Wed, Feb 18, 2009 at 8:17 PM, Bernardo Donadio >> >> >> > wrote: >>> >> Thanks for the quick response, but what can happens if i run for >>> >> example with 512MB? The server will have a high ping or what? >>> >> Thanks again for all! >>> >> >>> >> >As a rule of thumb, 256MB per sim is an operative minimum, but mono >>> >> >really likes to see 1GB per region to be happy. >>> >> > >>> >> > >>> > >>> >> >2009/2/19 Bernardo Donadio >>> >> > >>> >> > Hi! >>> >> > I'm new on OpenSim and I want to make a server. But I don't know >>> >> what I will need to do one, for a server with only one 256x256 >>> >> region, and something about 8~10 users at same time, what I will need? >>> >> > The server will run Linux Debian 5.0, probably with an optimized >>> >> kernel and in a Virtual Machine. >>> >> > Thanks for all! >>> >> > >>> >> > -- >>> >> > Bernardo Donadio >>> >> >>> >> >>> > >>> >> -- >>> >> Bernardo Donadio >>> >> ___ >>> >> Opensim-dev mailing list >>> >> Opensim-dev@lists.berlios.de >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> ___ >>> >> Opensim-dev mailing list >>> >> Opensim-dev@lists.berlios.de >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> > >>> >> ForwardSourceID:NT5ECE >>> > >>> > =-=-= >>> > Notice: The information contained in this e-mail >>> > message and/or attachments to it may contain >>> > confidential or privileged information. If you are >>> > not the intended recipient, any dissemination, use, >>> > review, distribution, printing or copying of the >>> > information contained in this e-mail message >>> > and/or attachments to it are strictly prohibited. If >>> > you have received this communication in error, >>> > please notify us by reply e-mail or telephone and >>> > immediately and permanently delete the message >>> > and any attachments. Thank you >>> > >>> > >>> > >>> > ___ >>> > Opensim-dev mailing list >>> > Opensim-dev@lists.berlios.de >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>> > >>> > >>> ___ >>> Opensim-dev mailing list >>> Opensim-dev@lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>> ForwardSourceID:NT5F0E >> >> =-=-= >> Notice: The information contained in this e-mail >> message and/or attachments to it may contain >> confidential or privileged information. If you are >> not the intended recipient, any dissemination, use, >> review, distribution, printing or copying of the >> information contained in this e-mail message >> and/or attachments to it are strictly prohibited. If >> you have received this communication in error, >> please notify us by reply e-mail or telephone and >> immediately and permanently delete the message >> and any attachments. Thank you >> >> >> >> ___ >> Opensim-dev mailing lis
Re: [Opensim-dev] OpenSim Hardware Requeriments
No one has ever gotten there. It has always crashed. Melanie Geetika S wrote: > But in any case doing 50+ avatars would be murder, right? > > Geetika Sharma > > opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 10:53:04 AM: > >> Melanie >> Sent by: opensim-dev-boun...@lists.berlios.de >> >> 02/19/2009 10:53 AM >> >> Please respond to >> opensim-dev@lists.berlios.de >> >> To >> >> opensim-dev@lists.berlios.de >> >> cc >> >> Subject >> >> Re: [Opensim-dev] OpenSim Hardware Requeriments >> >> You can't currently hard-limit anything. We have seen 20+ avatars in >> regions with 6000+ prims on less memory than that. >> Generally, avatars take more memory than prims. >> >> Melanie >> >> Geetika S wrote: >> > Hi >> > >> > If you do provide 1GB per region, what limits does one need to impose > on >> > number of avatars, scripts objects etc.? >> > >> > Thanks >> > >> > Geetika Sharma >> > >> > opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 09:52:30 AM: >> > >> >> Dahlia Trimble >> >> Sent by: opensim-dev-boun...@lists.berlios.de >> >> >> >> 02/19/2009 09:52 AM >> >> >> >> Please respond to >> >> opensim-dev@lists.berlios.de >> >> >> >> To >> >> >> >> opensim-dev@lists.berlios.de >> >> >> >> cc >> >> >> >> Subject >> >> >> >> Re: [Opensim-dev] OpenSim Hardware Requeriments >> >> >> >> It really matters how much memory the region is using. If you don't >> >> have enough, the system will need to use swap space and that will be >> >> perceived as lag spurts. How much memory you use is dependent on how >> >> many avatars are online, how many prims and how complex they are, >> >> and how many scripts are running, among other factors. You can do >> >> fine with 512 MB if you control those factors. >> > >> >> On Wed, Feb 18, 2009 at 8:17 PM, Bernardo Donadio > > >> > wrote: >> >> Thanks for the quick response, but what can happens if i run for >> >> example with 512MB? The server will have a high ping or what? >> >> Thanks again for all! >> >> >> >> >As a rule of thumb, 256MB per sim is an operative minimum, but mono >> >> >really likes to see 1GB per region to be happy. >> >> > >> >> > >> > >> >> >2009/2/19 Bernardo Donadio >> >> > >> >> > Hi! >> >> > I'm new on OpenSim and I want to make a server. But I don't know >> >> what I will need to do one, for a server with only one 256x256 >> >> region, and something about 8~10 users at same time, what I will need? >> >> > The server will run Linux Debian 5.0, probably with an optimized >> >> kernel and in a Virtual Machine. >> >> > Thanks for all! >> >> > >> >> > -- >> >> > Bernardo Donadio >> >> >> >> >> > >> >> -- >> >> Bernardo Donadio >> >> ___ >> >> Opensim-dev mailing list >> >> Opensim-dev@lists.berlios.de >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> ___ >> >> Opensim-dev mailing list >> >> Opensim-dev@lists.berlios.de >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > >> >> ForwardSourceID:NT5ECE >> > >> > =-=-= >> > Notice: The information contained in this e-mail >> > message and/or attachments to it may contain >> > confidential or privileged information. If you are >> > not the intended recipient, any dissemination, use, >> > review, distribution, printing or copying of the >> > information contained in this e-mail message >> > and/or attachments to it are strictly prohibited. If >> > you have received this communication in error, >> > please notify us by reply e-mail or telephone and >> > immediately and permanently delete the message >> > and any attachments. Thank you >> > >> > >> > >> > ___ >> > Opensim-dev mailing list >> > Opensim-dev@lists.berlios.de >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> > >> > >> ___ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> ForwardSourceID:NT5F0E > > =-=-= > Notice: The information contained in this e-mail > message and/or attachments to it may contain > confidential or privileged information. If you are > not the intended recipient, any dissemination, use, > review, distribution, printing or copying of the > information contained in this e-mail message > and/or attachments to it are strictly prohibited. If > you have received this communication in error, > please notify us by reply e-mail or telephone and > immediately and permanently delete the message > and any attachments. Thank you > > > > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OpenSim Hardware Requeriments
They're kilobit/s and they are UPSTREAM from the region, meaning they are going out to the client. melanie Bernardo Donadio wrote: > Ok, and the 150Kbps (was kilobits, not kilobytes, right?) are of > upload or download? > Thanks! > > 2009/2/19 Melanie : >> You can't currently hard-limit anything. We have seen 20+ avatars in >> regions with 6000+ prims on less memory than that. >> Generally, avatars take more memory than prims. >> >> Melanie >> >> Geetika S wrote: >>> Hi >>> >>> If you do provide 1GB per region, what limits does one need to impose on >>> number of avatars, scripts objects etc.? >>> >>> Thanks >>> >>> Geetika Sharma >>> >>> opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 09:52:30 AM: >>> Dahlia Trimble Sent by: opensim-dev-boun...@lists.berlios.de 02/19/2009 09:52 AM Please respond to opensim-dev@lists.berlios.de To opensim-dev@lists.berlios.de cc Subject Re: [Opensim-dev] OpenSim Hardware Requeriments It really matters how much memory the region is using. If you don't have enough, the system will need to use swap space and that will be perceived as lag spurts. How much memory you use is dependent on how many avatars are online, how many prims and how complex they are, and how many scripts are running, among other factors. You can do fine with 512 MB if you control those factors. >>> On Wed, Feb 18, 2009 at 8:17 PM, Bernardo Donadio >>> > wrote: Thanks for the quick response, but what can happens if i run for example with 512MB? The server will have a high ping or what? Thanks again for all! >As a rule of thumb, 256MB per sim is an operative minimum, but mono >really likes to see 1GB per region to be happy. > > >>> >2009/2/19 Bernardo Donadio > > Hi! > I'm new on OpenSim and I want to make a server. But I don't know what I will need to do one, for a server with only one 256x256 region, and something about 8~10 users at same time, what I will need? > The server will run Linux Debian 5.0, probably with an optimized kernel and in a Virtual Machine. > Thanks for all! > > -- > Bernardo Donadio >>> -- Bernardo Donadio ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev >>> ForwardSourceID:NT5ECE >>> >>> =-=-= >>> Notice: The information contained in this e-mail >>> message and/or attachments to it may contain >>> confidential or privileged information. If you are >>> not the intended recipient, any dissemination, use, >>> review, distribution, printing or copying of the >>> information contained in this e-mail message >>> and/or attachments to it are strictly prohibited. If >>> you have received this communication in error, >>> please notify us by reply e-mail or telephone and >>> immediately and permanently delete the message >>> and any attachments. Thank you >>> >>> >>> >>> ___ >>> Opensim-dev mailing list >>> Opensim-dev@lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >> ___ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OpenSim Hardware Requeriments
But in any case doing 50+ avatars would be murder, right? Geetika Sharma opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 10:53:04 AM: > Melanie > Sent by: opensim-dev-boun...@lists.berlios.de > > 02/19/2009 10:53 AM > > Please respond to > opensim-dev@lists.berlios.de > > To > > opensim-dev@lists.berlios.de > > cc > > Subject > > Re: [Opensim-dev] OpenSim Hardware Requeriments > > You can't currently hard-limit anything. We have seen 20+ avatars in > regions with 6000+ prims on less memory than that. > Generally, avatars take more memory than prims. > > Melanie > > Geetika S wrote: > > Hi > > > > If you do provide 1GB per region, what limits does one need to impose on > > number of avatars, scripts objects etc.? > > > > Thanks > > > > Geetika Sharma > > > > opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 09:52:30 AM: > > > >> Dahlia Trimble > >> Sent by: opensim-dev-boun...@lists.berlios.de > >> > >> 02/19/2009 09:52 AM > >> > >> Please respond to > >> opensim-dev@lists.berlios.de > >> > >> To > >> > >> opensim-dev@lists.berlios.de > >> > >> cc > >> > >> Subject > >> > >> Re: [Opensim-dev] OpenSim Hardware Requeriments > >> > >> It really matters how much memory the region is using. If you don't > >> have enough, the system will need to use swap space and that will be > >> perceived as lag spurts. How much memory you use is dependent on how > >> many avatars are online, how many prims and how complex they are, > >> and how many scripts are running, among other factors. You can do > >> fine with 512 MB if you control those factors. > > > >> On Wed, Feb 18, 2009 at 8:17 PM, Bernardo Donadio >> > wrote: > >> Thanks for the quick response, but what can happens if i run for > >> example with 512MB? The server will have a high ping or what? > >> Thanks again for all! > >> > >> >As a rule of thumb, 256MB per sim is an operative minimum, but mono > >> >really likes to see 1GB per region to be happy. > >> > > >> > > > > >> >2009/2/19 Bernardo Donadio > >> > > >> > Hi! > >> > I'm new on OpenSim and I want to make a server. But I don't know > >> what I will need to do one, for a server with only one 256x256 > >> region, and something about 8~10 users at same time, what I will need? > >> > The server will run Linux Debian 5.0, probably with an optimized > >> kernel and in a Virtual Machine. > >> > Thanks for all! > >> > > >> > -- > >> > Bernardo Donadio > >> > >> > > > >> -- > >> Bernardo Donadio > >> ___ > >> Opensim-dev mailing list > >> Opensim-dev@lists.berlios.de > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> ___ > >> Opensim-dev mailing list > >> Opensim-dev@lists.berlios.de > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > > > >> ForwardSourceID:NT5ECE > > > > =-=-= > > Notice: The information contained in this e-mail > > message and/or attachments to it may contain > > confidential or privileged information. If you are > > not the intended recipient, any dissemination, use, > > review, distribution, printing or copying of the > > information contained in this e-mail message > > and/or attachments to it are strictly prohibited. If > > you have received this communication in error, > > please notify us by reply e-mail or telephone and > > immediately and permanently delete the message > > and any attachments. Thank you > > > > > > > > ___ > > Opensim-dev mailing list > > Opensim-dev@lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > ForwardSourceID:NT5F0E =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OpenSim Hardware Requeriments
Ok, and the 150Kbps (was kilobits, not kilobytes, right?) are of upload or download? Thanks! 2009/2/19 Melanie : > You can't currently hard-limit anything. We have seen 20+ avatars in > regions with 6000+ prims on less memory than that. > Generally, avatars take more memory than prims. > > Melanie > > Geetika S wrote: >> Hi >> >> If you do provide 1GB per region, what limits does one need to impose on >> number of avatars, scripts objects etc.? >> >> Thanks >> >> Geetika Sharma >> >> opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 09:52:30 AM: >> >>> Dahlia Trimble >>> Sent by: opensim-dev-boun...@lists.berlios.de >>> >>> 02/19/2009 09:52 AM >>> >>> Please respond to >>> opensim-dev@lists.berlios.de >>> >>> To >>> >>> opensim-dev@lists.berlios.de >>> >>> cc >>> >>> Subject >>> >>> Re: [Opensim-dev] OpenSim Hardware Requeriments >>> >>> It really matters how much memory the region is using. If you don't >>> have enough, the system will need to use swap space and that will be >>> perceived as lag spurts. How much memory you use is dependent on how >>> many avatars are online, how many prims and how complex they are, >>> and how many scripts are running, among other factors. You can do >>> fine with 512 MB if you control those factors. >> >>> On Wed, Feb 18, 2009 at 8:17 PM, Bernardo Donadio >> > wrote: >>> Thanks for the quick response, but what can happens if i run for >>> example with 512MB? The server will have a high ping or what? >>> Thanks again for all! >>> >>> >As a rule of thumb, 256MB per sim is an operative minimum, but mono >>> >really likes to see 1GB per region to be happy. >>> > >>> > >> >>> >2009/2/19 Bernardo Donadio >>> > >>> > Hi! >>> > I'm new on OpenSim and I want to make a server. But I don't know >>> what I will need to do one, for a server with only one 256x256 >>> region, and something about 8~10 users at same time, what I will need? >>> > The server will run Linux Debian 5.0, probably with an optimized >>> kernel and in a Virtual Machine. >>> > Thanks for all! >>> > >>> > -- >>> > Bernardo Donadio >>> >>> >> >>> -- >>> Bernardo Donadio >>> ___ >>> Opensim-dev mailing list >>> Opensim-dev@lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> ___ >>> Opensim-dev mailing list >>> Opensim-dev@lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>> ForwardSourceID:NT5ECE >> >> =-=-= >> Notice: The information contained in this e-mail >> message and/or attachments to it may contain >> confidential or privileged information. If you are >> not the intended recipient, any dissemination, use, >> review, distribution, printing or copying of the >> information contained in this e-mail message >> and/or attachments to it are strictly prohibited. If >> you have received this communication in error, >> please notify us by reply e-mail or telephone and >> immediately and permanently delete the message >> and any attachments. Thank you >> >> >> >> ___ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- Bernardo Donadio ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OpenSim Hardware Requeriments
You can't currently hard-limit anything. We have seen 20+ avatars in regions with 6000+ prims on less memory than that. Generally, avatars take more memory than prims. Melanie Geetika S wrote: > Hi > > If you do provide 1GB per region, what limits does one need to impose on > number of avatars, scripts objects etc.? > > Thanks > > Geetika Sharma > > opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 09:52:30 AM: > >> Dahlia Trimble >> Sent by: opensim-dev-boun...@lists.berlios.de >> >> 02/19/2009 09:52 AM >> >> Please respond to >> opensim-dev@lists.berlios.de >> >> To >> >> opensim-dev@lists.berlios.de >> >> cc >> >> Subject >> >> Re: [Opensim-dev] OpenSim Hardware Requeriments >> >> It really matters how much memory the region is using. If you don't >> have enough, the system will need to use swap space and that will be >> perceived as lag spurts. How much memory you use is dependent on how >> many avatars are online, how many prims and how complex they are, >> and how many scripts are running, among other factors. You can do >> fine with 512 MB if you control those factors. > >> On Wed, Feb 18, 2009 at 8:17 PM, Bernardo Donadio > > wrote: >> Thanks for the quick response, but what can happens if i run for >> example with 512MB? The server will have a high ping or what? >> Thanks again for all! >> >> >As a rule of thumb, 256MB per sim is an operative minimum, but mono >> >really likes to see 1GB per region to be happy. >> > >> > > >> >2009/2/19 Bernardo Donadio >> > >> > Hi! >> > I'm new on OpenSim and I want to make a server. But I don't know >> what I will need to do one, for a server with only one 256x256 >> region, and something about 8~10 users at same time, what I will need? >> > The server will run Linux Debian 5.0, probably with an optimized >> kernel and in a Virtual Machine. >> > Thanks for all! >> > >> > -- >> > Bernardo Donadio >> >> > >> -- >> Bernardo Donadio >> ___ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> ___ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> ForwardSourceID:NT5ECE > > =-=-= > Notice: The information contained in this e-mail > message and/or attachments to it may contain > confidential or privileged information. If you are > not the intended recipient, any dissemination, use, > review, distribution, printing or copying of the > information contained in this e-mail message > and/or attachments to it are strictly prohibited. If > you have received this communication in error, > please notify us by reply e-mail or telephone and > immediately and permanently delete the message > and any attachments. Thank you > > > > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OpenSim Hardware Requeriments
You can use any voice system _beside_ opensim. No other system provides a Linden viewer plugin, though. Melanie Bernardo Donadio wrote: > And, I was reading that the OpenSim don't work with the built-in SL > voice system. Is that right? And if yes, I can integrate other voice > system, like Mambo (open-source) or Temspeak (proprietary)? > Thanks! > > 2009/2/19 Melanie : >> A rule of thumb is 150KBit/s per client. >> >> Melanie >> >> Bernardo Donadio wrote: >>> Ok, and how much is the utilization of the network? How much 1 client >>> need of bandwidth? >>> Thanks for all and sorry for my bad english :-) >>> >>> 2009/2/19 Dahlia Trimble : It really matters how much memory the region is using. If you don't have enough, the system will need to use swap space and that will be perceived as lag spurts. How much memory you use is dependent on how many avatars are online, how many prims and how complex they are, and how many scripts are running, among other factors. You can do fine with 512 MB if you control those factors. On Wed, Feb 18, 2009 at 8:17 PM, Bernardo Donadio wrote: > > Thanks for the quick response, but what can happens if i run for > example with 512MB? The server will have a high ping or what? > Thanks again for all! > > >As a rule of thumb, 256MB per sim is an operative minimum, but mono > >really likes to see 1GB per region to be happy. > > > > > > >2009/2/19 Bernardo Donadio > > > > Hi! > > I'm new on OpenSim and I want to make a server. But I don't know what I > > will need to do one, for a server with only one 256x256 region, and > > something about 8~10 users at same time, what I will need? > > The server will run Linux Debian 5.0, probably with an optimized kernel > > and in a Virtual Machine. > > Thanks for all! > > > > -- > > Bernardo Donadio > > > > -- > Bernardo Donadio > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >>> >> ___ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OpenSim Hardware Requeriments
Hi If you do provide 1GB per region, what limits does one need to impose on number of avatars, scripts objects etc.? Thanks Geetika Sharma opensim-dev-boun...@lists.berlios.de wrote on 02/19/2009 09:52:30 AM: > Dahlia Trimble > Sent by: opensim-dev-boun...@lists.berlios.de > > 02/19/2009 09:52 AM > > Please respond to > opensim-dev@lists.berlios.de > > To > > opensim-dev@lists.berlios.de > > cc > > Subject > > Re: [Opensim-dev] OpenSim Hardware Requeriments > > It really matters how much memory the region is using. If you don't > have enough, the system will need to use swap space and that will be > perceived as lag spurts. How much memory you use is dependent on how > many avatars are online, how many prims and how complex they are, > and how many scripts are running, among other factors. You can do > fine with 512 MB if you control those factors. > On Wed, Feb 18, 2009 at 8:17 PM, Bernardo Donadio > wrote: > Thanks for the quick response, but what can happens if i run for > example with 512MB? The server will have a high ping or what? > Thanks again for all! > > >As a rule of thumb, 256MB per sim is an operative minimum, but mono > >really likes to see 1GB per region to be happy. > > > > > >2009/2/19 Bernardo Donadio > > > > Hi! > > I'm new on OpenSim and I want to make a server. But I don't know > what I will need to do one, for a server with only one 256x256 > region, and something about 8~10 users at same time, what I will need? > > The server will run Linux Debian 5.0, probably with an optimized > kernel and in a Virtual Machine. > > Thanks for all! > > > > -- > > Bernardo Donadio > > > -- > Bernardo Donadio > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > ForwardSourceID:NT5ECE =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OpenSim Hardware Requeriments
And, I was reading that the OpenSim don't work with the built-in SL voice system. Is that right? And if yes, I can integrate other voice system, like Mambo (open-source) or Temspeak (proprietary)? Thanks! 2009/2/19 Melanie : > A rule of thumb is 150KBit/s per client. > > Melanie > > Bernardo Donadio wrote: >> Ok, and how much is the utilization of the network? How much 1 client >> need of bandwidth? >> Thanks for all and sorry for my bad english :-) >> >> 2009/2/19 Dahlia Trimble : >>> It really matters how much memory the region is using. If you don't have >>> enough, the system will need to use swap space and that will be perceived as >>> lag spurts. How much memory you use is dependent on how many avatars are >>> online, how many prims and how complex they are, and how many scripts are >>> running, among other factors. You can do fine with 512 MB if you control >>> those factors. >>> >>> On Wed, Feb 18, 2009 at 8:17 PM, Bernardo Donadio >>> wrote: Thanks for the quick response, but what can happens if i run for example with 512MB? The server will have a high ping or what? Thanks again for all! >As a rule of thumb, 256MB per sim is an operative minimum, but mono >really likes to see 1GB per region to be happy. > > >2009/2/19 Bernardo Donadio > > Hi! > I'm new on OpenSim and I want to make a server. But I don't know what I > will need to do one, for a server with only one 256x256 region, and > something about 8~10 users at same time, what I will need? > The server will run Linux Debian 5.0, probably with an optimized kernel > and in a Virtual Machine. > Thanks for all! > > -- > Bernardo Donadio -- Bernardo Donadio ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >>> ___ >>> Opensim-dev mailing list >>> Opensim-dev@lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >> >> >> > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- Bernardo Donadio ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OpenSim Hardware Requeriments
A rule of thumb is 150KBit/s per client. Melanie Bernardo Donadio wrote: > Ok, and how much is the utilization of the network? How much 1 client > need of bandwidth? > Thanks for all and sorry for my bad english :-) > > 2009/2/19 Dahlia Trimble : >> It really matters how much memory the region is using. If you don't have >> enough, the system will need to use swap space and that will be perceived as >> lag spurts. How much memory you use is dependent on how many avatars are >> online, how many prims and how complex they are, and how many scripts are >> running, among other factors. You can do fine with 512 MB if you control >> those factors. >> >> On Wed, Feb 18, 2009 at 8:17 PM, Bernardo Donadio >> wrote: >>> >>> Thanks for the quick response, but what can happens if i run for >>> example with 512MB? The server will have a high ping or what? >>> Thanks again for all! >>> >>> >As a rule of thumb, 256MB per sim is an operative minimum, but mono >>> >really likes to see 1GB per region to be happy. >>> > >>> > >>> >>> >2009/2/19 Bernardo Donadio >>> > >>> > Hi! >>> > I'm new on OpenSim and I want to make a server. But I don't know what I >>> > will need to do one, for a server with only one 256x256 region, and >>> > something about 8~10 users at same time, what I will need? >>> > The server will run Linux Debian 5.0, probably with an optimized kernel >>> > and in a Virtual Machine. >>> > Thanks for all! >>> > >>> > -- >>> > Bernardo Donadio >>> >>> >>> >>> -- >>> Bernardo Donadio >>> ___ >>> Opensim-dev mailing list >>> Opensim-dev@lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> ___ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> > > > ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OpenSim Hardware Requeriments
Ok, and how much is the utilization of the network? How much 1 client need of bandwidth? Thanks for all and sorry for my bad english :-) 2009/2/19 Dahlia Trimble : > It really matters how much memory the region is using. If you don't have > enough, the system will need to use swap space and that will be perceived as > lag spurts. How much memory you use is dependent on how many avatars are > online, how many prims and how complex they are, and how many scripts are > running, among other factors. You can do fine with 512 MB if you control > those factors. > > On Wed, Feb 18, 2009 at 8:17 PM, Bernardo Donadio > wrote: >> >> Thanks for the quick response, but what can happens if i run for >> example with 512MB? The server will have a high ping or what? >> Thanks again for all! >> >> >As a rule of thumb, 256MB per sim is an operative minimum, but mono >> >really likes to see 1GB per region to be happy. >> > >> > >> >> >2009/2/19 Bernardo Donadio >> > >> > Hi! >> > I'm new on OpenSim and I want to make a server. But I don't know what I >> > will need to do one, for a server with only one 256x256 region, and >> > something about 8~10 users at same time, what I will need? >> > The server will run Linux Debian 5.0, probably with an optimized kernel >> > and in a Virtual Machine. >> > Thanks for all! >> > >> > -- >> > Bernardo Donadio >> >> >> >> -- >> Bernardo Donadio >> ___ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev > > > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > -- Bernardo Donadio ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OpenSim Hardware Requeriments
It really matters how much memory the region is using. If you don't have enough, the system will need to use swap space and that will be perceived as lag spurts. How much memory you use is dependent on how many avatars are online, how many prims and how complex they are, and how many scripts are running, among other factors. You can do fine with 512 MB if you control those factors. On Wed, Feb 18, 2009 at 8:17 PM, Bernardo Donadio wrote: > Thanks for the quick response, but what can happens if i run for > example with 512MB? The server will have a high ping or what? > Thanks again for all! > > >As a rule of thumb, 256MB per sim is an operative minimum, but mono > >really likes to see 1GB per region to be happy. > > > > > > >2009/2/19 Bernardo Donadio > > > > Hi! > > I'm new on OpenSim and I want to make a server. But I don't know what I > will need to do one, for a server with only one 256x256 region, and > something about 8~10 users at same time, what I will need? > > The server will run Linux Debian 5.0, probably with an optimized kernel > and in a Virtual Machine. > > Thanks for all! > > > > -- > > Bernardo Donadio > > > > -- > Bernardo Donadio > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OpenSim Hardware Requeriments
Thanks for the quick response, but what can happens if i run for example with 512MB? The server will have a high ping or what? Thanks again for all! >As a rule of thumb, 256MB per sim is an operative minimum, but mono >really likes to see 1GB per region to be happy. > > >2009/2/19 Bernardo Donadio > > Hi! > I'm new on OpenSim and I want to make a server. But I don't know what I will > need to do one, for a server with only one 256x256 region, and something > about 8~10 users at same time, what I will need? > The server will run Linux Debian 5.0, probably with an optimized kernel and > in a Virtual Machine. > Thanks for all! > > -- > Bernardo Donadio -- Bernardo Donadio ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OpenSim Hardware Requeriments
As a rule of thumb, 256MB per sim is an operative minimum, but mono really likes to see 1GB per region to be happy. Some people use VPS to run OpenSim in, I don't recommend that,though. Melanie Bernardo Donadio wrote: > Hi! > I'm new on OpenSim and I want to make a server. But I don't know what I will > need to do one, for a server with only one 256x256 region, and something > about 8~10 users at same time, what I will need? > The server will run Linux Debian 5.0, probably with an optimized kernel and > in a Virtual Machine. > Thanks for all! > > > > > > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] OpenSim Hardware Requeriments
Hi! I'm new on OpenSim and I want to make a server. But I don't know what I will need to do one, for a server with only one 256x256 region, and something about 8~10 users at same time, what I will need? The server will run Linux Debian 5.0, probably with an optimized kernel and in a Virtual Machine. Thanks for all! -- Bernardo Donadio ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] oddities with asset storage
Hi,
i proposed a reaping strategy that is both type and time based.
There was no direct response to it, but current development on new
de-duping cable beach plugins may go a long way to curb asset
proliferation and the reaper can be developed on that basis.
Refcounting may be feasible as a positive indication, e.g. to
indicate something is _definitely_ safe to delete, but a reaper will
still be required.
Melanie
Buckaroo Mu wrote:
> Melanie wrote:
>> This is something i have though about. However, it would not work in
>> OSGrid. Regions may go away, and they may go away permanently.
>> Anything in a prim inventory at that time is refcounted and would
>> not be released. Ever.
>>
> In what what in particular would this be worse than the current
> situation? Yes, some assets would end up staying around forever.
> However, unlike the current scheme, some... would not.
>> So, you'd need a ref list, to purge invalid refs. That is where the
>> inpracticability begins. A redf list for each and every asset,
>> listing either avatar UUID or region UUID?
>>
>>
> Eep, no - wasn't considering suggesting this.
>> If assets are 51 mio, how long will the reflist table be?
>>
>> Melanie
>>
>> Buckaroo Mu wrote:
>>
>>> Here's my L$0.02, for what it's worth - why not maintain a 'reference
>>> count' in the asset entry?
>>>
>>> Resident A creates a prim, takes it into inventory. Asset is created,
>>> inventory item pointing to asset is created, asset->useagecount++. User
>>> gives away 15 copies of item, asset->usagecount+=15. Resident A deletes
>>> original item, inventory item goes away, asset->usagecount--.
>>>
>>> Resident B rezzes item on sim. If item is no-copy, asset->usagecount--.
>>> If it's copy, and Resident B (or Resident C) takes it back into
>>> inventory, asset->usagecount++ (they would have two copies of it).
>>> Resident B deletes both copies from inventory, asset->usagecount -=2.
>>>
>>> If asset->usagecount == 0, asset gets deleted.
>>>
>>> Tell me why this wouldn't work. I'm sure there's a simple reason, but I
>>> can't think of it. All of this is assuming that the asset is no-mod -
>>> any change to the asset creates a new UUID, correct? But if the asset is
>>> rezzed, then taken back into inventory, it should have the same UUID,
>>> thus adding one to the usage count.
>>>
>>> -Buckaroo
>>>
>>> Melanie wrote:
>>>
All you described is design behavior.
Prim items in world are not assets. They are stored exclusively in
the prims tables of the region.
Once taken, they become an asset. The name is totally meaningless,
it reflects whatever was the name at creation. Nothing else. It
never changes from there on.
On deleting the inventory item, assets remain. There is no easy or
practicable way to conclusively say that an asset is trash, because
we don't know.
In your test case, your (human) mind could know this for a fact,
however, the silicon mind of the asset server can't.
This is because you may have given the object to another user, or
put a copy into a prim.
These copies would refer to the same asset, that is what "implictily
shared" means.
So, any asset may, at any time, have any number of links to it, even
zero.
Like a website, you don't know who linked to it. If you remove it,
you leave dead links. Assets are the same. Except, you get "Asset
missing from database".
So, assetas are NOT 1-to-1 with inventory items, and they _never_
get deleted.
They have to be reaped, and there is a big discussion over how to
best do that, running right now.
Melanie
Dirk Krause wrote:
> Hi,
>
> I did a little test with a fresh OpenSim installation (yes, thanks for
> the installer!),
> to get a grip on what I learned from Melanie yesterday.
>
> I wrote a little python script to help me monitor these tables:
> inventoryStore/inventoryItems
> assetStorage/assets
> http://pastebin.com/mc9e6574 , be warned: ugly code.
>
> I started OpenSim and logged in a 'Test User' with the SL viewer.
>
> (Just to mention it - first time log in in as test users creates
> 4 'blank' entries in assets.)
>
> The inventoryItems table was initially empty.
>
> Now I rezzed a cube and renamed it to 'p1'.
> inventoryStore/inventoryItems was still empty.
> To my surprise no new entry shows up in assetStorage/assets.
>
> Picking up the cube ('take') created an entry named 'p1' in the
> inventory and in the asset table.
>
> Now I renamed the cube in Test Users inventory to 'p2'.
> The name in inventoryStore/inventoryItems changes to 'p2'.
> The entry in assetStorage/assets stays 'p1'. As mentioned on the list
> before,
> the asset name is useless, since the user only sees the
Re: [Opensim-dev] oddities with asset storage
Melanie wrote:
> This is something i have though about. However, it would not work in
> OSGrid. Regions may go away, and they may go away permanently.
> Anything in a prim inventory at that time is refcounted and would
> not be released. Ever.
>
In what what in particular would this be worse than the current
situation? Yes, some assets would end up staying around forever.
However, unlike the current scheme, some... would not.
> So, you'd need a ref list, to purge invalid refs. That is where the
> inpracticability begins. A redf list for each and every asset,
> listing either avatar UUID or region UUID?
>
>
Eep, no - wasn't considering suggesting this.
> If assets are 51 mio, how long will the reflist table be?
>
> Melanie
>
> Buckaroo Mu wrote:
>
>> Here's my L$0.02, for what it's worth - why not maintain a 'reference
>> count' in the asset entry?
>>
>> Resident A creates a prim, takes it into inventory. Asset is created,
>> inventory item pointing to asset is created, asset->useagecount++. User
>> gives away 15 copies of item, asset->usagecount+=15. Resident A deletes
>> original item, inventory item goes away, asset->usagecount--.
>>
>> Resident B rezzes item on sim. If item is no-copy, asset->usagecount--.
>> If it's copy, and Resident B (or Resident C) takes it back into
>> inventory, asset->usagecount++ (they would have two copies of it).
>> Resident B deletes both copies from inventory, asset->usagecount -=2.
>>
>> If asset->usagecount == 0, asset gets deleted.
>>
>> Tell me why this wouldn't work. I'm sure there's a simple reason, but I
>> can't think of it. All of this is assuming that the asset is no-mod -
>> any change to the asset creates a new UUID, correct? But if the asset is
>> rezzed, then taken back into inventory, it should have the same UUID,
>> thus adding one to the usage count.
>>
>> -Buckaroo
>>
>> Melanie wrote:
>>
>>> All you described is design behavior.
>>>
>>>
>>> Prim items in world are not assets. They are stored exclusively in
>>> the prims tables of the region.
>>>
>>> Once taken, they become an asset. The name is totally meaningless,
>>> it reflects whatever was the name at creation. Nothing else. It
>>> never changes from there on.
>>>
>>> On deleting the inventory item, assets remain. There is no easy or
>>> practicable way to conclusively say that an asset is trash, because
>>> we don't know.
>>>
>>> In your test case, your (human) mind could know this for a fact,
>>> however, the silicon mind of the asset server can't.
>>>
>>> This is because you may have given the object to another user, or
>>> put a copy into a prim.
>>>
>>> These copies would refer to the same asset, that is what "implictily
>>> shared" means.
>>>
>>> So, any asset may, at any time, have any number of links to it, even
>>> zero.
>>>
>>> Like a website, you don't know who linked to it. If you remove it,
>>> you leave dead links. Assets are the same. Except, you get "Asset
>>> missing from database".
>>>
>>> So, assetas are NOT 1-to-1 with inventory items, and they _never_
>>> get deleted.
>>>
>>> They have to be reaped, and there is a big discussion over how to
>>> best do that, running right now.
>>>
>>> Melanie
>>>
>>>
>>> Dirk Krause wrote:
>>>
>>>
Hi,
I did a little test with a fresh OpenSim installation (yes, thanks for
the installer!),
to get a grip on what I learned from Melanie yesterday.
I wrote a little python script to help me monitor these tables:
inventoryStore/inventoryItems
assetStorage/assets
http://pastebin.com/mc9e6574 , be warned: ugly code.
I started OpenSim and logged in a 'Test User' with the SL viewer.
(Just to mention it - first time log in in as test users creates
4 'blank' entries in assets.)
The inventoryItems table was initially empty.
Now I rezzed a cube and renamed it to 'p1'.
inventoryStore/inventoryItems was still empty.
To my surprise no new entry shows up in assetStorage/assets.
Picking up the cube ('take') created an entry named 'p1' in the
inventory and in the asset table.
Now I renamed the cube in Test Users inventory to 'p2'.
The name in inventoryStore/inventoryItems changes to 'p2'.
The entry in assetStorage/assets stays 'p1'. As mentioned on the list
before,
the asset name is useless, since the user only sees the name in the
inventory.
Now I deleted 'p2' in my inventory - 'p2's parentfolderID changes to
'Trash'.
Now I emptied the trash - the inventory table is empty again, which is
fine,
but here's the big one:
the assetStorage/assets still holds the reference to 'p1'.
Just to make sure I shut down the simulator and opened it again, and it
was still there.
Now, doesn't that mean, that the database increases over time with no
hope to find
these assets that actually should be gone? or is there s
Re: [Opensim-dev] oddities with asset storage
This is something i have though about. However, it would not work in
OSGrid. Regions may go away, and they may go away permanently.
Anything in a prim inventory at that time is refcounted and would
not be released. Ever.
So, you'd need a ref list, to purge invalid refs. That is where the
inpracticability begins. A redf list for each and every asset,
listing either avatar UUID or region UUID?
If assets are 51 mio, how long will the reflist table be?
Melanie
Buckaroo Mu wrote:
> Here's my L$0.02, for what it's worth - why not maintain a 'reference
> count' in the asset entry?
>
> Resident A creates a prim, takes it into inventory. Asset is created,
> inventory item pointing to asset is created, asset->useagecount++. User
> gives away 15 copies of item, asset->usagecount+=15. Resident A deletes
> original item, inventory item goes away, asset->usagecount--.
>
> Resident B rezzes item on sim. If item is no-copy, asset->usagecount--.
> If it's copy, and Resident B (or Resident C) takes it back into
> inventory, asset->usagecount++ (they would have two copies of it).
> Resident B deletes both copies from inventory, asset->usagecount -=2.
>
> If asset->usagecount == 0, asset gets deleted.
>
> Tell me why this wouldn't work. I'm sure there's a simple reason, but I
> can't think of it. All of this is assuming that the asset is no-mod -
> any change to the asset creates a new UUID, correct? But if the asset is
> rezzed, then taken back into inventory, it should have the same UUID,
> thus adding one to the usage count.
>
> -Buckaroo
>
> Melanie wrote:
>> All you described is design behavior.
>>
>>
>> Prim items in world are not assets. They are stored exclusively in
>> the prims tables of the region.
>>
>> Once taken, they become an asset. The name is totally meaningless,
>> it reflects whatever was the name at creation. Nothing else. It
>> never changes from there on.
>>
>> On deleting the inventory item, assets remain. There is no easy or
>> practicable way to conclusively say that an asset is trash, because
>> we don't know.
>>
>> In your test case, your (human) mind could know this for a fact,
>> however, the silicon mind of the asset server can't.
>>
>> This is because you may have given the object to another user, or
>> put a copy into a prim.
>>
>> These copies would refer to the same asset, that is what "implictily
>> shared" means.
>>
>> So, any asset may, at any time, have any number of links to it, even
>> zero.
>>
>> Like a website, you don't know who linked to it. If you remove it,
>> you leave dead links. Assets are the same. Except, you get "Asset
>> missing from database".
>>
>> So, assetas are NOT 1-to-1 with inventory items, and they _never_
>> get deleted.
>>
>> They have to be reaped, and there is a big discussion over how to
>> best do that, running right now.
>>
>> Melanie
>>
>>
>> Dirk Krause wrote:
>>
>>> Hi,
>>>
>>> I did a little test with a fresh OpenSim installation (yes, thanks for
>>> the installer!),
>>> to get a grip on what I learned from Melanie yesterday.
>>>
>>> I wrote a little python script to help me monitor these tables:
>>> inventoryStore/inventoryItems
>>> assetStorage/assets
>>> http://pastebin.com/mc9e6574 , be warned: ugly code.
>>>
>>> I started OpenSim and logged in a 'Test User' with the SL viewer.
>>>
>>> (Just to mention it - first time log in in as test users creates
>>> 4 'blank' entries in assets.)
>>>
>>> The inventoryItems table was initially empty.
>>>
>>> Now I rezzed a cube and renamed it to 'p1'.
>>> inventoryStore/inventoryItems was still empty.
>>> To my surprise no new entry shows up in assetStorage/assets.
>>>
>>> Picking up the cube ('take') created an entry named 'p1' in the
>>> inventory and in the asset table.
>>>
>>> Now I renamed the cube in Test Users inventory to 'p2'.
>>> The name in inventoryStore/inventoryItems changes to 'p2'.
>>> The entry in assetStorage/assets stays 'p1'. As mentioned on the list
>>> before,
>>> the asset name is useless, since the user only sees the name in the
>>> inventory.
>>>
>>> Now I deleted 'p2' in my inventory - 'p2's parentfolderID changes to
>>> 'Trash'.
>>> Now I emptied the trash - the inventory table is empty again, which is
>>> fine,
>>> but here's the big one:
>>>the assetStorage/assets still holds the reference to 'p1'.
>>>
>>> Just to make sure I shut down the simulator and opened it again, and it
>>> was still there.
>>>
>>> Now, doesn't that mean, that the database increases over time with no
>>> hope to find
>>> these assets that actually should be gone? or is there some magic
>>> purging that happens,
>>> and that I missed?
>>>
>>> This would mean that any grid runs into a severe problem over time.
>>>
>>> Best,
>>> Dirk/Bart
>>> ___
>>> Opensim-dev mailing list
>>> Opensim-dev@lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>>
>>>
>>
>> ___
Re: [Opensim-dev] oddities with asset storage
Here's my L$0.02, for what it's worth - why not maintain a 'reference
count' in the asset entry?
Resident A creates a prim, takes it into inventory. Asset is created,
inventory item pointing to asset is created, asset->useagecount++. User
gives away 15 copies of item, asset->usagecount+=15. Resident A deletes
original item, inventory item goes away, asset->usagecount--.
Resident B rezzes item on sim. If item is no-copy, asset->usagecount--.
If it's copy, and Resident B (or Resident C) takes it back into
inventory, asset->usagecount++ (they would have two copies of it).
Resident B deletes both copies from inventory, asset->usagecount -=2.
If asset->usagecount == 0, asset gets deleted.
Tell me why this wouldn't work. I'm sure there's a simple reason, but I
can't think of it. All of this is assuming that the asset is no-mod -
any change to the asset creates a new UUID, correct? But if the asset is
rezzed, then taken back into inventory, it should have the same UUID,
thus adding one to the usage count.
-Buckaroo
Melanie wrote:
> All you described is design behavior.
>
>
> Prim items in world are not assets. They are stored exclusively in
> the prims tables of the region.
>
> Once taken, they become an asset. The name is totally meaningless,
> it reflects whatever was the name at creation. Nothing else. It
> never changes from there on.
>
> On deleting the inventory item, assets remain. There is no easy or
> practicable way to conclusively say that an asset is trash, because
> we don't know.
>
> In your test case, your (human) mind could know this for a fact,
> however, the silicon mind of the asset server can't.
>
> This is because you may have given the object to another user, or
> put a copy into a prim.
>
> These copies would refer to the same asset, that is what "implictily
> shared" means.
>
> So, any asset may, at any time, have any number of links to it, even
> zero.
>
> Like a website, you don't know who linked to it. If you remove it,
> you leave dead links. Assets are the same. Except, you get "Asset
> missing from database".
>
> So, assetas are NOT 1-to-1 with inventory items, and they _never_
> get deleted.
>
> They have to be reaped, and there is a big discussion over how to
> best do that, running right now.
>
> Melanie
>
>
> Dirk Krause wrote:
>
>> Hi,
>>
>> I did a little test with a fresh OpenSim installation (yes, thanks for
>> the installer!),
>> to get a grip on what I learned from Melanie yesterday.
>>
>> I wrote a little python script to help me monitor these tables:
>> inventoryStore/inventoryItems
>> assetStorage/assets
>> http://pastebin.com/mc9e6574 , be warned: ugly code.
>>
>> I started OpenSim and logged in a 'Test User' with the SL viewer.
>>
>> (Just to mention it - first time log in in as test users creates
>> 4 'blank' entries in assets.)
>>
>> The inventoryItems table was initially empty.
>>
>> Now I rezzed a cube and renamed it to 'p1'.
>> inventoryStore/inventoryItems was still empty.
>> To my surprise no new entry shows up in assetStorage/assets.
>>
>> Picking up the cube ('take') created an entry named 'p1' in the
>> inventory and in the asset table.
>>
>> Now I renamed the cube in Test Users inventory to 'p2'.
>> The name in inventoryStore/inventoryItems changes to 'p2'.
>> The entry in assetStorage/assets stays 'p1'. As mentioned on the list
>> before,
>> the asset name is useless, since the user only sees the name in the
>> inventory.
>>
>> Now I deleted 'p2' in my inventory - 'p2's parentfolderID changes to
>> 'Trash'.
>> Now I emptied the trash - the inventory table is empty again, which is
>> fine,
>> but here's the big one:
>>the assetStorage/assets still holds the reference to 'p1'.
>>
>> Just to make sure I shut down the simulator and opened it again, and it
>> was still there.
>>
>> Now, doesn't that mean, that the database increases over time with no
>> hope to find
>> these assets that actually should be gone? or is there some magic
>> purging that happens,
>> and that I missed?
>>
>> This would mean that any grid runs into a severe problem over time.
>>
>> Best,
>> Dirk/Bart
>> ___
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] [croquet-dev] meeting today for arranging media links for MMOX BOF meeting
- Forwarded message from Lawson English - From: Lawson English Date: Wed, 18 Feb 2009 14:08:59 -0700 To: croquet-...@duke.edu CC: "Meadhbh S. Hamrick (Infinity Linden)" , David W Levine Subject: [croquet-dev] meeting today for arranging media links for MMOX BOF meeting User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) Reply-To: croquet-...@duke.edu, Lawson English Hey all, sorry this is being sent out so late but we arranged the time at the last second. Background: mmox is a proposed working group for the IETF that will have a Birds of Feather meeting in March at the IETF 74 meeting. mmox stands for "Massively Multiplayer Online X" [stuff] and is meant to be a general working group to design interoperability protocols between various virtual worlds. A meeting will be held today (Wed, Feb 18, 2009) at 4PM Pacific Coast Time in a Second Life venue to discuss the details/requirements for setting up 2-way video streaming of the March BOF meeting to/from participating virtual worlds. Media stream meeting: http://slurl.com/secondlife/Levenhall/89/205/105 The info about MMOX is found here: http://wiki.secondlife.com/wiki/MMOX Hope someone can attend and sorry for the last second notification. The BOF meeting is still in the BOF planning stages... ;-) Lawson English (Saijanai Kuhn in Second Life) - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] Heads Up: Updating Prebuild to Upstream
Dear colleagues, Kunnis and JHurliman has been working to incorporate our Prebuild customizations into the upstream source, and we're now at the point where we can do an upstream update and subsequentially move the Prebuild source out of the trunk and into opensim-libs. (Or should it go on the forge?) Since the code hasn't changed that much, I believe we should simply go ahead and do the switch, and if any cross-environment breakage would happen, work together to solve it. So please help us troubleshoot Prebuild on your environment. Best regards, Stefan Andersson Tribal Media AB ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] oddities with asset storage
- I also agree with you Dirk Krause wrote: I hope I am not too notorious by stating: - no 'big corp' IT manager will accept a solution with 'uncontrollable growth in asset storage' as Tommi correctly put it. Period. - I learned through Melanie that these issue are well known and already addressed. - I also learned that potential viewer developers are aware of these issues and have it on their list which is great. - I also agree with Stefan that there should be alternative scenarios possible. Von: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Charles Krinke Gesendet: Mittwoch, 18. Februar 2009 21:52 An: opensim-dev@lists.berlios.de Betreff: Re: [Opensim-dev] oddities with asset storage My goal in starting this whole discussion in the first place was two fold. Fold 1: Get us considering how to evolve OpenSim so that assets database currently containing 1.5million entries and consuming 50GBytes to support 10,000 users does not continue to grow without bound at the current 4GByte/week rate if possible. I see other grid deployments facing a similar issue in their future and some evolution at this point may help us all. Fold 2: I believe there are a few changes such as the "last terrain image" store that we can change in the near term, and I am hoping we can define a 'reaping' strategy for grids that lets them tame the exponential growth of the 'assets' table in the MySQL database defined by OpenSim as 2009 continues. Charles From: Melanie To: opensim-dev@lists.berlios.de Sent: Wednesday, February 18, 2009 12:20:42 PM Subject: Re: [Opensim-dev] oddities with asset storage There are several viewer being developed already and their authors are aware of requirements and responsive to different needs. Mainly, any new viewer will be able to accommodate changes quickly, unlike the LL viewer. So I see no need for a drawn out standardization discussion. This project is in too early a phase for this. Melanie Dirk Krause wrote: Ok, granted. But isn't this a bit chicken/egg here? Possible solution scenarios should define the requirements of the viewer, which probably won't write itself. Esp. when new viewers will be based on openmv somebody should tell John et al. :-). -Ursprüngliche Nachricht- Von: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Melanie Gesendet: Mittwoch, 18. Februar 2009 20:42 An: opensim-dev@lists.berlios.de Betreff: Re: [Opensim-dev] oddities with asset storage In the viewer, the following are true: - The asset ID attached to an inventory item may not change - The item ID of an inventory item may not change - an asset's content may not change. So, with this client, it's moot. We are exploring other concepts and will be implementing them as and when other clients become usable. Melanie Dirk Krause wrote: There could be business modell attached to it. Lets say you sell only the 'right to use it for a given time' to the user, then you would have only one set of assets with multiple inventory pointers from your 2000 customers. Once you delete/disable it, no one can use it anymore. Once you update it, all 2000 have a newer version of it. The other model would be the 'I buy it so I get a real copy of it'. The asset will be copied (in my scenario to my local inventory domain, so I 'really' own it). If you delete yours, mine is still there. If you update it, I need to obtain a newer copy. There could even be a concept that something is there only once (maybe art); you create it, give it a away (for a good price) and you don't have it anymore. The asset vanishes from your inventory domain. Regarding the SL compatibility - maybe it doesn't need to be broken. IIRC isn't there this CAPS mechanism that already proxies assets? Couldn't there be some kind of intelligence behind it that collects and distributes assets from the different domains? -Ursprüngliche Nachricht- Von: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Melanie Gesendet: Mittwoch, 18. Februar 2009 19:57 An: opensim-dev@lists.berlios.de Betreff: Re: [Opensim-dev] oddities with asset storage Making a copy is the greater evil. With implicitly shared assets, only content creators create assets. With asset copying, each sale/give creates assets. Take SL: I make a clothing item. I have to make 18 uploads (creating 18 assets) to finally use 2 of the uploaded textures. I have also created 36 wearable assets through this. Then i put that item for sale. 2000 users buy it. With implicitly shared assets, assets consumed: 18 texture, 36 wearable. With asset copying, assets consumed: 4001 texture, 4003 wearable See, the point of diminishing returns for copying is very close. Melanie John Ward wrote: Justin Clark-Casey wrote: The problem is th
Re: [Opensim-dev] oddities with asset storage
I hope I am not too notorious by stating: - no 'big corp' IT manager will accept a solution with 'uncontrollable growth in asset storage' as Tommi correctly put it. Period. - I learned through Melanie that these issue are well known and already addressed. - I also learned that potential viewer developers are aware of these issues and have it on their list which is great. - I also agree with Stefan that there should be alternative scenarios possible. Von: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Charles Krinke Gesendet: Mittwoch, 18. Februar 2009 21:52 An: opensim-dev@lists.berlios.de Betreff: Re: [Opensim-dev] oddities with asset storage My goal in starting this whole discussion in the first place was two fold. Fold 1: Get us considering how to evolve OpenSim so that assets database currently containing 1.5million entries and consuming 50GBytes to support 10,000 users does not continue to grow without bound at the current 4GByte/week rate if possible. I see other grid deployments facing a similar issue in their future and some evolution at this point may help us all. Fold 2: I believe there are a few changes such as the "last terrain image" store that we can change in the near term, and I am hoping we can define a 'reaping' strategy for grids that lets them tame the exponential growth of the 'assets' table in the MySQL database defined by OpenSim as 2009 continues. Charles From: Melanie To: opensim-dev@lists.berlios.de Sent: Wednesday, February 18, 2009 12:20:42 PM Subject: Re: [Opensim-dev] oddities with asset storage There are several viewer being developed already and their authors are aware of requirements and responsive to different needs. Mainly, any new viewer will be able to accommodate changes quickly, unlike the LL viewer. So I see no need for a drawn out standardization discussion. This project is in too early a phase for this. Melanie Dirk Krause wrote: > Ok, granted. But isn't this a bit chicken/egg here? Possible solution > scenarios should define the requirements of the viewer, which probably won't > write itself. Esp. when new viewers will be based on openmv somebody should > tell John et al. :-). > > -Ursprüngliche Nachricht- > Von: opensim-dev-boun...@lists.berlios.de > [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Melanie > Gesendet: Mittwoch, 18. Februar 2009 20:42 > An: opensim-dev@lists.berlios.de > Betreff: Re: [Opensim-dev] oddities with asset storage > > In the viewer, the following are true: > > - The asset ID attached to an inventory item may not change > - The item ID of an inventory item may not change > - an asset's content may not change. > > So, with this client, it's moot. > > We are exploring other concepts and will be implementing them as and > when other clients become usable. > > Melanie > > > Dirk Krause wrote: >> There could be business modell attached to it. >> Lets say you sell only the 'right to use it for a given time' to the user, >> then you would have only one set of assets with multiple inventory pointers >> from your 2000 customers. Once you delete/disable it, no one can use it >> anymore. Once you update it, all 2000 have a newer version of it. The other >> model would be the 'I buy it so I get a real copy of it'. The asset will be >> copied (in my scenario to my local inventory domain, so I 'really' own it). >> If you delete yours, mine is still there. If you update it, I need to obtain >> a newer copy. There could even be a concept that something is there only >> once (maybe art); you create it, give it a away (for a good price) and you >> don't have it anymore. The asset vanishes from your inventory domain. >> >> Regarding the SL compatibility - maybe it doesn't need to be broken. IIRC >> isn't there this CAPS mechanism that already proxies assets? Couldn't there >> be some kind of intelligence behind it that collects and distributes assets >> from the different domains? > >> >> -Ursprüngliche Nachricht- >> Von: opensim-dev-boun...@lists.berlios.de >> [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Melanie >> Gesendet: Mittwoch, 18. Februar 2009 19:57 >> An: opensim-dev@lists.berlios.de >> Betreff: Re: [Opensim-dev] oddities with asset storage >> >> Making a copy is the greater evil. With implicitly shared assets, >> only content creators create assets. With asset copying, each >> sale/give creates assets. >> Take SL: >> >> I make a clothing item. I have to make 18 uploads (creating 18 >> assets) to finally use 2 of the uploaded textures. I have also >> created 36 wearable assets through this. >> >> Then i put that item for sale. 2000 users buy it. >> >> With implicitly shared assets, assets consumed: 18 texture, 36 wearable. >> >> With asset copying, assets consumed: 4001 texture, 4003 wearable >> >> See, the point of diminishing returns for copyi
Re: [Opensim-dev] oddities with asset storage
My goal in starting this whole discussion in the first place was two fold. Fold 1: Get us considering how to evolve OpenSim so that assets database currently containing 1.5million entries and consuming 50GBytes to support 10,000 users does not continue to grow without bound at the current 4GByte/week rate if possible. I see other grid deployments facing a similar issue in their future and some evolution at this point may help us all. Fold 2: I believe there are a few changes such as the "last terrain image" store that we can change in the near term, and I am hoping we can define a 'reaping' strategy for grids that lets them tame the exponential growth of the 'assets' table in the MySQL database defined by OpenSim as 2009 continues. Charles From: Melanie To: opensim-dev@lists.berlios.de Sent: Wednesday, February 18, 2009 12:20:42 PM Subject: Re: [Opensim-dev] oddities with asset storage There are several viewer being developed already and their authors are aware of requirements and responsive to different needs. Mainly, any new viewer will be able to accommodate changes quickly, unlike the LL viewer. So I see no need for a drawn out standardization discussion. This project is in too early a phase for this. Melanie Dirk Krause wrote: > Ok, granted. But isn't this a bit chicken/egg here? Possible solution > scenarios should define the requirements of the viewer, which probably won't > write itself. Esp. when new viewers will be based on openmv somebody should > tell John et al. :-). > > -Ursprüngliche Nachricht- > Von: opensim-dev-boun...@lists.berlios.de > [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Melanie > Gesendet: Mittwoch, 18. Februar 2009 20:42 > An: opensim-dev@lists.berlios.de > Betreff: Re: [Opensim-dev] oddities with asset storage > > In the viewer, the following are true: > > - The asset ID attached to an inventory item may not change > - The item ID of an inventory item may not change > - an asset's content may not change. > > So, with this client, it's moot. > > We are exploring other concepts and will be implementing them as and > when other clients become usable. > > Melanie > > > Dirk Krause wrote: >> There could be business modell attached to it. >> Lets say you sell only the 'right to use it for a given time' to the user, >> then you would have only one set of assets with multiple inventory pointers >> from your 2000 customers. Once you delete/disable it, no one can use it >> anymore. Once you update it, all 2000 have a newer version of it. The other >> model would be the 'I buy it so I get a real copy of it'. The asset will be >> copied (in my scenario to my local inventory domain, so I 'really' own it). >> If you delete yours, mine is still there. If you update it, I need to obtain >> a newer copy. There could even be a concept that something is there only >> once (maybe art); you create it, give it a away (for a good price) and you >> don't have it anymore. The asset vanishes from your inventory domain. >> >> Regarding the SL compatibility - maybe it doesn't need to be broken. IIRC >> isn't there this CAPS mechanism that already proxies assets? Couldn't there >> be some kind of intelligence behind it that collects and distributes assets >> from the different domains? > >> >> -Ursprüngliche Nachricht- >> Von: opensim-dev-boun...@lists.berlios.de >> [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Melanie >> Gesendet: Mittwoch, 18. Februar 2009 19:57 >> An: opensim-dev@lists.berlios.de >> Betreff: Re: [Opensim-dev] oddities with asset storage >> >> Making a copy is the greater evil. With implicitly shared assets, >> only content creators create assets. With asset copying, each >> sale/give creates assets. >> Take SL: >> >> I make a clothing item. I have to make 18 uploads (creating 18 >> assets) to finally use 2 of the uploaded textures. I have also >> created 36 wearable assets through this. >> >> Then i put that item for sale. 2000 users buy it. >> >> With implicitly shared assets, assets consumed: 18 texture, 36 wearable. >> >> With asset copying, assets consumed: 4001 texture, 4003 wearable >> >> See, the point of diminishing returns for copying is very close. >> >> Melanie >> >> >> John Ward wrote: >>> Justin Clark-Casey wrote: The problem is that you may have given that item to somebody else. Giving an item does not make an asset copy, it just makes an inventory item copy (both inventory items still point towards the same asset). So you may delete your item, but we don't know if the asset referenced by that item lives on in someone else's inventory (or in an object inventory). So we can't delete the underlying asset. >>> >>> Why not make an asset copy when one makes an inventory copy? Then >>> delete the asset when deleted from inventory. Is each user having their >>> own copy of many things a
Re: [Opensim-dev] oddities with asset storage
ok, very cool, thanks for the info. I take it you esp refer to IdealistViewer, openviewer and the Rex-NG viewer? -Ursprüngliche Nachricht- Von: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Melanie Gesendet: Mittwoch, 18. Februar 2009 21:21 An: opensim-dev@lists.berlios.de Betreff: Re: [Opensim-dev] oddities with asset storage There are several viewer being developed already and their authors are aware of requirements and responsive to different needs. Mainly, any new viewer will be able to accommodate changes quickly, unlike the LL viewer. So I see no need for a drawn out standardization discussion. This project is in too early a phase for this. Melanie Dirk Krause wrote: > Ok, granted. But isn't this a bit chicken/egg here? Possible solution > scenarios should define the requirements of the viewer, which probably won't > write itself. Esp. when new viewers will be based on openmv somebody should > tell John et al. :-). > > -Ursprüngliche Nachricht- > Von: opensim-dev-boun...@lists.berlios.de > [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Melanie > Gesendet: Mittwoch, 18. Februar 2009 20:42 > An: opensim-dev@lists.berlios.de > Betreff: Re: [Opensim-dev] oddities with asset storage > > In the viewer, the following are true: > > - The asset ID attached to an inventory item may not change > - The item ID of an inventory item may not change > - an asset's content may not change. > > So, with this client, it's moot. > > We are exploring other concepts and will be implementing them as and > when other clients become usable. > > Melanie > > > Dirk Krause wrote: >> There could be business modell attached to it. >> Lets say you sell only the 'right to use it for a given time' to the user, >> then you would have only one set of assets with multiple inventory pointers >> from your 2000 customers. Once you delete/disable it, no one can use it >> anymore. Once you update it, all 2000 have a newer version of it. The other >> model would be the 'I buy it so I get a real copy of it'. The asset will be >> copied (in my scenario to my local inventory domain, so I 'really' own it). >> If you delete yours, mine is still there. If you update it, I need to obtain >> a newer copy. There could even be a concept that something is there only >> once (maybe art); you create it, give it a away (for a good price) and you >> don't have it anymore. The asset vanishes from your inventory domain. >> >> Regarding the SL compatibility - maybe it doesn't need to be broken. IIRC >> isn't there this CAPS mechanism that already proxies assets? Couldn't there >> be some kind of intelligence behind it that collects and distributes assets >> from the different domains? > >> >> -Ursprüngliche Nachricht- >> Von: opensim-dev-boun...@lists.berlios.de >> [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Melanie >> Gesendet: Mittwoch, 18. Februar 2009 19:57 >> An: opensim-dev@lists.berlios.de >> Betreff: Re: [Opensim-dev] oddities with asset storage >> >> Making a copy is the greater evil. With implicitly shared assets, >> only content creators create assets. With asset copying, each >> sale/give creates assets. >> Take SL: >> >> I make a clothing item. I have to make 18 uploads (creating 18 >> assets) to finally use 2 of the uploaded textures. I have also >> created 36 wearable assets through this. >> >> Then i put that item for sale. 2000 users buy it. >> >> With implicitly shared assets, assets consumed: 18 texture, 36 wearable. >> >> With asset copying, assets consumed: 4001 texture, 4003 wearable >> >> See, the point of diminishing returns for copying is very close. >> >> Melanie >> >> >> John Ward wrote: >>> Justin Clark-Casey wrote: The problem is that you may have given that item to somebody else. Giving an item does not make an asset copy, it just makes an inventory item copy (both inventory items still point towards the same asset). So you may delete your item, but we don't know if the asset referenced by that item lives on in someone else's inventory (or in an object inventory). So we can't delete the underlying asset. >>> >>> Why not make an asset copy when one makes an inventory copy? Then >>> delete the asset when deleted from inventory. Is each user having their >>> own copy of many things a bigger problem? I guess this doesn't address >>> one having out of ban knowledge of an assets UUID and expecting it to be >>> there. Also, I accept that I may be missing some fundamental knowledge >>> of how things work. Please be gentle :-) >>> >>> John. >>> ___ >>> Opensim-dev mailing list >>> Opensim-dev@lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >> ___ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.d
Re: [Opensim-dev] oddities with asset storage
Stefan Andersson wrote: Um. Having immutable assets do bring a number of optimization shortcuts. I'm not saying it's all good - merely that it's not all bad. The OpenSim solution, as always, is to address each case by itself, and to make divergence optional. So, maybe region map textures should be overwriteable. Maybe some scripts should be overwriteable as well, maybe only on some type of scripts. Maybe we should have a table enumerating what assetIds now point to newer assetIds. Yes, +1 Maybe the real problem is that we are talking about 'assets' and 'textures' instead of 'prim face textures', 'sculptie maps', 'photos', 'region map images', 'script sources', 'sounds', 'prims in inventory', 'notecards', 'animations' - my point being that we can probably implement various configurable strategies for each of them, linden viewer or no linden viewer. Yes, +1000 Best regards, Stefan Andersson Tribal Media AB > Date: Wed, 18 Feb 2009 16:37:12 +0100 > From: dirk.kra...@pixelpark.com > To: opensim-dev@lists.berlios.de > Subject: Re: [Opensim-dev] oddities with asset storage > > ... > > >> This would mean that any grid runs into a severe problem over time. > > >> Yep :). On a standalone one could implement some cleanup scheme > which checks everything to see > >> if an asset is still referenced, and deletes that asset if it is not. > >> In grid mode this is a much more difficult problem since references > are scattered across many different > >> regions servers. The situation is even worse if you are running a > grid where not all of them are > >> guaranteed to be connected. > > But isn't that ... horrible? (in lack of a better/worse word.) > > As I said yesterday, IMHO there is no real need to think about > optimizations when you have > a serious blocker like this. I would even go so far that this is a major > roadblock for grid based technologies per se. (grid as in Rosedale's > 'Happily now, Second Life has been proven to exist. If we disappeared > tomorrow, the grid would be rebuilt by you.') > > I take it the bad news is that any proposed solution to this breaks SL > compatibility? > > Maybe now would be a good time to take a step away from it. > > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev begin:vcard fn:Ideia Boa n:Boa;Ideia note;quoted-printable:Best regards,=0D=0A= Ideia Boa=0D=0A= WorldSimTerra=0D=0A= =0D=0A= Join the new 3D world revolution : http://www.worldsimterra.com/ x-mozilla-html:TRUE url:http://www.worldsimterra.com version:2.1 end:vcard ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] oddities with asset storage
There are several viewer being developed already and their authors are aware of requirements and responsive to different needs. Mainly, any new viewer will be able to accommodate changes quickly, unlike the LL viewer. So I see no need for a drawn out standardization discussion. This project is in too early a phase for this. Melanie Dirk Krause wrote: > Ok, granted. But isn't this a bit chicken/egg here? Possible solution > scenarios should define the requirements of the viewer, which probably won't > write itself. Esp. when new viewers will be based on openmv somebody should > tell John et al. :-). > > -Ursprüngliche Nachricht- > Von: opensim-dev-boun...@lists.berlios.de > [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Melanie > Gesendet: Mittwoch, 18. Februar 2009 20:42 > An: opensim-dev@lists.berlios.de > Betreff: Re: [Opensim-dev] oddities with asset storage > > In the viewer, the following are true: > > - The asset ID attached to an inventory item may not change > - The item ID of an inventory item may not change > - an asset's content may not change. > > So, with this client, it's moot. > > We are exploring other concepts and will be implementing them as and > when other clients become usable. > > Melanie > > > Dirk Krause wrote: >> There could be business modell attached to it. >> Lets say you sell only the 'right to use it for a given time' to the user, >> then you would have only one set of assets with multiple inventory pointers >> from your 2000 customers. Once you delete/disable it, no one can use it >> anymore. Once you update it, all 2000 have a newer version of it. The other >> model would be the 'I buy it so I get a real copy of it'. The asset will be >> copied (in my scenario to my local inventory domain, so I 'really' own it). >> If you delete yours, mine is still there. If you update it, I need to obtain >> a newer copy. There could even be a concept that something is there only >> once (maybe art); you create it, give it a away (for a good price) and you >> don't have it anymore. The asset vanishes from your inventory domain. >> >> Regarding the SL compatibility - maybe it doesn't need to be broken. IIRC >> isn't there this CAPS mechanism that already proxies assets? Couldn't there >> be some kind of intelligence behind it that collects and distributes assets >> from the different domains? > >> >> -Ursprüngliche Nachricht- >> Von: opensim-dev-boun...@lists.berlios.de >> [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Melanie >> Gesendet: Mittwoch, 18. Februar 2009 19:57 >> An: opensim-dev@lists.berlios.de >> Betreff: Re: [Opensim-dev] oddities with asset storage >> >> Making a copy is the greater evil. With implicitly shared assets, >> only content creators create assets. With asset copying, each >> sale/give creates assets. >> Take SL: >> >> I make a clothing item. I have to make 18 uploads (creating 18 >> assets) to finally use 2 of the uploaded textures. I have also >> created 36 wearable assets through this. >> >> Then i put that item for sale. 2000 users buy it. >> >> With implicitly shared assets, assets consumed: 18 texture, 36 wearable. >> >> With asset copying, assets consumed: 4001 texture, 4003 wearable >> >> See, the point of diminishing returns for copying is very close. >> >> Melanie >> >> >> John Ward wrote: >>> Justin Clark-Casey wrote: The problem is that you may have given that item to somebody else. Giving an item does not make an asset copy, it just makes an inventory item copy (both inventory items still point towards the same asset). So you may delete your item, but we don't know if the asset referenced by that item lives on in someone else's inventory (or in an object inventory). So we can't delete the underlying asset. >>> >>> Why not make an asset copy when one makes an inventory copy? Then >>> delete the asset when deleted from inventory. Is each user having their >>> own copy of many things a bigger problem? I guess this doesn't address >>> one having out of ban knowledge of an assets UUID and expecting it to be >>> there. Also, I accept that I may be missing some fundamental knowledge >>> of how things work. Please be gentle :-) >>> >>> John. >>> ___ >>> Opensim-dev mailing list >>> Opensim-dev@lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >> ___ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> ___ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> > > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/ope
Re: [Opensim-dev] oddities with asset storage
Ok, granted. But isn't this a bit chicken/egg here? Possible solution scenarios should define the requirements of the viewer, which probably won't write itself. Esp. when new viewers will be based on openmv somebody should tell John et al. :-). -Ursprüngliche Nachricht- Von: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Melanie Gesendet: Mittwoch, 18. Februar 2009 20:42 An: opensim-dev@lists.berlios.de Betreff: Re: [Opensim-dev] oddities with asset storage In the viewer, the following are true: - The asset ID attached to an inventory item may not change - The item ID of an inventory item may not change - an asset's content may not change. So, with this client, it's moot. We are exploring other concepts and will be implementing them as and when other clients become usable. Melanie Dirk Krause wrote: > There could be business modell attached to it. > Lets say you sell only the 'right to use it for a given time' to the user, > then you would have only one set of assets with multiple inventory pointers > from your 2000 customers. Once you delete/disable it, no one can use it > anymore. Once you update it, all 2000 have a newer version of it. The other > model would be the 'I buy it so I get a real copy of it'. The asset will be > copied (in my scenario to my local inventory domain, so I 'really' own it). > If you delete yours, mine is still there. If you update it, I need to obtain > a newer copy. There could even be a concept that something is there only once > (maybe art); you create it, give it a away (for a good price) and you don't > have it anymore. The asset vanishes from your inventory domain. > > Regarding the SL compatibility - maybe it doesn't need to be broken. IIRC > isn't there this CAPS mechanism that already proxies assets? Couldn't there > be some kind of intelligence behind it that collects and distributes assets > from the different domains? > > -Ursprüngliche Nachricht- > Von: opensim-dev-boun...@lists.berlios.de > [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Melanie > Gesendet: Mittwoch, 18. Februar 2009 19:57 > An: opensim-dev@lists.berlios.de > Betreff: Re: [Opensim-dev] oddities with asset storage > > Making a copy is the greater evil. With implicitly shared assets, > only content creators create assets. With asset copying, each > sale/give creates assets. > Take SL: > > I make a clothing item. I have to make 18 uploads (creating 18 > assets) to finally use 2 of the uploaded textures. I have also > created 36 wearable assets through this. > > Then i put that item for sale. 2000 users buy it. > > With implicitly shared assets, assets consumed: 18 texture, 36 wearable. > > With asset copying, assets consumed: 4001 texture, 4003 wearable > > See, the point of diminishing returns for copying is very close. > > Melanie > > > John Ward wrote: >> Justin Clark-Casey wrote: >>> The problem is that you may have given that item to somebody else. >>> Giving an item does not make an asset copy, it just makes an >>> inventory item copy (both inventory items still point towards the >>> same asset). >>> >>> So you may delete your item, but we don't know if the asset >>> referenced by that item lives on in someone else's inventory (or in >>> an object inventory). So we can't delete the underlying asset. >> >> Why not make an asset copy when one makes an inventory copy? Then >> delete the asset when deleted from inventory. Is each user having their >> own copy of many things a bigger problem? I guess this doesn't address >> one having out of ban knowledge of an assets UUID and expecting it to be >> there. Also, I accept that I may be missing some fundamental knowledge >> of how things work. Please be gentle :-) >> >> John. >> ___ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] oddities with asset storage
In the viewer, the following are true: - The asset ID attached to an inventory item may not change - The item ID of an inventory item may not change - an asset's content may not change. So, with this client, it's moot. We are exploring other concepts and will be implementing them as and when other clients become usable. Melanie Dirk Krause wrote: > There could be business modell attached to it. > Lets say you sell only the 'right to use it for a given time' to the user, > then you would have only one set of assets with multiple inventory pointers > from your 2000 customers. Once you delete/disable it, no one can use it > anymore. Once you update it, all 2000 have a newer version of it. The other > model would be the 'I buy it so I get a real copy of it'. The asset will be > copied (in my scenario to my local inventory domain, so I 'really' own it). > If you delete yours, mine is still there. If you update it, I need to obtain > a newer copy. There could even be a concept that something is there only once > (maybe art); you create it, give it a away (for a good price) and you don't > have it anymore. The asset vanishes from your inventory domain. > > Regarding the SL compatibility - maybe it doesn't need to be broken. IIRC > isn't there this CAPS mechanism that already proxies assets? Couldn't there > be some kind of intelligence behind it that collects and distributes assets > from the different domains? > > -Ursprüngliche Nachricht- > Von: opensim-dev-boun...@lists.berlios.de > [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Melanie > Gesendet: Mittwoch, 18. Februar 2009 19:57 > An: opensim-dev@lists.berlios.de > Betreff: Re: [Opensim-dev] oddities with asset storage > > Making a copy is the greater evil. With implicitly shared assets, > only content creators create assets. With asset copying, each > sale/give creates assets. > Take SL: > > I make a clothing item. I have to make 18 uploads (creating 18 > assets) to finally use 2 of the uploaded textures. I have also > created 36 wearable assets through this. > > Then i put that item for sale. 2000 users buy it. > > With implicitly shared assets, assets consumed: 18 texture, 36 wearable. > > With asset copying, assets consumed: 4001 texture, 4003 wearable > > See, the point of diminishing returns for copying is very close. > > Melanie > > > John Ward wrote: >> Justin Clark-Casey wrote: >>> The problem is that you may have given that item to somebody else. >>> Giving an item does not make an asset copy, it just makes an >>> inventory item copy (both inventory items still point towards the >>> same asset). >>> >>> So you may delete your item, but we don't know if the asset >>> referenced by that item lives on in someone else's inventory (or in >>> an object inventory). So we can't delete the underlying asset. >> >> Why not make an asset copy when one makes an inventory copy? Then >> delete the asset when deleted from inventory. Is each user having their >> own copy of many things a bigger problem? I guess this doesn't address >> one having out of ban knowledge of an assets UUID and expecting it to be >> there. Also, I accept that I may be missing some fundamental knowledge >> of how things work. Please be gentle :-) >> >> John. >> ___ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] oddities with asset storage
I suggest we talk more about complementary and parallell scenarios and strategies, and less about either/or - this is a platform, and various implemetations will prioritize differently. Best regards, Stefan Andersson Tribal Media AB > Date: Wed, 18 Feb 2009 20:02:38 +0100 > From: dirk.kra...@pixelpark.com > To: opensim-dev@lists.berlios.de > Subject: Re: [Opensim-dev] oddities with asset storage > > There could be business modell attached to it. > Lets say you sell only the 'right to use it for a given time' to the user, > then you would have only one set of assets with multiple inventory pointers > from your 2000 customers. Once you delete/disable it, no one can use it > anymore. Once you update it, all 2000 have a newer version of it. The other > model would be the 'I buy it so I get a real copy of it'. The asset will be > copied (in my scenario to my local inventory domain, so I 'really' own it). > If you delete yours, mine is still there. If you update it, I need to obtain > a newer copy. There could even be a concept that something is there only once > (maybe art); you create it, give it a away (for a good price) and you don't > have it anymore. The asset vanishes from your inventory domain. > > Regarding the SL compatibility - maybe it doesn't need to be broken. IIRC > isn't there this CAPS mechanism that already proxies assets? Couldn't there > be some kind of intelligence behind it that collects and distributes assets > from the different domains? > > -Ursprüngliche Nachricht- > Von: opensim-dev-boun...@lists.berlios.de > [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Melanie > Gesendet: Mittwoch, 18. Februar 2009 19:57 > An: opensim-dev@lists.berlios.de > Betreff: Re: [Opensim-dev] oddities with asset storage > > Making a copy is the greater evil. With implicitly shared assets, > only content creators create assets. With asset copying, each > sale/give creates assets. > Take SL: > > I make a clothing item. I have to make 18 uploads (creating 18 > assets) to finally use 2 of the uploaded textures. I have also > created 36 wearable assets through this. > > Then i put that item for sale. 2000 users buy it. > > With implicitly shared assets, assets consumed: 18 texture, 36 wearable. > > With asset copying, assets consumed: 4001 texture, 4003 wearable > > See, the point of diminishing returns for copying is very close. > > Melanie > > > John Ward wrote: > > Justin Clark-Casey wrote: > >> The problem is that you may have given that item to somebody else. > >> Giving an item does not make an asset copy, it just makes an > >> inventory item copy (both inventory items still point towards the > >> same asset). > >> > >> So you may delete your item, but we don't know if the asset > >> referenced by that item lives on in someone else's inventory (or in > >> an object inventory). So we can't delete the underlying asset. > > > > Why not make an asset copy when one makes an inventory copy? Then > > delete the asset when deleted from inventory. Is each user having their > > own copy of many things a bigger problem? I guess this doesn't address > > one having out of ban knowledge of an assets UUID and expecting it to be > > there. Also, I accept that I may be missing some fundamental knowledge > > of how things work. Please be gentle :-) > > > > John. > > ___ > > Opensim-dev mailing list > > Opensim-dev@lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] oddities with asset storage
There could be business modell attached to it. Lets say you sell only the 'right to use it for a given time' to the user, then you would have only one set of assets with multiple inventory pointers from your 2000 customers. Once you delete/disable it, no one can use it anymore. Once you update it, all 2000 have a newer version of it. The other model would be the 'I buy it so I get a real copy of it'. The asset will be copied (in my scenario to my local inventory domain, so I 'really' own it). If you delete yours, mine is still there. If you update it, I need to obtain a newer copy. There could even be a concept that something is there only once (maybe art); you create it, give it a away (for a good price) and you don't have it anymore. The asset vanishes from your inventory domain. Regarding the SL compatibility - maybe it doesn't need to be broken. IIRC isn't there this CAPS mechanism that already proxies assets? Couldn't there be some kind of intelligence behind it that collects and distributes assets from the different domains? -Ursprüngliche Nachricht- Von: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Melanie Gesendet: Mittwoch, 18. Februar 2009 19:57 An: opensim-dev@lists.berlios.de Betreff: Re: [Opensim-dev] oddities with asset storage Making a copy is the greater evil. With implicitly shared assets, only content creators create assets. With asset copying, each sale/give creates assets. Take SL: I make a clothing item. I have to make 18 uploads (creating 18 assets) to finally use 2 of the uploaded textures. I have also created 36 wearable assets through this. Then i put that item for sale. 2000 users buy it. With implicitly shared assets, assets consumed: 18 texture, 36 wearable. With asset copying, assets consumed: 4001 texture, 4003 wearable See, the point of diminishing returns for copying is very close. Melanie John Ward wrote: > Justin Clark-Casey wrote: >> The problem is that you may have given that item to somebody else. >> Giving an item does not make an asset copy, it just makes an >> inventory item copy (both inventory items still point towards the >> same asset). >> >> So you may delete your item, but we don't know if the asset >> referenced by that item lives on in someone else's inventory (or in >> an object inventory). So we can't delete the underlying asset. > > Why not make an asset copy when one makes an inventory copy? Then > delete the asset when deleted from inventory. Is each user having their > own copy of many things a bigger problem? I guess this doesn't address > one having out of ban knowledge of an assets UUID and expecting it to be > there. Also, I accept that I may be missing some fundamental knowledge > of how things work. Please be gentle :-) > > John. > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] oddities with asset storage
In a non-SL context, that asset storage is ameliorated over a distributed asset system, whether it be P2P, or my own local asset server. There is a ceiling on the growth of asset copies: any given avatar has a fixed number of things to wear, a region a fixed number of things to display, or a human a fixed number of things they can effectively manage in an inventory. If you factor in nose-diving hardware costs per gigabyte, and distributed placement of that storage, the picture doesn't remain quite as clear as before. My point is: if OpenSim is interested in out growing SL, they may need to take a look at how one might theoretically handle various non-traditional caching schemes. Cheers, On Wed, Feb 18, 2009 at 8:56 PM, Melanie wrote: > Making a copy is the greater evil. With implicitly shared assets, > only content creators create assets. With asset copying, each > sale/give creates assets. > Take SL: > > I make a clothing item. I have to make 18 uploads (creating 18 > assets) to finally use 2 of the uploaded textures. I have also > created 36 wearable assets through this. > > Then i put that item for sale. 2000 users buy it. > > With implicitly shared assets, assets consumed: 18 texture, 36 wearable. > > With asset copying, assets consumed: 4001 texture, 4003 wearable > > See, the point of diminishing returns for copying is very close. > > Melanie > > > John Ward wrote: >> Justin Clark-Casey wrote: >>> The problem is that you may have given that item to somebody else. >>> Giving an item does not make an asset copy, it just makes an >>> inventory item copy (both inventory items still point towards the >>> same asset). >>> >>> So you may delete your item, but we don't know if the asset >>> referenced by that item lives on in someone else's inventory (or in >>> an object inventory). So we can't delete the underlying asset. >> >> Why not make an asset copy when one makes an inventory copy? Then >> delete the asset when deleted from inventory. Is each user having their >> own copy of many things a bigger problem? I guess this doesn't address >> one having out of ban knowledge of an assets UUID and expecting it to be >> there. Also, I accept that I may be missing some fundamental knowledge >> of how things work. Please be gentle :-) >> >> John. >> ___ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] oddities with asset storage
Making a copy is the greater evil. With implicitly shared assets, only content creators create assets. With asset copying, each sale/give creates assets. Take SL: I make a clothing item. I have to make 18 uploads (creating 18 assets) to finally use 2 of the uploaded textures. I have also created 36 wearable assets through this. Then i put that item for sale. 2000 users buy it. With implicitly shared assets, assets consumed: 18 texture, 36 wearable. With asset copying, assets consumed: 4001 texture, 4003 wearable See, the point of diminishing returns for copying is very close. Melanie John Ward wrote: > Justin Clark-Casey wrote: >> The problem is that you may have given that item to somebody else. >> Giving an item does not make an asset copy, it just makes an >> inventory item copy (both inventory items still point towards the >> same asset). >> >> So you may delete your item, but we don't know if the asset >> referenced by that item lives on in someone else's inventory (or in >> an object inventory). So we can't delete the underlying asset. > > Why not make an asset copy when one makes an inventory copy? Then > delete the asset when deleted from inventory. Is each user having their > own copy of many things a bigger problem? I guess this doesn't address > one having out of ban knowledge of an assets UUID and expecting it to be > there. Also, I accept that I may be missing some fundamental knowledge > of how things work. Please be gentle :-) > > John. > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] oddities with asset storage
Justin Clark-Casey wrote: > The problem is that you may have given that item to somebody else. > Giving an item does not make an asset copy, it just makes an > inventory item copy (both inventory items still point towards the > same asset). > > So you may delete your item, but we don't know if the asset > referenced by that item lives on in someone else's inventory (or in > an object inventory). So we can't delete the underlying asset. Why not make an asset copy when one makes an inventory copy? Then delete the asset when deleted from inventory. Is each user having their own copy of many things a bigger problem? I guess this doesn't address one having out of ban knowledge of an assets UUID and expecting it to be there. Also, I accept that I may be missing some fundamental knowledge of how things work. Please be gentle :-) John. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] oddities with asset storage
We can't step away from SL compatibility until there is a full-featured, viable viewer, preferably not based on Linden Labs code. Until then, the viewer's asset caching mechanism make that impossible. Melanie Dirk Krause wrote: > ... > >>> This would mean that any grid runs into a severe problem over time. > >>> Yep :). On a standalone one could implement some cleanup scheme > which checks everything to see >>> if an asset is still referenced, and deletes that asset if it is not. >>> In grid mode this is a much more difficult problem since references > are scattered across many different >>> regions servers. The situation is even worse if you are running a > grid where not all of them are >>> guaranteed to be connected. > > But isn't that ... horrible? (in lack of a better/worse word.) > > As I said yesterday, IMHO there is no real need to think about > optimizations when you have > a serious blocker like this. I would even go so far that this is a major > roadblock for grid based technologies per se. (grid as in Rosedale's > 'Happily now, Second Life has been proven to exist. If we disappeared > tomorrow, the grid would be rebuilt by you.') > > I take it the bad news is that any proposed solution to this breaks SL > compatibility? > > Maybe now would be a good time to take a step away from it. > > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] oddities with asset storage
All you described is design behavior.
Prim items in world are not assets. They are stored exclusively in
the prims tables of the region.
Once taken, they become an asset. The name is totally meaningless,
it reflects whatever was the name at creation. Nothing else. It
never changes from there on.
On deleting the inventory item, assets remain. There is no easy or
practicable way to conclusively say that an asset is trash, because
we don't know.
In your test case, your (human) mind could know this for a fact,
however, the silicon mind of the asset server can't.
This is because you may have given the object to another user, or
put a copy into a prim.
These copies would refer to the same asset, that is what "implictily
shared" means.
So, any asset may, at any time, have any number of links to it, even
zero.
Like a website, you don't know who linked to it. If you remove it,
you leave dead links. Assets are the same. Except, you get "Asset
missing from database".
So, assetas are NOT 1-to-1 with inventory items, and they _never_
get deleted.
They have to be reaped, and there is a big discussion over how to
best do that, running right now.
Melanie
Dirk Krause wrote:
> Hi,
>
> I did a little test with a fresh OpenSim installation (yes, thanks for
> the installer!),
> to get a grip on what I learned from Melanie yesterday.
>
> I wrote a little python script to help me monitor these tables:
> inventoryStore/inventoryItems
> assetStorage/assets
> http://pastebin.com/mc9e6574 , be warned: ugly code.
>
> I started OpenSim and logged in a 'Test User' with the SL viewer.
>
> (Just to mention it - first time log in in as test users creates
> 4 'blank' entries in assets.)
>
> The inventoryItems table was initially empty.
>
> Now I rezzed a cube and renamed it to 'p1'.
> inventoryStore/inventoryItems was still empty.
> To my surprise no new entry shows up in assetStorage/assets.
>
> Picking up the cube ('take') created an entry named 'p1' in the
> inventory and in the asset table.
>
> Now I renamed the cube in Test Users inventory to 'p2'.
> The name in inventoryStore/inventoryItems changes to 'p2'.
> The entry in assetStorage/assets stays 'p1'. As mentioned on the list
> before,
> the asset name is useless, since the user only sees the name in the
> inventory.
>
> Now I deleted 'p2' in my inventory - 'p2's parentfolderID changes to
> 'Trash'.
> Now I emptied the trash - the inventory table is empty again, which is
> fine,
> but here's the big one:
>the assetStorage/assets still holds the reference to 'p1'.
>
> Just to make sure I shut down the simulator and opened it again, and it
> was still there.
>
> Now, doesn't that mean, that the database increases over time with no
> hope to find
> these assets that actually should be gone? or is there some magic
> purging that happens,
> and that I missed?
>
> This would mean that any grid runs into a severe problem over time.
>
> Best,
> Dirk/Bart
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
NHibernate has, in tests, been significantly slower than native implementations. Melanie Antti Kokko wrote: > Trying to catch up but anyway what I think in general is that the whole > database schema is not the best in terms of coherence, associations etc. For > me it seems that at first came all functionality and them came the database > solutions. The structure feels is "broken" but I understand it because of > grid mode etc. > > What I`d like to see is simply one db solution which covers mysql, mssql and > sqlite and that is most propably NHibernate. Why do all the updates to all > interface implementing classes instead of doing it only in one place. I > think this could save some serious time. > > However I try to get to the asset discussion: > > First of all I really like the way of Cable Beach and truly hope this all is > going to distributed asset system. One of the biggest issues is cache, > external cache etc. If we have e.q. publisher who wants to update an object > in Cable Beach which is already used in sim1 and sim2, how we send the > update to all caches? How I have understood it the current system is a kind > of trade-off and actually new object is created instead of updating the > existing one. On the database side I`d definitely like to see not a new > object but an update. What I`ve heard the cache issues are long discussed > and not easy to resolve and we definitely need a further discussion about > along with Cable Beach or any distributed asset system. After all why I > couldn`t have an apache web server somewhere where my asset, avatar, avatar > appearance are. > > Having several asset storages distributed all over the web we need an UUID > for the asset but we are going to need of course an URL as key too. That is > definitely one issue. > > Best, > > - Antti > > 2009/2/17 Charles Krinke > >> Dear Teravus: >> >> No problem. The key point I was trying to make is that as time goes on we >> seem to be increasing exponentially the storage requirements in the UGAIM >> assets table. The terrainImage entry was an example of of an 'asset' that is >> a little different in perception then say, a texture covering a face of a >> prim. >> >> This example was intended for us to think about those 'assets' which can be >> pruned on a regular basis so that our ability from the UGAIM viewpoint to >> find and retrieve an asset in a timely manner does not get so long as to >> make our sims performance degraded. >> >> Charles >> >> -- >> *From:* Teravus Ovares >> *To:* opensim-dev@lists.berlios.de >> *Sent:* Tuesday, February 17, 2009 6:39:52 AM >> *Subject:* Re: [Opensim-dev] Please do not revert fixes without careful >> comtemplation >> >> I thought it prudent to point out that the following statement is 100% >> fiction; >> >> " 2. We have a significant number of assets of each and every edit of >> terrain, where only the very last one is accessible" >> >> What I think you meant to say was, >> >> "2. Every two days each region generates a new map tile image and >> names it terrainImage. These do eventually add up" >> >> Best Regards >> >> Teravus >> >> On Tue, Feb 17, 2009 at 9:31 AM, Stefan Andersson >> wrote: >> > >> >> > 1. We have a significant number of assets whose name is "blank" that >> are >> >> > created with a default constructor. And I suspect are never >> accessible. >> >> >> >> In fact, this field has always seemed redundant to me since the user >> only >> >> ever manipulates assets by their inventory >> >> name, which is entirely separate from the asset name. The asset name is >> >> never visible to the user (and afaik is not >> >> used anywhere else in the code). >> >> >> >> At one point I thought about proposing to remove it. Possibly this issue >> >> should be revisited. >> > >> > I believe it's kept there just as a convenience - to be able to get some >> > kind of semantics, not necessarily exact, when browsing the table. >> > >> >> > 2. We have a significant number of assets of each and every edit of >> >> > terrain, where only the very last one is accessible. >> >> >> >> Yes, this does seem wasteful to me since old terrain assets are not used >> >> by anything, afaik. >> > >> > I have proposed a number of times that we could have a virtual asset_key >> as >> > well as an asset_id - so that things that would rewrite assets could use >> the >> > asset_key as an aux method to actually try to overwrite the asset. In the >> > terrain case, the asset would be overwritten by key, not by id. This >> would >> > allow us to implement a number of parallell schemas where some assets >> would >> > be overwritten (asset_key = asset_id) and some where we would keep a >> history >> > (only asset_key) and some where doing either or would be configurable. >> > >> >> > 3. We have a significant number of assets of each and every text edit >> >> > for each and every textual assets. Where only the last one should be >> >> > accessible. >> >> >> >> Unfortunatel
Re: [Opensim-dev] oddities with asset storage
+1 asset storage providers again. Trying to avoid one unideality causes
usually another unideality to occur. In this case immutable assets cause
uncontrollable growth in asset storage systems. It would be better to do
something like Dirk suggests and accept that sometimes something what is
referenced gets deleted. If you want to avoid this use textures from
providers who quarantee to keep them available or host them in your own
service provider.
regards,
Tommi
On Wed, Feb 18, 2009 at 7:33 PM, Dirk Krause wrote:
> Glad you asked :-).
>
> I would do a mixture of the following (and admit that I didn't think it all
> through to the very end).
>
> - introduce grid wide, region wide and personal (user) asset domains
> - introduce quotas for these
> - allow clones ('byref') assets, and copies that go into one of the
> domains, resp.
>
> I then would expect to have grid wide assets that are 'always on', region
> wide assets that only are important when the region is connected, and
> personal assets that are only visible when the user is online (could even be
> an FTP server behind a cable beach server).
>
> It boils down to: if someone treasures something, she better keeps it in
> her treasure chest, in her responsibility (and maintenance cost).
>
>
> -Ursprüngliche Nachricht-
> Von: opensim-dev-boun...@lists.berlios.de [mailto:
> opensim-dev-boun...@lists.berlios.de] Im Auftrag von Dr Scofield
> Gesendet: Mittwoch, 18. Februar 2009 17:41
> An: opensim-dev@lists.berlios.de
> Betreff: Re: [Opensim-dev] oddities with asset storage
>
> Dirk Krause wrote:
> > ...
> [...]
> >
> > But isn't that ... horrible? (in lack of a better/worse word.)
> >
> > As I said yesterday, IMHO there is no real need to think about
> > optimizations when you have
> > a serious blocker like this. I would even go so far that this is a major
> > roadblock for grid based technologies per se. (grid as in Rosedale's
> > 'Happily now, Second Life has been proven to exist. If we disappeared
> > tomorrow, the grid would be rebuilt by you.')
> >
> > I take it the bad news is that any proposed solution to this breaks SL
> > compatibility?
> >
> > Maybe now would be a good time to take a step away from it.
>
> so, what do you supposed should be done? ride OpenSim on web route 404?
> lots of
> dangling references?
>
> i supposed on a standalone system you could do ref counting or
> bidirectional
> refs/links --- that however is not a very scalable solution for a grid with
> sporadically connected grid components.
>
> one avatar's garbage is another avatar's treasure...
>
>DrS/dirk
>
>
> --
> dr dirk husemann virtual worlds research ibm zurich research lab
> SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/
> RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] oddities with asset storage
Glad you asked :-).
I would do a mixture of the following (and admit that I didn't think it all
through to the very end).
- introduce grid wide, region wide and personal (user) asset domains
- introduce quotas for these
- allow clones ('byref') assets, and copies that go into one of the domains,
resp.
I then would expect to have grid wide assets that are 'always on', region wide
assets that only are important when the region is connected, and personal
assets that are only visible when the user is online (could even be an FTP
server behind a cable beach server).
It boils down to: if someone treasures something, she better keeps it in her
treasure chest, in her responsibility (and maintenance cost).
-Ursprüngliche Nachricht-
Von: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Dr Scofield
Gesendet: Mittwoch, 18. Februar 2009 17:41
An: opensim-dev@lists.berlios.de
Betreff: Re: [Opensim-dev] oddities with asset storage
Dirk Krause wrote:
> ...
[...]
>
> But isn't that ... horrible? (in lack of a better/worse word.)
>
> As I said yesterday, IMHO there is no real need to think about
> optimizations when you have
> a serious blocker like this. I would even go so far that this is a major
> roadblock for grid based technologies per se. (grid as in Rosedale's
> 'Happily now, Second Life has been proven to exist. If we disappeared
> tomorrow, the grid would be rebuilt by you.')
>
> I take it the bad news is that any proposed solution to this breaks SL
> compatibility?
>
> Maybe now would be a good time to take a step away from it.
so, what do you supposed should be done? ride OpenSim on web route 404? lots of
dangling references?
i supposed on a standalone system you could do ref counting or bidirectional
refs/links --- that however is not a very scalable solution for a grid with
sporadically connected grid components.
one avatar's garbage is another avatar's treasure...
DrS/dirk
--
dr dirk husemann virtual worlds research ibm zurich research lab
SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] oddities with asset storage
Dirk Krause wrote: > ... [...] > > But isn't that ... horrible? (in lack of a better/worse word.) > > As I said yesterday, IMHO there is no real need to think about > optimizations when you have > a serious blocker like this. I would even go so far that this is a major > roadblock for grid based technologies per se. (grid as in Rosedale's > 'Happily now, Second Life has been proven to exist. If we disappeared > tomorrow, the grid would be rebuilt by you.') > > I take it the bad news is that any proposed solution to this breaks SL > compatibility? > > Maybe now would be a good time to take a step away from it. so, what do you supposed should be done? ride OpenSim on web route 404? lots of dangling references? i supposed on a standalone system you could do ref counting or bidirectional refs/links --- that however is not a very scalable solution for a grid with sporadically connected grid components. one avatar's garbage is another avatar's treasure... DrS/dirk -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] oddities with asset storage
Um. Having immutable assets do bring a number of optimization shortcuts. I'm not saying it's all good - merely that it's not all bad. The OpenSim solution, as always, is to address each case by itself, and to make divergence optional. So, maybe region map textures should be overwriteable. Maybe some scripts should be overwriteable as well, maybe only on some type of scripts. Maybe we should have a table enumerating what assetIds now point to newer assetIds. Maybe the real problem is that we are talking about 'assets' and 'textures' instead of 'prim face textures', 'sculptie maps', 'photos', 'region map images', 'script sources', 'sounds', 'prims in inventory', 'notecards', 'animations' - my point being that we can probably implement various configurable strategies for each of them, linden viewer or no linden viewer. Best regards, Stefan Andersson Tribal Media AB > Date: Wed, 18 Feb 2009 16:37:12 +0100 > From: dirk.kra...@pixelpark.com > To: opensim-dev@lists.berlios.de > Subject: Re: [Opensim-dev] oddities with asset storage > > ... > > >> This would mean that any grid runs into a severe problem over time. > > >> Yep :). On a standalone one could implement some cleanup scheme > which checks everything to see > >> if an asset is still referenced, and deletes that asset if it is not. > >> In grid mode this is a much more difficult problem since references > are scattered across many different > >> regions servers. The situation is even worse if you are running a > grid where not all of them are > >> guaranteed to be connected. > > But isn't that ... horrible? (in lack of a better/worse word.) > > As I said yesterday, IMHO there is no real need to think about > optimizations when you have > a serious blocker like this. I would even go so far that this is a major > roadblock for grid based technologies per se. (grid as in Rosedale's > 'Happily now, Second Life has been proven to exist. If we disappeared > tomorrow, the grid would be rebuilt by you.') > > I take it the bad news is that any proposed solution to this breaks SL > compatibility? > > Maybe now would be a good time to take a step away from it. > > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] oddities with asset storage
... >> This would mean that any grid runs into a severe problem over time. >> Yep :). On a standalone one could implement some cleanup scheme which checks everything to see >> if an asset is still referenced, and deletes that asset if it is not. >> In grid mode this is a much more difficult problem since references are scattered across many different >> regions servers. The situation is even worse if you are running a grid where not all of them are >> guaranteed to be connected. But isn't that ... horrible? (in lack of a better/worse word.) As I said yesterday, IMHO there is no real need to think about optimizations when you have a serious blocker like this. I would even go so far that this is a major roadblock for grid based technologies per se. (grid as in Rosedale's 'Happily now, Second Life has been proven to exist. If we disappeared tomorrow, the grid would be rebuilt by you.') I take it the bad news is that any proposed solution to this breaks SL compatibility? Maybe now would be a good time to take a step away from it. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] oddities with asset storage
Dirk Krause wrote:
> Hi,
>
> I did a little test with a fresh OpenSim installation (yes, thanks for
> the installer!),
> to get a grip on what I learned from Melanie yesterday.
>
> I wrote a little python script to help me monitor these tables:
> inventoryStore/inventoryItems
> assetStorage/assets
> http://pastebin.com/mc9e6574 , be warned: ugly code.
>
> I started OpenSim and logged in a 'Test User' with the SL viewer.
>
> (Just to mention it - first time log in in as test users creates
> 4 'blank' entries in assets.)
>
> The inventoryItems table was initially empty.
>
> Now I rezzed a cube and renamed it to 'p1'.
> inventoryStore/inventoryItems was still empty.
> To my surprise no new entry shows up in assetStorage/assets.
Rezzing an object in a region does not involve the creation of any new assets -
all the data is stored in unserialized
form in columns in the region database.
>
> Picking up the cube ('take') created an entry named 'p1' in the
> inventory and in the asset table.
The asset you see is the serialized object pointed to by your inventory item
entry.
>
> Now I renamed the cube in Test Users inventory to 'p2'.
> The name in inventoryStore/inventoryItems changes to 'p2'.
> The entry in assetStorage/assets stays 'p1'. As mentioned on the list
> before,
> the asset name is useless, since the user only sees the name in the
> inventory.
Exactly.
>
> Now I deleted 'p2' in my inventory - 'p2's parentfolderID changes to
> 'Trash'.
> Now I emptied the trash - the inventory table is empty again, which is
> fine,
> but here's the big one:
>the assetStorage/assets still holds the reference to 'p1'.
Exactly.
>
> Just to make sure I shut down the simulator and opened it again, and it
> was still there.
>
> Now, doesn't that mean, that the database increases over time with no
> hope to find
> these assets that actually should be gone? or is there some magic
> purging that happens,
> and that I missed?
The problem is that you may have given that item to somebody else. Giving an
item does not make an asset copy, it just
makes an inventory item copy (both inventory items still point towards the same
asset).
So you may delete your item, but we don't know if the asset referenced by that
item lives on in someone else's inventory
(or in an object inventory). So we can't delete the underlying asset.
>
> This would mean that any grid runs into a severe problem over time.
Yep :). On a standalone one could implement some cleanup scheme which checks
everything to see if an asset is still
referenced, and deletes that asset if it is not.
In grid mode this is a much more difficult problem since references are
scattered across many different regions servers.
The situation is even worse if you are running a grid where not all of them
are guaranteed to be connected.
>
> Best,
> Dirk/Bart
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
--
justincc
Justin Clark-Casey
http://justincc.wordpress.com
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] oddities with asset storage
Hi,
I did a little test with a fresh OpenSim installation (yes, thanks for
the installer!),
to get a grip on what I learned from Melanie yesterday.
I wrote a little python script to help me monitor these tables:
inventoryStore/inventoryItems
assetStorage/assets
http://pastebin.com/mc9e6574 , be warned: ugly code.
I started OpenSim and logged in a 'Test User' with the SL viewer.
(Just to mention it - first time log in in as test users creates
4 'blank' entries in assets.)
The inventoryItems table was initially empty.
Now I rezzed a cube and renamed it to 'p1'.
inventoryStore/inventoryItems was still empty.
To my surprise no new entry shows up in assetStorage/assets.
Picking up the cube ('take') created an entry named 'p1' in the
inventory and in the asset table.
Now I renamed the cube in Test Users inventory to 'p2'.
The name in inventoryStore/inventoryItems changes to 'p2'.
The entry in assetStorage/assets stays 'p1'. As mentioned on the list
before,
the asset name is useless, since the user only sees the name in the
inventory.
Now I deleted 'p2' in my inventory - 'p2's parentfolderID changes to
'Trash'.
Now I emptied the trash - the inventory table is empty again, which is
fine,
but here's the big one:
the assetStorage/assets still holds the reference to 'p1'.
Just to make sure I shut down the simulator and opened it again, and it
was still there.
Now, doesn't that mean, that the database increases over time with no
hope to find
these assets that actually should be gone? or is there some magic
purging that happens,
and that I missed?
This would mean that any grid runs into a severe problem over time.
Best,
Dirk/Bart
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] [Opensim-commits] r8437 - in trunk
Mike Mazur wrote: > Hi, > > I have just one comment on the below commit: > > > Could the extension point be renamed /OpenSim/AssetClient? > AssetServerClient seems strangely confusing, perhaps redundant :P Good call. I've sent the feedback on to Alan as I don't want to make that change directly lest it collide with his next patch. Expect it be be changed with the next patch. -Sean -- Sean Dague / Neas Bade sda...@gmail.com http://dague.net signature.asc Description: OpenPGP digital signature ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
