Content Creation/Scripting User Group/Transcripts/2011 07 11

From Second Life Wiki
< Content Creation‎ | Scripting User Group‎ | Transcripts
Revision as of 10:55, 10 January 2012 by Kelly Linden (talk | contribs) (Created page with "== List of Speakers == {| |<font color=#b5005a><b>Ardy Lay</b></font> |- |<font color=#005ab5><b>flexi campfire</b></font> |- |<font color=#5a00b5><b>Leonel Iceghost</b></font> |…")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

List of Speakers

Ardy Lay
flexi campfire
Leonel Iceghost
Liisa Runo
Michelle Resistance


[09:03] Haravikk (haravikk.mistral): Heya Kelly!

[09:03] tehKellz (kelly.linden): Good morning.

[09:03] Harry vs the World (harry.gleeson): HeLlOoO!! <_>

[09:04] Ardy Lay: Your camel case is leaking into your voice, Harry.

[09:04] Harry vs the World (harry.gleeson): ?

[09:04] Ardy Lay:

[09:05] tehKellz (kelly.linden): We missed last week due to the 4th holiday here in the US. Hope everyone has had a good couple of weeks.

[09:05] Ardy Lay: He didn't have camel case to deal with but might have had fun with it.

[09:06] oobscure (opensource.obscure): having my Google Profile suspended because I'm using "Opensource Obscure" as a name it's not great - but that apart, I'm fine.

[09:06] oobscure (opensource.obscure): (details: )

[09:06] Michelle Resistance: So, what's on the menu for today? Triage, or open discussion, or what?

[09:06] tehKellz (kelly.linden): :-/

[09:07] tehKellz (kelly.linden): Today is the second Monday of the month so open discussion. Was giving a few minutes for stragglers but time to get started.

[09:08] tehKellz (kelly.linden): News first: Mono 2 upgrade/performance rolled out week before last. Last week was a 'no releases' week, which we made an exception for rolling back the mesh prep regions due to a crasher.

[09:08] tehKellz (kelly.linden): Performance on Homesteads in particular was really bad with the mono 2 release so we did a fix roll that Thursday. There are still issues though. :(

[09:09] Michelle Resistance: Not entirely surprising.

[09:09] tehKellz (kelly.linden): I've got some fixes, primarily for the less than great SimFPS in homesteads. Hope to get that onto RC this week. However there is another issue with individual script performance on full regions which I am still trying to track down.

[09:09] F L I P (flip.idlemind): In 20 words or less can you tell us what cause the performance problems, or is it not that simple?

[09:10] tehKellz (kelly.linden): There are multiple issues, I can go over each sure.

[09:10] F L I P (flip.idlemind): (The ones that you fixed)

[09:10] tehKellz (kelly.linden): The first was a timing issue. Instead of using the script time limit of a homestead, all regions (including homesteads) were using the time limit of a regular region. This killed performance across the host. This issue was fixed the Thursday after the roll.

[09:12] Michelle Resistance: Interesting.

[09:12] Kallista Arliss (kallista.destiny): Question, are homesteads sometimes hosted on the same physicial servers as regular regions?

[09:12] tehKellz (kelly.linden): After that fix there were still some rough edges on the script time that needed ironing out, primarily for homesteads. This is more vague, death of a thousand cuts kind of issue that happened because of our lack of homesteads in RCs (which we will be addressing hopefully this week).

[09:12] tehKellz (kelly.linden): Kallista: no.

[09:13] Kallista Arliss (kallista.destiny): snaps finger that might have explained some strange performance issues

[09:13] tehKellz (kelly.linden): I have a set of fixes ready for RC to smooth out the edges and give homesteads a solid SimFPS, better I think than they have had maybe ever.

[09:13] alternative doorbell shouts: Liisa Runo will come in

[09:14] tehKellz (kelly.linden): The last issue I really don't know the cause. We are hitting some performance cliff once there are more than X number of scripts in the region. I think X is 'how many scripts we can run in a single frame' but I'm still working on nailing it down exactly.

[09:15] Michelle Resistance: Do you have an idea of what this threshold value is?

[09:16] Ardy Lay: If scripts run in the time left after other things are don then that's gonna be a fun variable to track.

[09:16] Kallista Arliss (kallista.destiny): ~4000? wasnlt that the number mentioned by testing to use up all the time?

[09:17] tehKellz (kelly.linden): The number chnages based at least on the nature of the scripts.

[09:17] Kallista Arliss (kallista.destiny): 2µsec/script

[09:17] Qie (qie.niangao): number of *running* scripts, presumably, not merely resident

[09:17] tehKellz (kelly.linden): I think. Like I said, still working on it.

[09:17] tehKellz (kelly.linden): Qie: still working on it, but one would hope.

[09:17] Kallista Arliss (kallista.destiny): no Idle scripts use up time too

[09:18] Kallista Arliss (kallista.destiny): 2µsec/script was the overhead mentioned

[09:18] Michelle Resistance: Alright.

[09:18] Haravikk (haravikk.mistral): Is there no way to eliminate idle script time?

[09:18] Leonel Iceghost: any way to make idle scripts event driven?

[09:18] tehKellz (kelly.linden): Ah, yes, the 'top scripts' report is also getting some attention as idle scripts are appearing to use as much time as regular scripts. I think this may be the same bug, but it also might be some innaccuracy in the time monitoring we do.

[09:18] Kallista Arliss (kallista.destiny): WAG: A rewrite of the scheduler

[09:19] Ardy Lay: Schedulers spend processing time too.

[09:20] tehKellz (kelly.linden): It is complicated Leonel.

[09:20] Kallista Arliss (kallista.destiny): Nice understatement Kelly

[09:20] tehKellz (kelly.linden): :)

