Jump to content

Oz Linden

Lindens
  • Content Count

    269
  • Joined

  • Days Won

    1

Posts posted by Oz Linden


  1. 8 hours ago, MBeatrix said:

    Not to mention that the inventory service has been slow for weeks... Not always, but enough times along a day to be annoying.

    Forgive me for using your post as an example @MBeatrix; I don't want to pick on you at all. We do rely on user problem reports for detecting many kinds of problems, but the quality of the reports make a huge difference in how effective they can be.

    This report doesn't have enough information in it for us to even begin to investigate.

    • What inventory operations are "slow"?
    • Quantify "slow"
    • What viewer?
    • What regions are you in when they are "slow"?
    • When is "for weeks"?

    Specifics might allow us to correlate the problem report with changes we've made to the deployed services, including changes to backend systems that may be made at times other then when simulators are updated. Note that if you fill in a BUG report in Jira, and just copy into the Environment for the bug all the information in your viewers About Second Life floater, you'll have provided much of that.

    8 hours ago, MBeatrix said:

    Inventory slowness may be due to a poor quality CDN service, and maybe some of the other issues have the same cause.

    This comment illustrates a common communication problem; this gets a bit geeky, but the better we all understand the same vocabulary, the better we'll be able to help each other to identify and solve problems...

    • "Inventory" is a database of items either owned by an agent or inside an object. When you open the inventory floater or the content pane of the build floater, you're looking at that list. But the list does not contain the actual objects - it's essentially just a set of named pointers to the objects.
    • "Assets" are the actual objects. They're not stored in the inventory database, they're in a completely different (very large) data store of every object in all of Second Life.

    The Inventory database is manipulated by talking to that database through the simulator.  If you move an item from your personal inventory to the contents of an object, for example, you're removing a row from your inventory and adding a row to the inventory of the object, but you're not actually moving any of the data for the object those rows point to.

    Most Assets are accessed through the CDN (there are a few exceptions that are managed through the simulator for security reasons).

    This is why it's important to understand what operations are "slow" (or have some other problem); some operations are just interacting with the Inventory database, some are interacting just with the Asset store, and others are doing both.

    • Like 3
    • Thanks 2

  2. 13 hours ago, NeoBokrug Elytis said:

    It hasn't been brought up here, but there are a lot of problems with the latest roll concerning objects being rezzed, http services, and I believe llRegionSayTo().  The most recent bugs on the JIRA highlight a lot of the issues -- but because they're intermittent it's hard to test and nail down exactly what is going on.

    A lot of SL content is affected by this, and I think you should consider rolling server versions back.

    See the Status notice

     

    • Thanks 2

  3. 17 hours ago, Aishagain said:

    I recall Oz saying that the new Roll strategy would result in less downtime for the regions, not more. 

    We're making a series of changes that I hope/believe will result in rolls that will reduce downtime and solve some other roll-related problems (some of which are purely internal). Those changes are being made slowly so that we can measure the effect of each change carefully. The roll this week was deliberately slightly slower than normal (I don't have the numbers yet, but we're collecting data); future changes should reduce the downtime for each region during the roll, but those changes will be made one at a time over the next several weeks. I don't think that any of those intermediate steps will increase the roll time further, but stay tuned...

    • Thanks 2

  4. 15 hours ago, KT Kingsley said:

    Are simulators or servers limited in the volume of HTTP traffic they can handle? Could there be another script (or scripts) in this region (or another region sharing the server) especially busy handling HTTP traffic?

    Yes, there are limits.  Depending on circumstances you may get a debug channel notice when a limit is reached, or you may get this error.

    Yes, competing with other scripts that are making large numbers of requests can cause this error.

    As @animats said, a backoff and retry is the appropriate way to handle this.  There's an example in the wiki of a simple structure for doing these retries (it's written in terms of an initial registration of your script with an external server, but the method used is general and can be applied to any outgoing request).

    • Thanks 1

  5. 21 hours ago, MissSweetViolet said:

    Ever since about June, I have been having issues logging in to second life on the official Linden Labs viewer. I spend on average 20 minutes trying to log in every time I come on. I will usually ether have it log me out immediately on getting into the game, it'll log me in, but underwater, and I can't TP or do anything, or it'll stall on the log in screen till I force quit it, eventually I will manage to log in, but it takes forever. Some days are worse then others. Ever since the most recent update, I have also started to have the TP log out issue again, though not as bad as it use to be.

     

    Most likely your problem is actually something wrong with the connectivity between you and the servers (if you have a Windows or third party firewall active on your system that may be contributing). I suggest that the next time you experience a problem, save your viewer log file and contact Support to help diagnose the problem. 


  6. 2 hours ago, Aishagain said:

    1) On a region with multiple parcel "owners" I understood that ALL the owners had to be in agreement before a channel change could be requested.  Now, if I am wrong then I apologise, we were told this many months ago by support.

    I'm not in Support, so whatever I say must be taken with a grain of salt. My understanding is that the request must come from the region owner. I don't know how they handle mainland and other Linden-owned regions.

    2 hours ago, Aishagain said:

    2) In future when channel information is not available and regions can be moved from one channel to another at LL's whim, how will we KNOW to ask for a change of channel rather than just a restart or a fresh server?  So far as I can see we would have no way of knowing.

    We will continue to post release notes, and link to them from the About Second Life floater; you'll be able to tell what version you're on. If some behavior changes that's causing you a problem then Support will be able to move you off of it, but please file a bug report first so that we can fix it

    Really, all we're doing so far is to hide the name of the RC; whether or not you're in an RC is not really hidden if you just click through to the release notes.

    2 hours ago, Aishagain said:

    WHY are you doing this?

    It's just one part of a much larger effort to make our simulator evolution more stable. Right now, the RC channels are not very good models of the grid as a whole. Some recent problems got to main channel because they didn't happen (or didn't happen much) in the RCs, or weren't detected when they did. Other parts of this project include much better reporting on what's happening, including things we have not monitored closely before. We're also developing ways of making the RCs more representative of the grid as a whole, but doing that will require being able to change their populations. Our objective is to find problems more quickly and reliably.

    • Thanks 4

  7. 4 hours ago, Aishagain said:

    Apart from anything else, one upshot of The Lab's avowed intent is that builders will now have avoid TWO days when restarts might interfere with their work rather than just one, since regions will be "arbitrarily" moved between channels as LL see fit.  Won't THAT be popular!

    We fully appreciate that predictable roll days are important, and that will continue to be a design constraint. Nothing is changing about when rolls happen for some time, and we'll provide ample notice and time for feedback when/if we make any change to that.

    4 hours ago, Aishagain said:

    I know of at least one parcel owner that has just spent a LOT of RL money to move away from the somewhat capricious RC channel changes in the (seemingly futile) hope of a little more stabilty. 

    For a region owner, all that is required to move on to or off of an RC (or any RC) is a support ticket. That will continue to be true.

    Sometimes being on an RC is more stable than on the main channel; when we're fixing bugs, that's certainly our objective.

    We're going to try to provide more useful information on what is changing in each new server release, but sometimes we just can't - for example, it wouldn't be a good idea for us to describe that we've disabled a particular griefing vector if it's only disabled on one RC.

    • Thanks 4

  8. 15 hours ago, Penny Patton said:

    Beyond not being able to make a proper rural night sky, Second Life is a virtual world. It would be great if we could push it beyond the realistic. Like being able to make the largest stars in the sky even larger and brighter than you would see even in the most remote setting. I mean, why not go crazy with it? Letting people make a night sky that looks like you're standing on a planet in the middle of the Pleiades or something. Just with the star settings. That would be amazing.

    Customized stars was considered, and didn't make the cut this time around. It's still on my personal watch list, so maybe next time.

    • Like 1
    • Thanks 5

  9. 18 hours ago, Kurshie Muromachi said:

    No. I heard some "rumors" years ago about people using voice to exploit/leak real IP addresses. I don't know if that was true or if it's still true, but not bothering to chance it. If anyone has the official word on this, I would like to know.

    That's true only for direct person to person voice calls. Any group/local/conference voice is anonymous because you are connected through a mixer. 

    • Like 3
    • Thanks 6

  10. On 8/17/2019 at 10:05 AM, jillgoodgal said:

    So, I take it that I got the EEP viewer as an update because I was a parcel owner?

    Nope, just dumb luck.

    When we have a viewer in a nearly-releasable state (in this case, that turned out to be a little optimistic), the last phase of the release process is to offer it as an upgrade to a cohort of randomly selected users. Second Life is so large and complex that it's just not possible for us to test as much as giving to real users will. Normally, once you're on a Release Candidate like this, you'll keep getting those updates, but by manually downloading the default release you removed yourself from the test.

    For details, see http://wiki.secondlife.com/wiki/Viewer_Integration_and_Release_Processes#Release_Candidate

    • Thanks 1

  11. This is an optical illusion. The further away an object is, the less often the viewer runs its animations (to save trying to make what will be very small changes in distant objects). When animations loop, the updates can end up looking backwards for the same reason that a fan viewed with a strobe light will look like it's running in reverse at some strobe frequencies.

    • Thanks 5

  12. The "flat inventory" problem is very simple... if you have too many items in a single folder, especially the (invisible) top level folder of your inventory, it will slow down login. An 'item' for this purpose is either a folder or something else (an object, a notecard, anything). If you have enough of those very large folders, it can slow down login so much that it times out and you can't log in (if it doesn't happen every time, you're probably right on the edge of too many). It's only one level deep that counts; if folder A has 50 items, one of which is folder B, and B has 12,000 items, those 12,000 are not added to the count for A.

    We've cautioned people about this many times.

    Our support team does have a tool that "unflattens" your inventory by creating new subfolders and sorting the items into the too-large folders into those subfolders. They can apply that tool to your next login if you report a problem and it looks as though it might help.

    • Like 1
    • Thanks 2

  13. On 8/10/2019 at 5:09 PM, Chic Aeon said:

    I am using the not so new Firestorm ( Feb  9 2019 18:55:39 (64bit) (Firestorm-Releasex64) with Havok support)

    Testing the appearance with any viewer other than the EEP RC viewer is not very meaningful, since only that viewer has the shader changes that accompany the new settings and capabilities.

    We appreciate that the rendering in this overlap period before the TPVs all have the same rendering pipeline as our viewer is frustrating, and regret having gotten into this situation; we (specifically I) thought that this overlap period would be very short, but it hasn't worked out that way. My apologies.

    We're working as hard as possible to get the EEP viewer into shape to promote to default, after which we expect that it will be quickly available in most TPVs.

    • Thanks 3
    • Sad 2

  14. On 8/11/2019 at 1:09 AM, Prokofy Neva said:

    Why is it even needed? What, LL's servers can't themselves tell what version is logging on without having to put files on your computer to do this?

    It allows downloads for optional upgrades to happen in the background so that you don't get prompted about the upgrade until the file is ready to be installed.

    More importantly, it is a 32bit application so that it can check whether or not your system is compatible with the 64bit viewer (a test that's not as simple as whether or not it can run 64bit apps, since some video systems are not supported in the 64bit Windows). By doing that test, it can ensure that no matter which build of the viewer you start with you end up installing one that should work on your system.

    • Like 5

  15. When reporting a DNS problem, it is helpful if you describe what you were doing (opening a browser to the marketplace, logging in the viewer, ...), specifically where you are, if possible including what ISP you are connecting through.

    DNS is a global distributed system, with potentially many layers of caching between you and the systems that provide the information about our current names and addresses; some of those layers don't follow all the rules or are buggy enough that they are sometimes not in sync with us.

    Flushing your local cache may sometimes help, but won't help with the cache you probably have in your home router, the ones in your ISP, or any of the others that may be in the path. Debugging this can be very frustrating.

    There's a pretty good page on debugging DNS at https://www.a2hosting.com/kb/getting-started-guide/internet-and-networking/troubleshooting-dns-with-dig-and-nslookup

    As far as I can tell we didn't change anything last night involved with this, and right now I don't see major providers that have bad data.

    • Thanks 3

  16. 3 hours ago, Lucia Nightfire said:

    I don't consider using string literals to hold data outside of valid url format a hack.

    ... but note that Linden Lab does consider it a hack and not supported. We've already been through one round of data loss by users doing this when we improved the parameter validation; that could well happen again.

    The first law of software reliability: Use it the way the author intended.

     

    • Like 4
    • Thanks 4

  17. 25 minutes ago, KT Kingsley said:

    Is stuff like location at relog to last location, state of scripts and script-saved data useful or relevant?

    Bad effects on scripts may be relevant (or may be bugs in the scripts... hard to say), so it's fine to include it.

    Subsequent login attempts, regardless of where they are, are not part of the base problem we're most interested in right now.


  18. We are very interested in hearing about TP problems, but it will be far far more useful if you report all of the following:

    • When it happened; this doesn't have to be exact - within a few minutes is plenty accurate. Tell us what time zone you're using (SLT is easiest for us)
    • Where were you when you tried to TP?
    • Where were you trying to go?  (region names is all we normally need for start and end locations)
    • If you ended up somewhere else, where was it?
    • Were you disconnected or did you crash?  If the viewer window disappears with no message, you crashed; if not, you were disconnected.
    • What viewer were you using? (copy the information from Help > About Second Life)

    It's easiest for us if you report those in jira, but contrary to what some people think we do watch the forums.

    This issue is a very very high priority for us right now, so we really will use reports we get, but none of the above is enough for us to learn anything from. If what you want to do is just vent your frustration by all means go ahead, but if you'd like to contribute to solving the problem we need the information above.

    • Like 4

  19. 14 hours ago, iMeeky said:

    First and foremost, processing credit means you are taking your Linden Dollars and turning them into US Dollars.

    That is incorrect. The term 'process credit' means withdrawing your US Dollars (transferring them to PayPal, Skrill, or any other outside institution).

    Please see this thread for official clarifications.

    • Like 5
    • Thanks 7

  20. This is quite a bit more involved and expensive than it needs to be. You're essentially using the SHA1 value as an expensive index into a list; if both scripts have the same list of textures in the same order, just passing the index into the list is just as secure and much cheaper.

     

    • Like 1
    • Thanks 2
×
×
  • Create New...