[sldev] [ARCH] Render unto Caesar the things that are Caesar's

Nik Radford nik at terminaldischarge.net
Tue Sep 18 14:55:48 PDT 2007


----- Original Message ----- 
From: "Mike Monkowski" <monkowsk at watson.ibm.com>
To: "Jason Giglio" <gigstaggart at gmail.com>
Cc: <sldev at lists.secondlife.com>
Sent: Tuesday, September 18, 2007 10:50 PM
Subject: Re: [sldev] [ARCH] Render unto Caesar the things that are Caesar's


> Jason Giglio wrote:
>> Agents wear a load of scripts, usually much more than there are scripts 
>> in fixed objects in a sim.  I've seen agents taking up 5+ms of script 
>> time.
>
> That's a good reason for having Avatar Hosts.  I understand though that 
> performance is expected to improve dramatically when scripting goes to 
> Mono.  Don't know when that's planned though.
>
>>> By network load do you mean sim-to-sim or viewer-to-sim?  If the latter, 
>>> then it would mean in the new architecture we shouldn't have 
>>> communication directly with the Region Hosts if we want to allow more 
>>> avatars per sim.  Yes?
>>
>>
>> sim-to-viewer mainly.  And it's things like objectupdates that really the 
>> sim needs to handle.  If you offload it you just move the load to the 
>> interdomain link, bogging it down.
>>
>> There's no silver bullet here to get more agents on a sim.
>
> I'm not sure where an interdomain link would be or what it would do, but 
> I'm guessing that your're saying that it's not really the number of 
> avatars but the number of changes in the scene, and more avatars tends to 
> mean more changes.  Maybe it's a matter of proximity dependent object 
> update rate.
Well as far as I know, a viewer is only sent object updates from the region 
host for the objects it is near. However, the region host itself has to 
update all objects all the time in memory in order to keep things 
consistant.

>
> Silver bullet?  No.  I never said it would be easy, but the population 
> limit is one of those limitations that's worth solving.
>
> Mike
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
> 



More information about the SLDev mailing list