User:Babbage Linden/Office Hours/2009 08 19

Transcript of Babbage Linden's office hours:

[3:17]	Sebastean Steamweaver:	Hey Babbage
[3:17]	Sebastean Steamweaver:	First!
[3:17]	Morgaine Dinova:	It's Babbage!
[3:17]	Dimitris Peliatropis:	hi babbage
[3:17]	Babbage Linden:	hi everyone
[3:17]	Babbage Linden:	sorry i'm late
[3:17]	Aimee Trescothick:	hi :)
[3:17]	Morgaine Dinova:	Hiya Babbage, how goes?
[3:17]	Nock Forager:	hello Babbage.
[3:17]	Saijanai Kuhn woners if he'll have his next kernel panic before or after Babbage's office hours are done
[3:17]	Aimee Trescothick:	uh oh
[3:18]	Babbage Linden:	things are going well, thank you
[3:18]	Morgaine Dinova:	Aww, what's panicking Sai?
[3:18]	Sebastean Steamweaver:	How is Gisele doing Babbage? :)
[3:18]	Saijanai Kuhn:	8 in the past 24 hours. Very odd.
[3:18]	Aimee Trescothick talks soothingly to Sai's kernel to keep it calm
[3:18]	Babbage Linden:	i've spent a lot of time talking to gisele about where we are and various issues and plans
[3:18]	Morgaine Dinova:	lol
[3:18]	Babbage Linden:	she's still drinking from the firehose :-D
[3:18]	Xugu Madison:	hey Babbage
[3:18]	Sebastean Steamweaver:	Hehe
[3:18]	Sebastean Steamweaver:	Were you able to go through those JIRAs with her?
[3:19]	Babbage Linden:	not yet, but i will do sebastean
[3:19]	Xugu Madison:	Tip for everyone. Making coffee with soy milk is troublingly difficult. Seems to want to react if the coffee is just a liiiiitle too hot
[3:19]	Sebastean Steamweaver:	Soy milk does strange things no matter what you put it in.
[3:19]	Babbage Linden:	they are potentially easy wins that we can work on before starting the C#, IDE, libraries roadmap
[3:19]	Babbage Linden:	but we'll see
[3:19]	Sebastean Steamweaver:	And somehow, the product always results in X + hay flavor.
[3:19]	Xugu Madison:	Today, I'd like llDrop() please
[3:20]	Morgaine Dinova:	Babbage: from observation freelance around UK industry, product managers tend to be an utter disaster, continually introducing nonsense and noise into the dev and release process. I hope Gisele is better than average :-)
[3:20]	Babbage Linden:	as well as helping bring gisele up to speed we've been working on the script limits ui support
[3:20]	Sebastean Steamweaver:	I hope that they are Babbage :) That would make me one extremely happy person. And many, many other people as well.
[3:20]	Babbage Linden:	there are a number of boundaries cases that we're working to clarify
[3:21]	Morgaine Dinova:	"UI support" means the API to the UI for it? Presumably you don't work on the actual viewer.
[3:21]	Babbage Linden:	for example, sitting on vehicles is complicated when working with resource pools
[3:21]	Babbage Linden:	so we're adding test plan cases for those
[3:22]	Babbage Linden:	when you rez a vehicle it uses the parcel pool
[3:22]	Babbage Linden:	(as there is no way to determine it is a vehicle)
[3:22]	Babbage Linden:	when you sit on it, it still uses the parcel pool
[3:22]	Babbage Linden:	(it might be a chair)
[3:23]	Babbage Linden:	then when you drive over a parcel boundary it first tries to use the attachment pool of a sitting avatar
[3:23]	Babbage Linden:	if it can't it will try to use the new parcel pool
[3:23]	Babbage Linden:	if it can't do that it will block the movement
[3:23]	Babbage Linden:	if it can't do that (due to region crossing) it will return the vehicle
[3:24]	Babbage Linden:	the goal is to try to avoid people on vehicles hitting invisible walls or having their vehicle returned as much as possible
[3:24]	Morgaine Dinova:	What other pool exist, other than parcel pool?
[3:24]	Morgaine Dinova:	pools*
[3:24]	Babbage Linden:	but it makes the logic complex
[3:24]	Babbage Linden:	and I don't think those semantics currently work quite right with urls
[3:25]	Babbage Linden:	if you could check that would be great
[3:25]	Babbage Linden:	morgaine, the only other pools are attachment pools
[3:25]	Babbage Linden:	which are a fixed size for every avatar
[3:25]	Xugu Madison:	"work quite right with urls" - hangon, where did URLs get into this?
[3:26]	Babbage Linden:	script urls were the first clients of the script resource pools
[3:26]	Babbage Linden:	so, if you want to find out how memory limits are going to work
[3:26]	Morgaine Dinova:	Aha, so that people can still use their attachments despite the parcel having no spare resource, I guess.
[3:26]	Xugu Madison:	Ah!
[3:26]	Babbage Linden:	write a quick script that reports available urls
[3:27]	Babbage Linden:	then kick it around different parcels, attach, it, detach it, sit on it with a friend and move it around ;-)
[3:27]	Babbage Linden:	then give me feedback on where it doesn't work as you'd expect :-D
[3:27]	Babbage Linden:	the basic behaviour, is that things in world use their current parcel pool
[3:27]	Babbage Linden:	which gives you N KB per m^2
[3:28]	Babbage Linden:	scripts attached to avatars use the avatar attachment pool
[3:28]	Babbage Linden:	which is going to be a fixed size for all avatars
[3:29]	Babbage Linden:	so, the total script memory available in a region is going to be memory_per_m_sq * 256 * 256 + memory_per_av * av_limit
[3:29]	Babbage Linden:	the other complex bounary cases were looking at are rezzing/derezzing scripts
[3:30]	Babbage Linden:	(which is complex as we have to store the urls and memory required in the inventory item then check it's available or block rez)
[3:30]	Morgaine Dinova:	But if something is rezzed in-world and uses resources from the current parcel's parcel pool, and then it's moved a tiny distance into the adjacent parcel, does it retain its allocations from the previous parcel's parcel pool?
[3:30]	Babbage Linden:	and region boundary crossing
[3:30]	Babbage Linden:	(which is complex as we want to avoid having to build distributed transactions)
[3:31]	Babbage Linden:	morgaine, if something is rezzed in world and moves to a new parcel, it will try to switch its resource usage to the new parcel
[3:31]	Morgaine Dinova:	Eeeek
[3:31]	Morgaine Dinova:	Oh no!
[3:31]	Babbage Linden:	if it can't because the new parcel can't support it the movement will be blocked
[3:32]	Morgaine Dinova:	Region crossings are bad enough .... now there will be parcel crossings too?
[3:32]	Babbage Linden:	there have always been parcel crossings: if you move a scripted object in to a no script parcel it just dies
[3:32]	Saijanai Kuhn:	is there a reason to actually USE a parcel pool as opposed to merely notating it?
[3:32]	Babbage Linden remembers surina skalagrimsons fish lying dead on surrounding no script parcels
[3:32]	Saijanai Kuhn:	I guess that answers that question.
[3:33]	Babbage Linden:	not sure I follow you saijanai
[3:33]	Xugu Madison:	I would be tempted to have scripts use their home parcel's resources at least until they hit the sim edge
[3:33]	Morgaine Dinova:	Babbage: sure there have been parcel crossings, but there's a difference between a simple attribute like parcel ID and an allocation pool + migration handling.
[3:33]	Babbage Linden:	objects have no concept of a home parcel
[3:34]	Saijanai Kuhn:	well, if you're in the same sim, moving from one parcel to the other doesn't affect the physical location of the active scripts, so you could save time (maybe) by merely flagging that its part of Parcel A as opposed to Parcel B
[3:34]	Saijanai Kuhn:	though, I guess if you have to activate/deactivate scripts based on parcel location, you end up with the same deal as moving them from one sim to the other...
[3:35]	Babbage Linden:	where possible we're trying to implement script resource limits like prim limits
[3:36]	Babbage Linden:	which means that objects get their prim and memory resources from their parcel
[3:36]	Saijanai Kuhn:	OK, so its a physical thing rather than just a bunch of flags
[3:36]	Babbage Linden:	attachments are different as we want to improve on prim handling for non-parcel objects
[3:36]	Xugu Madison:	Also, any work on reducing script memory usage by adding functionality? Allowing sit offset and animation to be set as a prim attribute from the client UI, to avoid poseballs, for example?
[3:36]	Babbage Linden:	the vehicle pool + temp object pool + attachments don't count behaviour is pretty horrible for non-parcel prims
[3:37]	Babbage Linden:	xugu, we should do that in future yes
[3:37]	Babbage Linden:	if we're going to limit script memory we should also make it possible to script in a memory efficient way
[3:38]	Xugu Madison:	Or, just avoid scripts completely. Poseballs being the obvious example. Allow web service access to transaction logs (or ideally push them out) so vendors aren't needed for detailed reporting...
[3:38]	Babbage Linden:	scripts are nicely general purpose
[3:38]	Babbage Linden:	being able to support scripts rather than many special case behaviours is nice
[3:39]	Babbage Linden:	it makes second life turing complete
[3:39]	Babbage Linden:	it allows you all to build awesome stuff that we haven't thought off
[3:39]	Babbage Linden:	but, we need to make it efficient
[3:39]	Babbage Linden:	i agree
[3:39]	Xugu Madison:	Absolutely, but... I think scripts are overused for a lot of stuff that should be considered part of the client or server, not in addition to it...
[3:39]	Babbage Linden:	it's an interesting discussion, sure
[3:40]	Morgaine Dinova:	Sudden hard limits don't work well, they create cycles. Limiting resource utilization is extremely important, but you need to do it through negative feedback with a cost that's asymptotic to the limit, so that stuff doesn't just simply die. It's part of the "cost assignment" idea that I've been thrashing out with Andrew+Simon a lot, although the motivation there is mainly abuse control through automatic resource control. Simple limits where "bad things happen" aren't really a good way of doing it.
[3:40]	Babbage Linden:	it's also important to note that the first iteration of script limits is about visualising proposed limits
[3:40]	Babbage Linden:	rather than enforcing them
[3:40]	Babbage Linden:	i hope that we will have lots of useful productive discussion once we have make limits visible
[3:41]	Morgaine Dinova:	Hire a control engineer.
[3:41]	Babbage Linden:	where we can talk about how it's very inefficient to do X and we should add call Y to make it easier
[3:41]	Babbage Linden:	as well as use Z is perfectly reasonable and we should adjust the limits to allow it
[3:41]	Saijanai Kuhn:	I'm already seeing signs of that with certain packet calls, I think
[3:42]	Saijanai Kuhn:	FloatTextUpdate vs ObjectUpdate
[3:42]	Xugu Madison:	llReadNotecard(string notecard, function parser) would rock my world. One for C#, I suspect, alas
[3:43]	Babbage Linden:	morgaine, with memory it really is about limiting what is resident in sim memory
[3:43]	Babbage Linden:	slowing a big script down doesn't help, it still ends up sitting in memory causing the sim to page
[3:43]	Babbage Linden:	so, limiting what can be rezzed
[3:44]	Babbage Linden:	plus trying to avoid returning or stopping things that have already been rezzed is what we're trying to do here
[3:44]	Babbage Linden:	as well as following the prim model where we can to avoid multiple systems
[3:44]	Sebastean Steamweaver:	Well Babbage, I think a lot of us have already seen places where scripts can be much more efficient. The JIRAs I mentioned to you are among them.
[3:44]	Babbage Linden:	yes, and we should do that
[3:44]	Babbage Linden:	once we've made visualising usage possible
[3:44]	Babbage Linden:	measure before you optimize ;-)
[3:45]	Morgaine Dinova:	Yeah, but a sudden cut-off creates problem. Your only means of control becomes denial or even termination, but that just leads to further resource requests, so you end up busy-waiting at the limit point. If you applied cost accounting as a negative feedback then you wouln't hit the asymptote, you'd end up with graceful degradation instead.
[3:46]	Xugu Madison:	Being able to move messages to the user out of scripts, and into locale assets that are downloaded by the client, would also make a huge difference to memory...
[3:46]	Babbage Linden:	agreed, let's look in to that once we can talk about memory usage
[3:47]	Babbage Linden:	i'd like to have lots of discussions here that go "my script uses X memory, nearly all of it is because it needs to do this silly thing, let's fix that"
[3:47]	Sebastean Steamweaver:	So basically, everything is on hold until then?
[3:48]	Babbage Linden:	especially where the script in question is a widely used pattern
[3:48]	Babbage Linden:	well sebastean, things aren't on hold
[3:48]	Babbage Linden:	we're working on script limits ui support right now
[3:48]	Babbage Linden:	you can test the resource pools with urls right now
[3:48]	Babbage Linden:	the ui to visualise this stuff will be in viewer 2
[3:49]	Morgaine Dinova:	Is there a wiki page on that?
[3:49]	Babbage Linden:	the simulator support should be on aditi at the end of september
[3:49]	Sebastean Steamweaver:	Well, again, you don't necessarily need visible memory quantifications to be able to see what's being inefficient or taking up a lot of memory. Script systems that need to use hundreds of scripts currently to do what they do, is a pretty obvious example. And I'm not just pushing for that one JIRA, it's just a handy example.
[3:49]	Babbage Linden:	so you will be able to use curl to query memory usage via caps on aditi even before viewer 2
[3:49]	Babbage Linden:	yes i know
[3:50]	Morgaine Dinova:	How do we test the resource pools with URLs right now?
[3:50]	Xugu Madison:	Any ETA on viewer 2?
[3:51]	Babbage Linden:	we're unlikely to be working on new library calls until the end of the year earliest
[3:51]	Babbage Linden:	but next year should have a team working on the script roadmap
[3:51]	Babbage Linden:	that gisele is helping put togetehr#
[3:51]	Sebastean Steamweaver:	Viewer 2 = SL09 I'm guessing?
[3:51]	Babbage Linden:	yes
[3:51]	Babbage Linden:	morgaine, just make a script that calls http://wiki.secondlife.com/wiki/LlGetFreeURLs
[3:52]	Babbage Linden:	attach it to your head, see you attachment limit
[3:52]	Morgaine Dinova:	Thanks Babbage
[3:52]	Babbage Linden:	put it on the ground, see the parcel limit
[3:52]	Babbage Linden:	experiment with exhasuting urls and rezzing objects
[3:52]	Babbage Linden:	or sitting on the object and crossing boundaries
[3:52]	Babbage Linden:	both parcel and region boundaries
[3:52]	Babbage Linden:	let me know if you get any strange behaviour
[3:53]	Morgaine Dinova:	That's very cool. /me loves numbers
[3:53]	Babbage Linden:	we've also made some progress with the memory limit analysis
[3:53]	Babbage Linden:	xan has got some numbers for attachments, but i'm not sure I believe them
[3:53]	Morgaine Dinova:	Haha
[3:53]	Babbage Linden:	so i wanted to run them past you, see if you think they sound plausible
[3:55]	Babbage Linden:	hang on, just finding them
[3:56]	Babbage Linden:	so, according to xan's analysis, the median SL avatar has 100 scripts in their attachments and uses 780KB of scripts in those attachments
[3:57]	Morgaine Dinova:	Wow
[3:57]	Sebastean Steamweaver:	Is that just compiled size, or including actual processing memory used?
[3:57]	Saijanai Kuhn:	I'm not too surprised given what bling and prim animations require
[3:57]	Babbage Linden:	at the 90th percentile, avatars are using 2.8MB of attachment script and have 300 scripts attached
[3:57]	Babbage Linden:	and there is at least 1 avatar with 7612 attached scripts using 98MB of memory
[3:57]	Xugu Madison:	Do seem high, but not unbelievably so. Resizers and a few other things are HORRIFIC for requring a lot of scripts
[3:57]	Saijanai Kuhn:	ban him
[3:58]	Babbage Linden:	(that has to be a griefer and I bet they can't log in)
[3:58]	Sebastean Steamweaver:	Exactly Xugu ;)
[3:58]	Morgaine Dinova:	I'm seriously underscripted as a human av then, need to keep up with the Jones's.
[3:58]	Aimee Trescothick:	that sounds about what I'd expect
[3:58]	Babbage Linden:	morgaine, please don't!
[3:58]	Morgaine Dinova:	Haha
[3:58]	Saijanai Kuhn glances at his render cost of 1 and his zero sripted avatar
[3:58]	Aimee Trescothick:	well, the normal figure anyway
[3:58]	Babbage Linden:	it seems incredible to me
[3:58]	Morgaine Dinova:	Sai++
[3:59]	Sebastean Steamweaver:	I was about to say, a lot of that could be cut right off the bat with some some low-hanging fruit additions to the script system :P
[3:59]	Babbage Linden:	i only have a single script
[3:59]	Babbage Linden:	and i thought my arm was pretty blinging
[3:59]	Xugu Madison:	Just did a script count on myself. For wings (with HUD), jet pack, and AO: 9 scripts
[3:59]	Sebastean Steamweaver:	I bet with additions like llGet/SetObjectScale, you'd see those numbers drop significantly as people adopted it.
[3:59]	Babbage Linden:	so, everyone seems to think that's plausible?
[3:59]	Sebastean Steamweaver:	llSetLinkListPrimitiveParams is another big one. A lot of full-prim avatars, which are usually scripted, would need that.
[3:59]	Saijanai Kuhn:	client side scripting for certain things would reduce the number of scripts I would think
[4:00]	Aimee Trescothick:	yeah, just from observing the number of scripts in some multitool huds though it's probably not far off the mark, especially when you add a weapon or two with show/hide scripts in every prim
[4:00]	Xugu Madison nods "Yup, sounds plausible"
[4:00]	Morgaine Dinova:	Babbage: have you considered raising the feature set of the basic av? People don't necessarily *WANT* to stress test your platform --- it's just that the native av feature set is butt ugly.
[4:00]	Babbage Linden:	zomg
[4:00]	Sebastean Steamweaver:	With the way we currently need to control things like attachments, yes, I see that as being plausible. I can even think of a few cases thatwould probably be examples.
[4:00]	Babbage Linden:	well, ok, i think this makes it clear that we need script limits :-D
[4:00]	Aimee Trescothick:	heh
[4:00]	Babbage Linden:	but also more efficient ways of scripting
[4:00]	Aimee Trescothick:	totallty
[4:00]	Babbage Linden:	we're having lots of teleport failures currently due to avatar size
[4:01]	Xugu Madison:	I still think https://jira.secondlife.com/browse/SVC-4270 covers this well :)
[4:01]	JIRA-helper: [#SVC-4270] We DESPERATELY need llGetLinkPrimitiveParams
[4:01]	Sebastean Steamweaver:	"LindenLabs is going to be introducing scripting limits that could drastically effect items we use every day from resizers, to the HUDS that color our attachments. In order to compensate for this and do our part to help reduce server load to increase performance, scripters need better and more efficient tools to work with."
[4:01]	Sebastean Steamweaver:	The intro to my "Want to help make SL better" notecard :P
[4:01]	Babbage Linden:	so, sebastean, both are needed
[4:01]	Aimee Trescothick:	just looked at mystitool, that has about 50 scripts in to start with
[4:02]	Babbage Linden:	if we just made scripting more efficient
[4:02]	Babbage Linden:	then we'd just accelerate the bling arms race
[4:02]	Dimitris Peliatropis:	sorry everyone, gotta go
[4:02]	Babbage Linden:	people would end up using the same resources, but for even more bling
[4:02]	Xugu Madison:	See you Dimitris!
[4:02]	Dimitris Peliatropis:	babbage did you get my message?
[4:02]	Babbage Linden:	and some people wouldn't bother being efficient, so why would they
[4:02]	Sebastean Steamweaver:	Making scripting more efficient would help some, but I can see how management would also help. As Kelly said, we could reduce script numbers and even processing needed by allocating enough memory to just one script.
[4:02]	Babbage Linden:	we need limits and efficient ways to script
[4:02]	Xugu Madison:	I'm not sure they would, I don't think they're holding back because it's getting slow, I think they're loosely where they want to be
[4:03]	Babbage Linden:	to solve lag and memory usage problems
[4:03]	Aimee Trescothick:	a lot of it is going to be things using multiple scripts to get around script delays
[4:03]	Sebastean Steamweaver:	You will always have people like that Babbage. You can't make the ceiling so low that those who -would-script efficiently bang their heads every time they try to do something that's complex, but responsible :)
[4:03]	Babbage Linden:	right, script delays are a completely broken way of doing limits
[4:03]	Aimee Trescothick:	he
[4:03]	Aimee Trescothick:	*heh
[4:03]	Babbage Linden:	they just make scripts more complex as people work round them
[4:03]	Sebastean Steamweaver:	Exactly
[4:04]	Babbage Linden:	and they result in more memory usage and lag as a result
[4:04]	Babbage Linden:	not less
[4:04]	Xugu Madison:	Oh, yes, certainly you need limits even just to keep the platform stable, but I think letting us fix things first would be nice :)
[4:04]	Sebastean Steamweaver:	I am right along with Xugu.
[4:04]	Babbage Linden:	we should only be throttling calls that create external load
[4:04]	Babbage Linden:	like httprequest
[4:04]	Babbage Linden:	which cause problems unthrottled
[4:04]	Sebastean Steamweaver:	I think you'll get a far -Clearer- picture of what exactly needs to be done, if you first give us better tools to work with, and see how that impacts the current state.
[4:04]	Morgaine Dinova:	Although the "arms race" thing is evidently true, if you provided a basic human av that people weren't embarrassed to use, you'd find much less interest in high cost attachments and massive scripting.
[4:05]	Morgaine Dinova:	The basic av feature set hasn't kept pace.
[4:05]	Babbage Linden:	right, well that's not my department morgaine ;-)
[4:05]	Babbage Linden:	anyway, we're over time, I should go do some work
[4:05]	Xugu Madison:	Thanks for hosting Babbage!
[4:05]	Morgaine Dinova:	But you're suffering the consequences :-))))
[4:05]	Saijanai Kuhn:	take care babbage
[4:05]	Sebastean Steamweaver:	Give us a chance to do our part before you limit things, and then you'll be better able to see where the limit needs to be set.
[4:06]	Sebastean Steamweaver:	Take care babbage, thanks for the hours:)
[4:06]	Morgaine Dinova:	Cyu Babbage, have a good day :-)
[4:06]	Babbage Linden:	please play with http://wiki.secondlife.com/wiki/LlGetFreeURLs and let me know if there are any unexpected corner cases
[4:06]	Nock Forager:	Thansk Bababge, see you around.
[4:06]	Babbage Linden:	i don't think the boundary conditions have been sufficiently explored yet
[4:06]	Babbage Linden:	see you all next time
[4:06]	Morgaine Dinova:	Will do, cool, TC :-)
[4:06]	Sebastean Steamweaver:	Take care :)