[09:22] tehKellz (kelly.linden): Essentially what we do is keep bitmasks of the events a script handles and the pending events. We do some checking every time the script gets a chance to run on those bitmasks to see if there is anything we need to do for some types of events. For other events we add them to a queue and so we check if a script has anything in queue and needs to run or not.

[09:22] tehKellz (kelly.linden): I'd guess that doesn't make anything clearer at all.

[09:23] Kaluura (kaluura.boa): That's clear to me...

[09:23] Michelle Resistance: Mostly parses.

[09:23] Kallista Arliss (kallista.destiny): Actually it does make it clearer

[09:23] Leonel Iceghost: why not allow scripts to put themselves in the queue?

[09:24] tehKellz (kelly.linden): To some extent we used to do that a very long time ago, when there was a larger distinction between 'idle' and 'running' scripts. It turns out managing that queue took enough time and added enough complexity to really not be worth it.

[09:25] tehKellz (kelly.linden): Many scripts needed to always be active, and we'd get bugs whenever some script should be getting on the active list but wasn't.

[09:25] Kallista Arliss (kallista.destiny): Idle and running is determined by behaivior and changes from frame to frame

[09:25] tehKellz (kelly.linden): now we keep them all in the same queue, but early exit / continue as soon as we can determine there is nothing to do.

[09:26] Kallista Arliss (kallista.destiny): idle is waiting for some event, running is actually consuming CPU time

[09:26] Haravikk (haravikk.mistral): Is it not possible to optimise the case where a script has a pending bitfield that doesn't match what it can run, and only schedule it if that bitmap changes?

[09:26] tehKellz (kelly.linden): haravikk: yes, we do that. We don't add events to a queue if the script doesn't handle that event

[09:27] Michelle Resistance: { I would presume each script has a mask for what events it handles. }

[09:27] tehKellz (kelly.linden): yes.

[09:27] Kallista Arliss (kallista.destiny): Ahhhhhhh so you should bit put an empty event handler on a script?

[09:27] Kallista Arliss (kallista.destiny): should not.

[09:27] tehKellz (kelly.linden): not a great idea.

[09:27] Kallista Arliss (kallista.destiny): nods

[09:27] Haravikk (haravikk.mistral): But if it has no events pending, what then? Is it still checked? Surely it'd be easy enough to remove it from the scheduler until a new event comes along?

[09:28] Kallista Arliss (kallista.destiny): runs of to rewriet a buch of scripts

[09:28] Ardy Lay: I miss working with interupts and their vectors. ;-)

[09:29] tehKellz (kelly.linden): Some events like listens and collisions we don't handle via an event queue because it is easier to check only when the script's turn comes up to see if there is new chat or has been a collision.

