Jump to content

Qie Niangao

  • Content Count

  • Joined

  • Last visited

Everything posted by Qie Niangao

  1. I've been responsible for fixing some big systems. It's a whole lot easier when everybody on the team has been working on the relevant code for a while. Now would be a very good time to really fix sim handoffs. In fact, the best time in SL's entire history.
  2. Qie Niangao

    lindons home

    They're also going to supply some sort of scripted security feature; until then, you're allowed to use your own which could theoretically have about the same effect as the banlines. We don't know what will be possible with the Linden-supplied script (or rather I don't know, but I haven't really been paying attention lately). Dunno 'bout you, but I sure wouldn't think it worth my time to set up my own security script knowing it will be replaced Real Soon Now.
  3. I've seen my alphas change with TP, too (at least with my Slink male avatar, maybe others) but not often enough to try to figure out what's going on. (For the past week or so I have auto-alpha turned off and haven't seen it, but I often go weeks without seeing it again.) The second thing, though, with the horridly delayed response to mesh avatar HUD settings: that's a classic first indication of degraded scripts run percentage. Check the sim statistics the next time this happens and I bet you'll find that number below 50% -- even if the sim is otherwise perfectly normal with no time dilation or anything. (Of course that's the way script performance is supposed to degrade, without affecting physics or anything else, but we think it's somehow degrading too soon.)
  4. For my sins, in a former life I studied social science, and I may be more comfortable with trying to extract meaning from crazily messy data. So I'm okay with informally correlating possible contributing factors across a bunch of wildly diverse sims, at least as a way of generating theories to test experimentally, to collect more specific data or, if it's quicker, to find sections of simulator code to investigate for flaws. Studying the brain and debugging software have stuff in common. Maybe not the probe insertion part, but stuff in common nonetheless. Also, the way we got here is really the most informal longitudinal study ever: Performance on the same sims, degrading over time. Sure, there are still multiple possible contributing factors, sometimes including changes in the user-generated content on the sim, but sometimes apparently not.
  5. There are certainly Mainland sims with plenty of spare time, too, but they seemed relatively low script-count and low script-event-count (probably low object count, though) compared to some other sims where script performance has fallen off a cliff. Come to think of it, "falling off a cliff" does seem pretty non-linear. I wonder... could it be memory after all? Or it could be only some LSL functions that cause the script-lag to arise in some regions and not others. (For example, Pathfinding was a hypothesis at one point but the problem often arises with no Pathfinding on the sim.)
  6. That's not the message I've gotten at Server user groups. Maybe I misinterpreted the Lindens, but I thought they were pretty committed to working on script performance, high on the to-do list. (I think that was before the teleport disconnects were recognized as needing everybody's full attention.) I understood the focus to be on script performance, I guess because it's the most evident and widespread performance problem affecting the sims. I have seen some sims in non-script trouble, but I don't know if there really are more of those in more trouble than in the past. Has anybody asked Ebbe or another Linden at a Town Hall whether they're still running full sims one-per-core? Or if they have some other theory of diminished performance?
  7. Other stuff is likely happening too, but one thing that some of us have been focused on is the inordinate amount of script time being consumed. Script-on-script lag, specifically, is getting serious with sims running a smaller percentage of scripts per frame, with seemingly as much frame time devoted to scripts as always. It's not clear why, and it's a thing Linden developers claim is next-in-line for study -- presumably delayed by the current teleport disconnect fiasco. As you say, sims aren't keeping up with the same loads they easily handled before. Maybe I'm gullible, but I really doubt this is because they're stacking them more sims per core. Something is using up time. My current totally unfounded theory is that it's due to stuff added to the sim ("little features and throttles and data collection") that has more than consumed all the savings they realized by off-loading services to non-sim hosts.
  8. I have no idea whether it means anything, but at one user group we were advised that teleporting quickly after arriving would likely not trigger the problem. Still, any hope is better than none.
  9. Permanent particle systems (e.g., continuous waterfall spray) is another example of script-set prim properties. I once went on a campaign to remove all those scripts from everything I could, just as a matter of computing hygiene. It's a big help to turn on the beacon for scripts. The thing is, though, these things have been around for ages. In fact, hovertext is much less common than it was when I was a newbie and everybody labelled everything (including poseballs, which were everywhere). Conceivably it could still help to reduce the number of these scripts now, even though they weren't a problem before, because we have so many more other scripts now. I wish there were a way to quantify trends in what's contributing script count (and script time, too). One thing that's been nagging at me is the fact that AVsitter is so ubiquitous and uses two scripts per sitter, plus a bunch of modular accessory scripts. I know the engine is actually way more efficient than XPOSE (probably about the same as nPose, maybe a bit better than MLP, no idea about others), but still it adds a lot of scripts to a region. It's open source, so I've mashed some of those scripts together occasionally, but that makes a whole project of version updates, and it's nothing we can expect end-users to do, or even most furniture creators. I wonder if it's too late to devise a more or less plug-and-play replacement that maybe supports fewer poses and somehow shrinks the script-per-function modularity. Also it's hard to get motivated to cut furniture scripts in half when one HUD-equipped mesh-headed mesh avatar can more than offset the whole exercise. Are those the scripts causing the script lag? I remember when shoes and some hair had scripts in each prim, so are script counts really higher than they used to be? Or have little features and throttles and data collection been added to the server code, making script processing less efficient in imperceptibly gradual increments?
  10. You sure convinced me. Also, Linden QA needs an automated Fluf to ride the pods for every deployed version. (I mean after being deployed on Agni, first to RCs and then grid-wide. Of course they'd be using a totally non-standard client, so some issues might still sneak through.) If only they could do it retroactively. It tells us something, that there's a mutant viewer strain that's somehow surviving the challenge. How do biologists figure out what changed to make one microbe resistant to antibiotics? Maybe this isn't that hard, but it's sure beyond me. We do have the source code, I guess, if somebody's equipped to compare how they handle region change. (I'm still only assuming that the sim-crossing and teleport problems are caused by the same thing. But I also assumed the choice of viewer had nothing to do with it, and that was wrong, so now I'm second-guessing everything.)
  11. This is news to me. I've had TP disconnects either way, but not enough volume to say one way or another. I'm assuming that within-sim teleports are excluded in both cases; of course within-sim TPs are very often scripted, but they're probably not part of the distinction being made here. I don't think I've ever heard of anybody getting disconnected during a within-sim teleport but come to think of it, that does kinda reinforce the relationship between the current sim-crossing and teleport problems. I didn't mean to make any point at all about "reports"... I guess I shouldn't have used that word because I really meant all the data about the problem, whether reported by users, sim-monitoring code, statistics from normal operations, or anything else. I agree they almost certainly installed some code for collecting extra data on sim-crossings as well as teleports, but the teleport problems are more "all-or-nothing" in the sense that we (or I, at least) never got them and now we do, whereas I've gotten sim-crossing disconnections (yes, I mean disconnections) for as long as I've been in SL (although, to be fair, I have a crappy Canadian ISP, so others may not have as much trouble). As I was typing, I was reminded of another challenge in diagnosing race conditions: a few lines of debug code can completely change the triggering circumstances, sometimes completely masking the whole event, or shifting it unrecognizably. They really are the worst bugs.
  12. If I were a developer, I wouldn't even look at reports of sim crossing problems while they're able to collect data on teleport disconnects. That's a solid all-or-nothing thing that we know was very rare before. Sim crossings suck worse than before, maybe, but they've always sucked and discerning any signal in that mess of noise has always been nearly impossible. Maybe, maybe the sim-crossing problems are affected by something distinct from the teleport disconnects, but: Occam says no, and Even if so, it'll likely be easier to find it without whatever's causing the teleport disconnections contaminating the data. There could be multiple factors contributing to the teleport disconnections, too, but it almost doesn't matter: race conditions are notoriously difficult to pinpoint, even if it's always the same out-of-sequence event in every failure, and always the same conditions triggering it (which is rarely the case, and almost surely not the case here). Still, yeah, it has been a long time now, and the developers must be going crazy with stress about it -- if they're not numbed to the pain by now. Oh, also a word about viewers: there's practically zero chance the Linden viewer fares any better than the others here. For one thing, for me it has happened more with the Linden viewer than Firestorm or Catznip, but that's possibly due to time-of-day when I use the different viewers -- or just randomness misinterpreted as pattern, the source of all superstitions.
  13. Even though you can change indoors on the ground, having a skybox as a changing room and a home location may be a good idea, too, especially if you can bring yourself to keep it minimally furnished so there's not much to rez up there. You can maybe set up a one-way sit teleporter to make it one-touch (or even a walk-through portal using an Experience) to get to ground, because you can always Control-Shift-H to get yourself back up to the skybox and nobody else needs to follow you without a direct invitation to teleport.
  14. It's my impression that the alarm bells rang, the firefighters all slid down the pole, rode the fire truck sirens blaring, and have been hauling around fire hoses for a week or two. I suspect the developers are deaf to alarm bells by now, no matter how long and loud they're ringing.
  15. They could certainly roll-back to pre-EEP a chunk of the server base, either RC channels or the entire Aditi grid -- if they can get the problem to reproduce in a subset of the grid. But folks seem to think Cake was getting the same problems early in the OS upgrade testing (I guess), so maybe a subset is enough. All this said, it's been close to a week since I've had any trouble with teleports. At all. And I've been teleporting some. And before, for a while, I was having trouble the same as others describe. This kind of bug is really the worst.
  16. First, thanks for the information. It's more than we're seeing in the release notes, that's for sure. At this point, I really think @Oz Linden needs to direct Development and Operations to practice radical transparency about this mess with TP disconnects, region crossings, and I guess EEP. Maybe the OS upgrade stuff, too, to the extent they're investigating that as a contributing factor. I mean, we're all in it together now, and I feel like I'm stuck on a plane on the tarmac with no word from the pilot.
  17. You mean a Library terrain texture, right? I've never known why, but it seems one must first copy it from Library to your own inventory folder, and then when you open it you can Save As to download it.
  18. That's a thing, now that you mention it. I mean, the houses and houseboats and landscaping, etc., aren't the most efficient hunks of geometry, but they're not that bad for textures. In a neighborhood of houseboats, anyway, I think I get all the textures cached pretty quickly. Of course, that doesn't apply to resident-supplied contents, but at least seems that textures (and everything else, somehow) rez faster.
  19. If it turns out that the OS upgrade has anything to do with the current problems, then indeed it's related to the move to the cloud, inasmuch as the OS upgrade is seen as a prerequisite for that eventual move. Eventually. I have to admit that in my limited excursions, I haven't even noticed sim crossings being worse than usual, but they're always pretty awful for me, so it's a signal-to-noise problem I guess. Teleports, however, are intermittently dreadful now -- and then everything clears up and it's all back to normal and I'd think it just something flaky with my often-flaky internet connection were it not for everybody else having troubles too. As unfortunate as the immediate effect this is having on current in-world events, it also has a pretty tragic opportunity cost: before this all started, next up for focused attention was to be the weird degradation in sim script performance some of us have been watching develop in recent months. Not to rehash all that here, but it's another nest of dragons that could bite us at any time. I must say, the current server developers are of intrepid stock. I hope they're well appreciated and compensated. Boy, do I hope that.
  20. It will click, and then you'll just get stuck occasionally, like all the rest of us, and create bugs you just can't see yourself, like all the rest of us. All programming languages have in common that mere mortals created them for mere mortals to use, and one spends more time fixing stuff that's broken than it takes to create all the broken stuff in the first place. LSL is neither the easiest nor the most difficult programming language, but scripting with it is more challenging than it looks because there are obscure quirks in the library functions -- which we all learn over time and yet still somehow get bitten by, over and over. Will you be able to program anything you think of? No, not if you have a healthy imagination. But the fun part is discovering a way to program something that seemed impossible at first. Do that a couple of times and you'll be hooked.
  21. And the OP is on the right track here: those residents who want "total privacy" really need such estate-manager control of that location -- which means an Estate that caters to that market. It simply cannot be achieved on Mainland even with all parcel settings cranked up to 11 and an instantaneous ejector orb.
  22. Yes but they're a minority, and they cause a lot of grief for others. Kind of a tragedy of the commons, really. Or anyway some kind of moral hazard.
  23. The Lindens created a continent without banlines and zero-trigger security orbs. No Mainland landlord can do that. There's certainly still a role for Mainland rentals, but I wouldn't underestimate the draw of a whole hassle-free continent, either. Mainland serves a very diverse market, but it's also uniquely appealing to explorers and vehicle users.
  • Create New...