Simulator User Group/Transcripts/2011.09.30
| Prev 2011.09.30 | Next 2011.10.04 |
List of Speakers
| Andrew Linden | AnnMarie Otoole | Cory Hancroft |
| Falcon Linden | Flip Idlemind | Gooden Uggla |
| Kadah Coba | Kallista Destiny | Kelly Linden |
| Latif Khalifa | Liisa Runo | lonetorus Habilis |
| Moundsa Mayo | Pauline Darkfury | Rex Cronon |
| Sahkolihaa Contepomi | Sebastean Steamweaver | Simon Linden |
| TankMaster Finesmith | Thickbrick Sleaford |
Transcript
[16:00] Sahkolihaa Contepomi: Hey Andrew.
[16:00] Meeter: Welcome to the Server User Group
[16:00] Moundsa Mayo: I think I clipped you at the landing point, Andrew. My apoolgies.
[16:00] Andrew Linden: Hello
[16:00] Pauline Darkfury: Afternoon, Andrew :)
[16:01] Andrew Linden: No worries Moundsa.
[16:02] Andrew Linden: Ok. Let's get started...
[16:02] Andrew Linden: I spent all day today doing merges between projects
[16:03] Andrew Linden: which means no new code written.
[16:03] Andrew Linden: Most of yesterday too... I had redo one of the merges.
[16:03] Sahkolihaa Contepomi: Hey Simon.
[16:03] Rex Cronon: hello everybody
[16:03] Andrew Linden: My "faster scripts" project is on BlueSteel.
[16:04] Andrew Linden: It introduced a new crash mode that Pauline Darkfury noticed
[16:04] Andrew Linden: It's hard to repro, but I fixed it yesterday... the fix will be deployed next week in an update.
[16:04] Pauline Darkfury: I can't take all the credit, others were talking about it, I just jumped on it and pushed it in LL-tech direction
[16:05] Andrew Linden: If anyone notices any script speed improvements on BlueSteel I'd be interested in hearing anecdotes.
[16:05] Pauline Darkfury: I tested the new build with Maestro earlier, as did the product creator, seems to fix it
[16:05] Andrew Linden: Thanks for that help Pauline.
[16:05] Pauline Darkfury: Not a problem :)
[16:06] Andrew Linden: Lets see... anything else?
[16:06] Andrew Linden: I think that's all the news I've got.
[16:07] Andrew Linden: The table is open. Maybe Falcon has a topic for the agenda.
[16:07] Pauline Darkfury: Oh, and if anyone has a BlueSteel that's crashing because of it, put a ticket in and mention SEC-974. Maestro has briefed support that regions experiencing the problem should be moved to another channel
[16:07] Sahkolihaa Contepomi: Just a quick question - what's the Monday OS upgrade about?
[16:07] Sahkolihaa Contepomi: Is that the kernel upgrade or the whole debian upgrade?
[16:07] Andrew Linden: Where is that Monday OS upgrade announced?
[16:07] Simon Linden: We annouced and extended update window
[16:07] Pauline Darkfury: it's on the main status page
[16:07] TankMaster Finesmith: ^
[16:07] Andrew Linden: It is just a kernel upgrade.
[16:07] Sahkolihaa Contepomi: http://status.secondlifegrid.net/2011/09/30/post1420/
[16:08] Pauline Darkfury: It was also discussed at yesterday's beta OH
[16:08] Pauline Darkfury: The status page says starting Monday, then all week
[16:08] Andrew Linden: I believe that is to address what we've been calling the "timewarp" problem.
[16:08] Sahkolihaa Contepomi: Yay.
[16:09] Andrew Linden: We concluded it was a kernel bug. We updated the kernels on adtit and I don't think we've seen a "timewarp" incident there yet.
[16:09] Kadah Coba: Cool.
[16:10] Andrew Linden: However, I wondered today if machine uptime might be a factor.
[16:10] Andrew Linden: I didn't do the legwork on that issue, so I just speculate.
[16:10] Pauline Darkfury: That's a good thought, Andrew
[16:10] Andrew Linden: I'll have to ask Don Linden about it.
[16:10] Pauline Darkfury: Do the sim hosts have spectacularly large uptimes?
[16:10] Sahkolihaa Contepomi: I bet they have really high uptimes.
[16:10] Simon Linden: That's my understanding, too
[16:10] TankMaster Finesmith: just run around the lab power cyceling the systems at randome :D
[16:11] Andrew Linden: Hrm... I wonder what the uptimes look like...
[16:11] Pauline Darkfury: I'm from an old-school Unix background, so uptimes measured in months are not something I view as bad, but there are still cases where it can become bad over time
[16:12] Andrew Linden: wow, one has an uptime of 519 days
[16:12] Sahkolihaa Contepomi: Nice.
[16:12] Andrew Linden: actually... the majority of the servers have an uptime of 519 for this small sample I'm running
[16:12] TankMaster Finesmith: wow
[16:13] Andrew Linden: they seem to fall into bins, which makes sense
[16:13] Latif Khalifa: means it's got all the kernel bugs since the OS has been installed ;)
[16:13] Andrew Linden: most of the cabinets are turned on all at once
[16:13] Andrew Linden: so... 519, 375, and 192 are the most populated bins
[16:14] Simon Linden: We're pretty sure this timewarp problem has been around for a long time
[16:15] Pauline Darkfury: Another thing to note, which was briefly discussed at the beta OH, is that ext2/ext3 do tend to gain some non-critical corruption of state over time (blocks getting orphaned which should be on the free lists, etc)
[16:15] Andrew Linden: we also have an OS upgrade in progress, but it hasn't hit the simulator hosts yet
[16:15] Sahkolihaa Contepomi: Nice.
[16:15] Sahkolihaa Contepomi: I hope that goes well.
[16:15] Pauline Darkfury: So, if the system filesystems are ext2/3, rolling a full fsck into the upgrade might not be a bad thing.
[16:16] Pauline Darkfury: The type of corruption I'm talking about normally doesn't actually cause problems, it's just stuff that would be better to have "clean"
[16:16] Andrew Linden: they appear to be ext3
[16:16] Latif Khalifa: it will happen automatically on reboot, ext3 has some if last fsck > xxx days, do it
[16:16] Pauline Darkfury: it does depend on activity patterns, etc, of course
[16:16] Pauline Darkfury: Yeah, although the fsck every n mounts/days thing is tunable
[16:17] Latif Khalifa: from what i understand sim hosts are pretty vanilla debian installs
[16:18] Gooden Uggla: does the OS upgrade mean that you can now have a version of mono that works?
[16:18] Latif Khalifa: mono works pretty well now
[16:18] Andrew Linden: I don't think our mono upgrade depends on that.
[16:18] Latif Khalifa: and they're not using system mono anyway
[16:18] Gooden Uggla: unless you have a sim with 20 people on it, it works pretty well, but...
[16:19] Gooden Uggla: really? once upon a time we were told that the linux neeeded an upgrade to run a newer mono
[16:19] lonetorus Habilis: still works correctly, just slower...
[16:19] Andrew Linden: Gooden, are you saying that legacy LSL scripts scale better with large number of avatars?
[16:20] Gooden Uggla: andrew it's been mitigated somewhere, but the freezes still exist
[16:20] Latif Khalifa: Sims lag badly with a lot of avatars in them. People tend to attribute that to scripting engine.
[16:20] Kelly Linden: A newer linux distro makes further mono upgrades easier. Except for the whole API/ABI change in the version after what we use now.
[16:20] Gooden Uggla: somewhat*
[16:20] Gooden Uggla: no latif, i'm talking about the rez/derez freeze
[16:21] Andrew Linden: Gooden, you mean SVC-5927?
[16:21] JIRA-helper: http://jira.secondlife.com/browse/SVC-5927
[#SVC-5927] Temp on Rezzed objects get queued
[16:21] Gooden Uggla: the inherent lag seems mostly gone
[16:21] Latif Khalifa: yeah, but rez is expensive. with or without scripts
[16:21] Andrew Linden: oh, just the rez/derez cost of mono scripts
[16:21] Latif Khalifa: and derez is still singlethreaded and freezy
[16:21] Gooden Uggla: exactly
[16:22] Latif Khalifa: it has nothing to do with mono version but the sim architecture
[16:22] Gooden Uggla: we were once told that the linux was the reason that a newer mono couldn't be used, will that still be the case?
[16:22] Latif Khalifa: i was always wondering why make threaded rez and optimize avatar entry and not exit and derez
[16:23] Gooden Uggla: ask kelly, he's here
[16:23] Kelly Linden: The linux version has never prevented us from using a mono version
[16:23] Kelly Linden: The current version we use (2.6.7) was the most recent stable at the time of the project.
[16:23] Latif Khalifa: Gooden, I've heard that mentioned as the excuse before. But Kelly said that the system mono is not used and that mono is basically bundled with the sim package as deployed so OS version doesn't matter much
[16:24] Kelly Linden: We do not use the system mono for compiling scripts.
[16:24] Gooden Uggla: ok, good to know
[16:24] Latif Khalifa: Kelly, some Lindens before said that mono upgrade would require OS update to be done first causing confusion.
[16:24] Gooden Uggla: in that case, when will threaded derez happen?
[16:24] Kelly Linden: I'm not sure on the circumstances of those statements or what in particular they were talking about.
[16:25] Gooden Uggla: sorry, i waws going on faulty info :)
[16:25] Kelly Linden: Threaded de-rez is unrelated to mono version.
[16:25] Latif Khalifa: they were not well informed ;)
[16:25] Latif Khalifa: Simon did threaded rez, perhaps he can enlighten if threaded derez is going to happen?
[16:25] Gooden Uggla: kelly, i'll be quiet if we can be told when the derez fix is due to be fixed?
[16:26] Gooden Uggla: freeze*
[16:26] Simon Linden: There's some work on de-rezzing for region crossings going on right now
[16:26] Simon Linden: Or TP
[16:26] Gooden Uggla: right
[16:27] Kelly Linden: As far as I am aware, threaded de-rez is not currently scheduled. That is all I know.
[16:27] Andrew Linden: once that is done I suppose it shouldn't be too much work to thread the "derez to inventory" stuff too
[16:27] Latif Khalifa: Andrew, yeah, that can cause a sim freeze too, derez to inv.
[16:28] Andrew Linden: If it looks easy and might improve things I think a dev will take a swing at it.
[16:28] Latif Khalifa: Will script serialization bit be on that other thread too?
[16:28] Simon Linden: The main problem has been isolating code to be thread-safe
[16:28] Kallista Destiny: zWhat nput derez to the bit bucket (LLDie)
[16:29] Kallista Destiny: about*
[16:29] Andrew Linden: yes, it would include all serialization for the object being derezed, I think.
[16:29] Andrew Linden: llDie() doesn't serialized out, but it does delete and cleanup
[16:30] Gooden Uggla: the original point still stands, it ruins social gatherings
[16:30] Gooden Uggla: and live performances
[16:30] Meeter: Timecheck : User Group is half over
[16:30] Andrew Linden: so... once all the data were unhooked the deletes could be threaded... dunno whether that would gain us much
[16:31] Gooden Uggla: SVC-4196
[16:31] JIRA-helper: http://jira.secondlife.com/browse/SVC-4196
[#SVC-4196] Avatar entering sim or rezzing object causes sim to freeze for up to 30 seconds - everything stops for everybody there
[16:31] Latif Khalifa: well entering part is fixed. leaving part still causes issues ;;)
[16:31] Gooden Uggla: i'm sure simon is sick of it by now :)
[16:32] Sebastean Steamweaver: Hello everyone :)
[16:32] Pauline Darkfury: The big freeze is gone most of the time now, tbh
[16:33] Kallista Destiny: I haven't see that at any noticeable strength for ages, although instrumentation does show it.
[16:33] Rex Cronon: hi
[16:33] Simon Linden: I'd love to put more work into other side threads, but our system is so intertwined it's a lot of work
[16:33] Gooden Uggla: yes pauline, for which we are thankful and delighted
[16:33] Pauline Darkfury: There is still something where occasionally the newer softer impact is a bit longer lasting and more notable, doesn't seem to be an obvious pattern to it
[16:34] Latif Khalifa: yeah it's much improved
[16:34] Latif Khalifa: none of those 30 second freezes anymore
[16:34] Latif Khalifa: weekly restarts help too :P
[16:35] Gooden Uggla: pauline the pattern is "when we have a well-attended event" and sometimes the freeze is over 5 seconds or so
[16:35] Gooden Uggla: since the sec updatre, freezing is longer
[16:35] Gooden Uggla: my moon meter says so
[16:35] Pauline Darkfury: Yeah, but I'm also seeing low-impact enter/leave of heavy AVs when the sim is busy, at least some of the time
[16:35] Gooden Uggla: :)
[16:36] Kallista Destiny: You should note that combat regions usually restart every few days on occasion daily or mor often
[16:36] Simon Linden: Latif makes a good point ... one of the difficult problems we face now is that performance seems to slowly degrade over time. A bunch of people have looked at it for memory leaks, etc but it's eluded us so far
[16:36] Pauline Darkfury: That's my point, the heavier impact isn't an exact thing, sometimes it is much worse than other times, even when the sim is busy with script-heavy people
[16:36] Kallista Destiny: There is some performance degradation after heavy activity
[16:37] Gooden Uggla: correct pauline, it seems more related to grid load
[16:37] Simon Linden: There's also a lot of interaction with other regions on the server ... if one of them is loaded down, it can hurt overall performace
[16:37] Pauline Darkfury: Yes, there's def some remaining degredation over time or activity
[16:37] Pauline Darkfury: It's nothing like as bad as it was around mid-2010 though. Heavy sims used to be pretty much dead after 48h uptime back then
[16:38] Kallista Destiny: No it's much better, then we'd reboot right after the battle
[16:38] Gooden Uggla: i brought this up because it still impacts the most popular and desired social events that the lab likes to trot out in front - live music and music events
[16:39] Gooden Uggla: the derez freeze mostly
[16:39] Latif Khalifa: yeah it's much improved. and i know it's difficult to trace those time performance degradation problems. it could be inefficient malloc fragmenting heap to hell.
[16:39] Simon Linden: When you say derez, do you mean AVs specifically?
[16:39] Simon Linden: or deleting any object?
[16:39] Gooden Uggla: i mean the junk the avatars are wearing, but sure...
[16:39] Latif Khalifa: Simon, mainly heavy avatars teleporting out
[16:40] Simon Linden: ok, that makes sense ... yeah, there's a lot going on at that time, unfortunately it's blocking the main simulator loop
[16:40] Gooden Uggla: there aren't many objects so scripty that taking them in causes a freeze anymore
[16:40] Kallista Destiny: Arrows derezzing
[16:40] Gooden Uggla: i suppose it's possible
[16:40] Kallista Destiny: several hundred over a 20 minute fight
[16:40] Simon Linden: If the object isn't going back to inventory, it should be pretty quick
[16:41] Simon Linden: The other factor is if it changes the physical world significantly ... that adds lag
[16:41] Gooden Uggla: and if it is?
[16:41] Kallista Destiny: yes they are gone
[16:41] AnnMarie Otoole: Well I'm going to say it, Kudos all round on getting the PHYSICS fix out quickly.
[16:41] Kallista Destiny: but I suspect that there is some heap/memory/whatever fragmentation happening
[16:42] Gooden Uggla: it just seems half-done, it's better but not finished. I'm just trying to keep it in the collective mind
[16:42] Simon Linden: If it's going back to inventory, Gooden, there's more work than if it's just being deleted from the world
[16:42] Gooden Uggla: agreed
[16:42] Latif Khalifa: yaeh it needs to be serialized, sent to the asset server, and inventory server...
[16:43] Gooden Uggla: as i said, it's avatars TPing out mostly, or crashing
[16:43] Liisa Runo: this week i have noticed that many places have spare time. Places that never had spare time before. 24 of us here. why this sim has spare time? im sure our scripts would be happy to waste all unused time
[16:43] Gooden Uggla: crashing is still something of a problem when a sim has a lot of avs on it, especially in the new viewer
[16:44] Kallista Destiny: Not Region crashing?
[16:44] Pauline Darkfury: So, talking of performance stuff, I'm seeing a relatively new phenomenom (last 2 weeks, 4 max, I think, hard to put an exact date on it). I've just started a Jira on it, SVC-7339. I think it _might_ be either specific to or most likely to occur on LeTigre
[16:44] JIRA-helper: http://jira.secondlife.com/browse/SVC-7339
[#SVC-7339] Performance issues on LeTigre 11.09.23.241511
[16:44] Gooden Uggla: haven't run into many region crashes lately in our busiest sims
[16:45] Pauline Darkfury: Short version is regions which are not massively loaded, but approx saturated on script time (maybe 3000-ish scripts upwards on a C7), low event rate, stats generally looking ok
[16:45] Pauline Darkfury: They seem to be capping at approx 0.95 or 0.97 dilation, and always having around 1.0ms spare, when they really should be 0.0ms spare
[16:45] Andrew Linden: I don't see "spare time" on the list anymore. Are you talking about the "Total - sum(other)" value?
[16:45] Latif Khalifa: they removed spare time from the latest viewer?
[16:46] Pauline Darkfury: Spare is still visible if you have a viewer where it wasn't nerfed ;)
[16:46] Liisa Runo: im talking about spare time displayed by good old clients that have less than 5000 bugs
[16:46] Latif Khalifa: that was a "smart" move of the viewer team lol
[16:46] Flip Idlemind: Spare time has always been missing from Viewer 2 as far as I know. But it's only a UI change, the code for it isn't missing
[16:46] Pauline Darkfury: e.g. this region currently has approx 3.5-4.0 spare
[16:46] Flip Idlemind: 'Twas easy for me to put back in
[16:47] Latif Khalifa: it only has 2000 runnning scripts
[16:47] Rex Cronon: u just have to edit an xml file to see spare time again?
[16:47] Simon Linden: I keep meaning to put that back into the viewer
[16:47] Flip Idlemind: Yar
[16:47] Pauline Darkfury: I really can't tell if this issue I'm seeing is a measurement issue, or an actual case of reduced performance. but something is def not quite right
[16:48] Pauline Darkfury: The regions where it's visible basically "feel" ok, although a region which is heavily enough loaded to justify around 0.95 average perf does still feel "ok"
[16:48] Kallista Destiny: Spare time is in the dev version of firestorm (3.1.1 based))
[16:48] Kallista Destiny: 2.2msec here
[16:48] Falcon Linden: Hey folks. As time is getting short, I wanted to jump in and give some news in case you haven't heard it yet
[16:49] Falcon Linden: (a) llSetKeyframedAnimation (probably to be renamed llSetKeyframedMotion) is available on Aditi in Sandbox - Bispinor and Sandbox - Weapons Testing
[16:49] Sebastean Steamweaver: !
[16:49] Falcon Linden: It's mostly documented on the wiki
[16:49] Sebastean Steamweaver: I am all ther!
[16:49] Sebastean Steamweaver: When did this start?
[16:49] Falcon Linden: A week or so ago
[16:49] Sebastean Steamweaver: I've been out f the loop for a while.
[16:49] Rex Cronon: can u put it in rausch too:)
[16:50] Sebastean Steamweaver: Haha! I'm ecstatically happy now.
[16:50] Latif Khalifa: Most scripters I talked to are really confused with that name. Most everyone thinks it's about animating prims within a linkset.
[16:50] Falcon Linden: Due to time constraints, only showstopper bugs will be fixed before release (I think the wiki has a description of "showstopper" in this context), but please report any bugs you do find.
[16:51] Falcon Linden: Latif: Yeah, I picked up on that. They should read the documentation. :) But I'm all for good names, so I'll probably rename it to llSetKeyframedMotion
[16:51] Rex Cronon: maybe change function name to llObjKeyFrameAnim?
[16:51] Sebastean Steamweaver: I automatically associated it with the keyframed motion that Andrew spoke of a long while back.
[16:51] Flip Idlemind: I've noticed that right click selecting an object with keyframed motion freezes it. Is that intentional, and if so, is it going to be subject to the same rules as right clicking physical objects?
[16:52] Kallista Destiny: Question, how many reboots can we expect with the upgrades to the Linux servers next week, 1 + 1 for the usual Roll?
[16:52] Thickbrick Sleaford: About llSetKeyframedAnimation: how does its velocity profile look? Is it constant accel? (constant accel would be nice, since it would avoid lots of updates to the viewer, presumably)
[16:52] Simon Linden: That should be the limit, Kallista, unless your region has the bad luck to move back onto a non-upgraded server at some point
[16:52] Latif Khalifa: llWayPointMotion() or something ;)
[16:52] Falcon Linden: Thickbrick: it's infinite acceleration, constant velocity
[16:53] Thickbrick Sleaford: heh, cool
[16:53] Andrew Linden: Kallista, I think the kernel upgrades will contribute an extra restart per host... those upgrades will happen all week rather than during the rolling restarts.
[16:53] Falcon Linden: flip: good question. I don't know. Probably should be treated like physical objects. Feel to report that as an issue, though I can't promise I'll be able to fix it immediately
[16:53] Falcon Linden: Feel free*
[16:53] Falcon Linden: Any other questions on the keyframed anim stuff?
[16:53] Thickbrick Sleaford: I thought it behaved like llMoveToTarget, which is neither constant velocity nor constant acceleration.
[16:53] Kallista Destiny: Thanks anderew that is what I expected
[16:54] Latif Khalifa: Why fore PE on users of that function?
[16:54] Latif Khalifa: force*
[16:54] Simon Linden: http://wiki.secondlife.com/wiki/LlSetKeyframedAnimation
[16:54] Cory Hancroft: Question: Has any progress been made with the exploits with llGiveMoney? Status has been unchanged for 4 years and the negative impact has been growing steadily lately.
[16:54] lonetorus Habilis: falcon and is it inter sim yet?
[16:54] Falcon Linden: Latif: I explained that in an SL community post. It's because we can't have arbitrarily complex objects moving around and the only way to limit things based on their physics complexity is to use PE
[16:55] Falcon Linden: Ionetorus: yes
[16:55] Flip Idlemind: So, question: It seems like every time I bring up SCR-91, it gets dodged. Am I missing something? Would it be, like, more complicated to implement than one might thing?
[16:55] JIRA-helper: http://jira.secondlife.com/browse/SCR-91
[#SCR-91] llRequestAgentKey (llName2Key)
[16:55] Rex Cronon: what llgivemoney exploits?
[16:55] Meeter: Timecheck : User Group is almost over
[16:55] Pauline Darkfury: Quick question before we run out of time. Any response from Patch on likely timescale to enable mainland encroachment-return?
[16:55] Falcon Linden: Next important item:
[16:55] Simon Linden: Cory - yes, there was a fix recently about pay price problems
[16:55] Falcon Linden: We're upgrading Havok again: w00t!
[16:55] Falcon Linden: haha
[16:55] Cory Hancroft: SCR-37
[16:55] JIRA-helper: http://jira.secondlife.com/browse/SCR-37
[#SCR-37] llGiveMoney() method needs a money_given() event handler.
[16:56] Rex Cronon: oh. that one
[16:56] Pauline Darkfury: The old thing where llGiveMoney() just silently fails
[16:56] Falcon Linden: 2011.2 this time. It's already out on some aditi regions including Ahern and Chief (to pick two off the top of my head)
[16:56] Pauline Darkfury: which provides ways for people to exploit certain commerce things
[16:56] Cory Hancroft: its not about the pay price problem, its the fact that uses can cause the llGiveMoney to fail after 35 events in 30 seconds (not sure the threshold)
[16:56] Latif Khalifa: Falcon, what's the changelog highlight for that new version?
[16:56] Falcon Linden: We expect no changes in behavior between the current havok version and the 2011.2 version, but if you don't want a nasty surprise come release, you should test your content :)
[16:56] Sebastean Steamweaver: Nice! Will there be any big differences that we'd notice Falcon?
[16:56] Moundsa Mayo: Falcon, possible to get that Havok on Aditi:Kapor and Rosedale for rail testing?
[16:57] Falcon Linden: Latif: nothing of any significance. I think I had to change the way I access a zero vector. That's about it :P
[16:57] Andrew Linden: No Pauline, Patch has not given an ETA. I have seen some email traffic about it. I'd say Patch is in "discovery phase", asking for info from people who might know how things might be impacted.
[16:57] Falcon Linden: Moundsa: I'll see what I can do.
[16:57] Moundsa Mayo: Appreciated.
[16:57] Pauline Darkfury: Thanks, Andrew :)
[16:57] Cory Hancroft: this affects Split Pays and Affiliates, basically anything that uses llGiveMoney can be exploits and prevent the llGiveMoney from being performed
[16:58] Sebastean Steamweaver: I will say, having keyframed animation for prims in a linkset would be nice.
[16:58] Andrew Linden: Cory, do you know of some jira issues that talk about the llGiveMoney problems? I ask mostly so that links will be available in the transcripts.
[16:58] Pauline Darkfury: It's not even just exploits. It can fail in non-exploit situations, resulting in someone failing to have the L$ they should have
[16:58] Cory Hancroft: SCR-37
[16:58] Falcon Linden: Sebastean: I agree. we need hierarchy first.
[16:58] Cory Hancroft: this offeres a solution to the issue
[16:58] Latif Khalifa: my biggest problem with llGiveMoney() is that my vendors "forget" that they have debit permission so the split playment fails
[16:59] Sebastean Steamweaver: STil, thank you for this - this'll make things much nicer in many regards.
[16:59] Sebastean Steamweaver: Smoothly rotating doors is one of them! Even if they do need to be unlinked, that isn't anything new.
[16:59] Moundsa Mayo: Yes, and a natural for using SLERPs on curves.
[16:59] Simon Linden: -37 is specifically about the lack of the event handler, but if you can send me or Andrew more details about problems flooding it, I'd be interested
[16:59] Gooden Uggla: "This issue is original of duplicate SEC-957"
[16:59] Rex Cronon: the vendors don't give change?
[16:59] Pauline Darkfury: If you want to know how to get unlimited free vends from most vending systems, just ask one of us to show you how, Andrew ;)
[16:59] Gooden Uggla: nope, not it the helper either
[16:59] lonetorus Habilis: falcon sounds like it will be same time as arbitary rigging
[17:00] Andrew Linden: hrm... there is a throttle on llGiveMoney(): 30 events in 30 sec, per owner_id
[17:00] Falcon Linden: Ionetorus: not necessarily. It doesn't require viewer-side animation
[17:00] Falcon Linden: just joints and hierarchy
[17:00] Sebastean Steamweaver: Thank you Andrew, Simon, Falcon, Kelly
[17:00] Gooden Uggla: good meeting, thanks
[17:00] Pauline Darkfury: That's the most serious problem with it, affiliate vendors owned by untrustworthy people
[17:00] Meeter: Thank you for coming to the Server User Group
[17:00] Rex Cronon: if u have 100 vendors u r in trouble:(
[17:00] Kallista Destiny: yes Thank you all...
[17:00] Andrew Linden: Cory, what are some cases where that throttle is hit incorrectly?
[17:00] Andrew Linden: er... where it causes problems?
[17:00] Cory Hancroft: Andrew: basically a resident runs a script that gives themself 35 $L1 payments within 30 seconds which causes the llGiveMoney function to silently fail. Once this is performed, the user can then purchase from a vendor and the llGiveMoney for split pays and affiliates is bypassed, basically, giving the buyer a free item and the owner gets nothing
[17:01] Pauline Darkfury: The less serious, but equally annoying case is if it just fails to pay someone that should have been paid, there's no way to easily spot that without painful reconciliation of downloaded trans history vs. 3rd party log, to find the missing payments
[17:01] Andrew Linden: hrm...
[17:01] Cory Hancroft: users exploit Split Payments and Commission based systems to avoid giving the creator their portion
[17:01] Latif Khalifa: oh yes, i can see how affilate vendors can be milked like that
[17:01] Pauline Darkfury: The throttle on llGiveMoney actually makes it much easier to abuse the system
[17:01] Andrew Linden: what are "split payments"?
[17:02] Cory Hancroft: where a renter will give the land owner a portion of their earning to the land owner
[17:02] Latif Khalifa: Andrew, you and I are partners. vendor sells stuff and pays us each 50%
[17:02] Rex Cronon: if u sell something i made u get a percent
[17:02] Cory Hancroft: or when 2 residents design together in a partnership
[17:02] Gooden Uggla: vendors splits
[17:02] Pauline Darkfury: Say you and I create something together, Andrew. We might have an arrangement where Latif sells it for us, keeps 20% for that, gives us 40% each
[17:02] Sebastean Steamweaver: Split payments are where the money earned form a purchase is automatically split among two or more people by the vendor script.
[17:02] Andrew Linden: I see, so split payments increase the frequency at which llGiveMoney() needs to be called.
[17:03] Pauline Darkfury: It's entirely uncommon to have a 5+ way split, where there's a group effort on something
[17:03] Rex Cronon: if u reset script after each paymen this should go away:)
[17:03] Rex Cronon: payment*
[17:03] Cory Hancroft: this is not the only way to exploit either, a user can have a hud that wears a script that will constantly llGiveMoney to their alt, which leaves them zero balance
[17:03] Pauline Darkfury: resetting scripts removes debit perms
[17:03] Rex Cronon: right
[17:03] Cory Hancroft: Andrew: Correct
[17:04] Thickbrick Sleaford: Not really. Split payment is just a scenario in which the throttle on llGiveMoney can be exploited for monetary gain.
[17:04] Andrew Linden: why does zero balance matter for this hack?
[17:04] Pauline Darkfury: Yup, or if you have a very active account, one device might pay something out (legit) inbetween money coming in for an unrelated thing and the llGiveMoney to forward or refund some/all of it
[17:04] Latif Khalifa: "affiliate vendor" you give to people around to put up on their land. so they get to keep say 20% of the sale and the rest goes to the original creator. so with this exploit someone picks up affiliate vendor, makes a script that pays himself quickly $35, then they purchase from affilate vendor and besically get 100% of the proceeds since split payment to the original creator fails
[17:04] Pauline Darkfury: llGiveMoney silently fails if the working balace is even temporarily L$1 short
[17:04] Cory Hancroft: its not so much the zero balance, if they time out llGiveMoney events, it silentyly fails
[17:04] Pauline Darkfury: L$0 is just the extreme example
[17:04] Gooden Uggla: andrwew it means the commion vendor owner has no cash to send the creator
[17:04] Cory Hancroft: it will silently fail if you have an infinite Linden balance
[17:05] Gooden Uggla: commisssion vendor*
[17:05] Cory Hancroft: its ANY time the llGiveMoney event is performed higher than the threshold
[17:05] Andrew Linden: ok, I'll try to read over these explanations and ponder whether the llGiveMoney() throttle can be fixed.
[17:05] Cory Hancroft: "Use is limited to 30 payments in a 30 second interval for all scripts owned by that resident on a region. Sustained overage will produce a script error and halt payments while the rate remains excessive. Historically, faster payments have failed intermittently"
[17:06] Gooden Uggla: to be honest, creators neeed to be more careful in how they hand out commission vendors, but it should get fixed
[17:06] Cory Hancroft: except that its not intermittently, its every time in this case
[17:06] Pauline Darkfury: One case that could hit me, is if my working balance was temporarily low, and someone paid an affiliate vendor owned by me, then a tenant refunded a large amount of pre-paid rent before the affiliate had a chance to forward it. That's a narrow, but possible non-abuse failure case
[17:06] Cory Hancroft: yes, very true Gooden, but this is a very open hack
[17:06] Andrew Linden: It would be possible to "key" the throttle on the giver_id XOR receiver_id... which would narrow down the throttle
[17:06] Simon Linden: The trottles are built to handle a burst of activity, but hit the limit if that pace is maintained
[17:06] Pauline Darkfury: Of course, as a responsible commerce participant, I try to always ensure my float is high enough to not end up in that situation
[17:06] Gooden Uggla: agreed cory
[17:07] Andrew Linden: however I need to figure out what the original purpose of the throttle was for... there may be some other consequences of opening it up
[17:07] Simon Linden: 1 per second is easy to pass, however
[17:07] Latif Khalifa: yes, n number of payments to where sender and reciever are the same would help avoid this particular exploit
[17:07] Cory Hancroft: as in SCR-37, a simple verification whether the money is actually given would be a huge leap forward on this
[17:07] Pauline Darkfury: Yup, just a simple boolean success/fail would solve most of the problems
[17:07] Cory Hancroft: setting a limit doesnt solve it due to the fact they just let the script run longer that times out the llGiveMnoney
[17:08] Sebastean Steamweaver: Or better yet, return the key the money was given to, or NULL_KEY if unsuccessful.
[17:08] Pauline Darkfury: Yeah, even with no throttle, the abuse cases are still there
[17:08] Cory Hancroft: they just set it to give 1L every .1 seconds for 30 seconds, then you just hit 300 times
[17:08] Cory Hancroft: raise the threshold and they just lengthen the time or just start up another script
[17:08] Sebastean Steamweaver: Though I suppose if it's asynchronous that isn't necessary.
[17:08] Latif Khalifa: Cory it solves "affiliate vendor" exploit if throttle is done on sender/reciever combination. Not just sender. And it requires no vendor code to be rewritten
[17:09] Pauline Darkfury: There's another more subtle way to make it fail, where you don't need timing or rate, but I'll only explain that one in private
[17:09] Pauline Darkfury: The root of all of the issues is the silent fail
[17:09] Cory Hancroft: exactly
[17:10] Cory Hancroft: this issue has been going for more than 4 years now and really does need some attention
[17:10] Rex Cronon: u really need to know if the money really got to their destination
[17:10] Andrew Linden: Ok. I'll try to look into it to understand the possible solutions better.
[17:10] Latif Khalifa: well it's all async and difficult to do. it's quite possible that payment succeeds but proposed return event notification fails
[17:10] Moundsa Mayo: Andrew, Simon, Kelly, Falcon - thanks for your time and all your hard work!
[17:10] Sahkolihaa Contepomi: See you, Andrew & Simon.
[17:10] Andrew Linden: Thanks for coming.
[17:10] Sebastean Steamweaver: Thank sAndrew, and Simon, again :)
[17:10] Pauline Darkfury: key llGiveMoneyVerified() is the solution
[17:10] Cory Hancroft: thanks so much, i do appreciate the time :)
[17:10] Latif Khalifa: thank you for your time :)
[17:10] Liisa Runo: thanks everybody
[17:10] Sahkolihaa Contepomi: Enjoy your weekends.
[17:10] Pauline Darkfury: raise a dataserver with success/fail
[17:11] Simon Linden: I'd go for the new event myself, but either way would work
[17:11] Rex Cronon: tc everybody
[17:11] Rex Cronon: andhaveaniceday:)
[17:11] Simon Linden: Thanks everyone for coming today and the good discussion
| Prev 2011.09.30 | Next 2011.10.04 |