[09:30] tehKellz (kelly.linden): I don't mean to indicate that what you suggest isn't possible, or maybe even a good idea. Right now there are only 2 lists of scripts: running and not. We don't have a separate 'active' list or list of scripts with pending work.

[09:30] Haravikk (haravikk.mistral): What about scripts without listen or collision events?

[09:30] Kallista Arliss (kallista.destiny): That would be one way to do toit ,interrupt vectors, which are actualy queues the get reordered every time

[09:30] Michelle Resistance: I think we're getting a bit too deep into implementation details we can't see, to offer useful advice.

[09:30] F L I P (flip.idlemind): What if a script has a timer() event with no timer set

[09:30] Kallista Arliss (kallista.destiny): lols Fun to speculate though

[09:31] Michelle Resistance: Fun to speculate, but I think it's more important to focus on the APIs we can see.

[09:31] Ardy Lay: I don't think Kelly is gonna let us play with ring zero code on his hosts.

[09:31] Haravikk (haravikk.mistral): My thinking is that a big chunk of scripts are largely superficial, i.e - they spend most of their time idle until something happens, so there may be some slack to take up for running active scripts

[09:31] Kallista Arliss (kallista.destiny): Unless the timer() maight have times set, it shouldn;lt be there

[09:32] Qie (qie.niangao): *hmmm*. But not just *empty* event handlers, but also maybe some that aren't going to happen anymore / for a while... meaning that it may be worthwhile to switch to a state without those event handlers

[09:32] Haravikk (haravikk.mistral): I suppose there are less superficial scripts now with the efficient scripts additions, but I notice I'm topping the list for most scripts at the moment, but the bulk of my scripts other than my AO aren't doing anything, as they're all style or HUD related

[09:32] Kallista Arliss (kallista.destiny): Actually I suspect that the vast bulk of scripts are waiting on events

[09:32] tehKellz (kelly.linden): Haravikk: We agreed and thought the same thing, which is what the old implementation did - very closely matching what you suggest. We changed it based on seen behavior.

[09:33] Ardy Lay: Does the compiler not optimize out empty event handlers?

[09:33] tehKellz (kelly.linden): It does not Ardy.

[09:33] tehKellz (kelly.linden): There is no optimization in LSL.

[09:33] Kallista Arliss (kallista.destiny): It's not really an optimizing complier

[09:34] Michelle Resistance: Which is why I yell at people for using integers where they should be using floats.

[09:34] Kallista Arliss (kallista.destiny): lsl -O3

[09:35] Leonel Iceghost: even if before it didn't work, it doesn't look eficient to poll to see if they have events pending.. I think there should be a way for a script to push its own place in the queue

[09:35] Ardy Lay: COmprehensive optimization I would not expect but some things that are seen by developers such as Kelly as important might be useful to add to improve simulator performance. The rest can be user education.

[09:36] tehKellz (kelly.linden): Leonel, it may indeed be worth revisiting since it has been the way it currently is for a very, very long time.

[09:38] tehKellz (kelly.linden): Lets open it up to some other topics.

[09:38] Liisa Runo: Kelly, SCR-103 your area or should i take it to Andrew?

[09:39] Liisa Runo pokes the jira helper

[09:39] F L I P (flip.idlemind): "Script error particle not displaying above agent when script error comes from a HUD"

[09:39] Liisa Runo: got moved to but it is not really viewer bug

[09:39] flexi campfire: [#VWR-26016] Script error particle not displaying above agent when script error comes from a HUD

[09:40] tehKellz (kelly.linden): I think it may be a viewer issue.

[09:40] tehKellz (kelly.linden): :)

[09:41] Liisa Runo: how can it be when LL has not updated 1.23 or snowglobe for years

[09:41] tehKellz (kelly.linden): The server behavior changed intentionally (so the error would point to the actual attachment and not the agent). The viewer needs to be updated to match.

[09:41] Kallista Arliss (kallista.destiny): Kelly take a look at the last comment, the particle is now missing on 1.23.5 and it used to be

[09:41] tehKellz (kelly.linden): Yes, see my last statement.

[09:41] Kallista Arliss (kallista.destiny): yeah race contition for typing

[09:42] Liisa Runo: oh well, i guess ill just write a script to orbit the hell out of them spammers

[09:42] Qie (qie.niangao): so, Liisa, you'd be okay with the new intended behavior (showing on the culprit's own screen), if it worked?

[09:42] Kaluura (kaluura.boa): Actually, you better send an IM to the script creator...

[09:42] tehKellz (kelly.linden): :-/ huds will be a tough case and the viewer may not be able to compensate for the new behavior. Honestly there should be a SVC issue or SCR issue that hud script errors should only go to the owner.

[09:43] Kaluura (kaluura.boa): Ho, yes! Please!

[09:43] tehKellz (kelly.linden): you shouldn't get spammed for script errors on someone elses hud. That seems to be the real bug.

[09:43] Kallista Arliss (kallista.destiny): from you mout to the Dev's ears

[09:43] Liisa Runo: it is not bug of cript creator, script works fine, people just dont realise LL wiped copybotted anims from their HUD's cause they dont see the error

[09:43] tehKellz (kelly.linden): If someone makes that jira I'll import it to ER.

[09:44] F L I P (flip.idlemind): What is "ER" again? (Not a cancelled NBC show I imagine)

[09:44] tehKellz (kelly.linden): Engine Room. Server maintenance project / team.

[09:45] tehKellz (kelly.linden): Where most SVC bugs go.

[09:45] oobscure (opensource.obscure): I thought it was "Excessively Restricted" as we can't usually see those (IIRC)

[09:45] Kallista Arliss (kallista.destiny): sekret JIRAS

[09:45] tehKellz (kelly.linden): Yeah, you can't see them. They often include non-public info like server logs etc.

[09:45] Liisa Runo: not quite sure what you ask Qie, but i just want it to be impossible to ignore script errors. people must always be aware of the spam they create

[09:46] tehKellz (kelly.linden): Liisa: maybe we should address that directly and reduce the spam they create.

[09:47] Liisa Runo: just blocking the spam is not a good solution, we must make the people want to stop wasting sim resources with nonworking stuff

[09:47] tehKellz (kelly.linden): 13 minutes remaining. Other topics?

[09:47] Haravikk (haravikk.mistral): I was actually going to ask who the best linden to speak to is about how animations work server-side, with regards to SCR-13 (previously SVC-6300)

[09:47] Leonel Iceghost: kelly, is there any posibility to work on compression for comunications with the viewer, as you did inter sim?

[09:48] flexi campfire:

[#SCR-13] llStartAnimationSynced() - start an animation synchronised with a given timestamp

[09:48] Haravikk (haravikk.mistral): Or if there are any lindens that could take a look to try and help get an idea of the technical issues for adding the function of the server-side

[09:48] Haravikk (haravikk.mistral): Oz Linden and Esbee Linden are both intersted in the possibility of adding the viewer-side through Snowstorm, but they're not really server-side gurus

[09:49] tehKellz (kelly.linden): Haravikk: hrm. Tough one. If they add the viewer side it shouldn't be too hard to add the server side, though scheduling time is always an issue.

[09:50] Haravikk (haravikk.mistral): That seems to be the main hurdle, as no-one wants to do both the server and viewer side, which seems to mean two sets of Lindens are needed heh, but at least if the viewer stuff can get done I suppose it'd be more likely to find time since it'd become a smaller job?

[09:51] tehKellz (kelly.linden): Yes, cross team jobs are difficult to schedule.

[09:51] Haravikk (haravikk.mistral): How likely would be that SCR-13 could get a big bump in priority once the viewer-side was sorted? That might at least get it seen to sooner? What's the actual status on clearing SCR issues actually?

[09:53] tehKellz (kelly.linden): It depends on what the viewer implementation expects from the server.

[09:53] tehKellz (kelly.linden): I honestly don't know.

[09:53] tehKellz (kelly.linden): Leonel: What do you mean by compression for communications?

[09:54] Haravikk (haravikk.mistral): Well, my thinking is that timing info can be its own data at the end of an animation message, which should avoid backwards compatibility issues, so long as ordering is the same it'd be easy to match up timestamps to animations

[09:54] Leonel Iceghost: if you try to make a game, where you need 20 people running.. just moving, the bandwidth goes up to ~200

[09:54] Leonel Iceghost: it may not seem a problem, but for people outside USA, with packets loss.. it means more errors in what you see

[09:55] Leonel Iceghost: making it difficult to do any real game

[09:55] Haravikk (haravikk.mistral): Compression might be too high a trade-off, as most data to viewers is tiny? So the performance overhead of compressing it could be quite large

[09:55] tehKellz (kelly.linden): Leonel, yeah that issue probably isn't compression but rather the logrithmic nature of the data being generated and sent. More people means both more data generated and more people to send it to.

[09:56] Leonel Iceghost: it is not tiny Haravikk, if you do the maths... 20 keys, with pos, and vel... 10 times per seconds shouldn't go over 30kbps the most... but is uses 200kbps or more

[09:56] Haravikk (haravikk.mistral): For intra-sim it makes sense I think because once an avatar is fully serialised, it can add up to quite a lot?

[09:56] tehKellz (kelly.linden): That is honestly a better question for the Sim user group w/ Andrew and Simon.

[09:56] Leonel Iceghost: I'm talking 200kbps per viewer Kelly...

[09:56] tehKellz (kelly.linden): Yeah, we have to serialize all your attachments' scripts for region crossing.

[09:56] Haravikk (haravikk.mistral): True, but the added processing would slow the simulator, and add latency to the already slow messages

[09:56] Haravikk (haravikk.mistral): (with regards to lots of small messages)

[09:57] Leonel Iceghost: so any explanation of why 20 avie updates, with pos and vel, 10 times per second takes 200kbps in a single viewer?

[09:57] Haravikk (haravikk.mistral): Compression isn't desperately effective on small messages anyway, the saving could very little for a lot of work

[09:57] Kallista Arliss (kallista.destiny): Leonel, Keys and Floatingpoint numbers donl;t compress well.

[09:58] Michelle Resistance: Highly entropic data.

[09:58] tehKellz (kelly.linden): Leonel: That is a better question for the other User Group.

[09:58] Qie (qie.niangao): might also want to watch Control-Alt-Shift-U to see what else besides avatars moving around is flooding comms. Combat meters or other crap sending object updates constantly.

[09:58] Leonel Iceghost: keys, with pos and vel shouldn't take more than 15-20kbps without compression Kelly

[09:58] Leonel Iceghost: with compression even less

[09:59] Kallista Arliss (kallista.destiny): Actually combat meters are prettuy quier most of the time

[09:59] tehKellz (kelly.linden): I do have a question for the last 2 minutes: For anyone here that uses Top Scripts on an estate they own or manage, do you ever care about the 'mono script time' vs. the 'total script time' ?

[09:59] Michelle Resistance: Yes, actually.

[09:59] Qie (qie.niangao): Kallista: yours is now, indeed.

[09:59] F L I P (flip.idlemind): Question is what, if anything, besides keys, positions and velocities is being sent

[09:59] Michelle Resistance: At least, until we get Mono 2. =p

[09:59] Ardy Lay: I know an Australian that made a fancy flashing tiled dance floor then started hitting her transfer quota. She told me the object update traffic was a lot higher than she expected.

[09:59] tehKellz (kelly.linden): Michelle: we have mono 2.

[09:59] tehKellz (kelly.linden): On all of agni.

[10:00] tehKellz (kelly.linden): Michelle: in what way is that data meaningful?

[10:01] Michelle Resistance: Well, it's useful for estimating how much of the script time is being consumed by old versus new scripts.

[10:02] Michelle Resistance: When rezzing mono-scripted objects would lock things up, it was also useful for figuring out what objects were scripted by people unaware of the problem.

[10:02] tehKellz (kelly.linden): ahh. ok.

[10:02] Michelle Resistance: Of which there were a lot. x_x;

[10:02] Kallista Arliss (kallista.destiny): Meters listen on a specifice channel (related you the user's key) for specific messages then process that. The weapons either fly (arrows and such) until the hit something, decide if theyhit an avatar (if so the send a direct hit) or other someithgn (scan and hit the nearest inrange Avatar) and then delet them selves

[10:03] Kallista Arliss (kallista.destiny): Melee weapons do a scan and hit the nearest target.

[10:03] tehKellz (kelly.linden): All right! Thanks for coming everyone.

[10:03] tehKellz (kelly.linden): Next week is triage.