Jump to content

Oz Linden

Lindens
  • Content Count

    264
  • Joined

  • Days Won

    1

Everything posted by Oz Linden

  1. Nalates Urriah wrote: I see Jelly Babies even with the slider maxed out. Most of that is due to one bug in the comparisons that we've got a fix for ... next update.
  2. seanabrady wrote: The assumption then is that VMM RC will be promoted to the defacto release prior to the 23rd? Probably not because we've just done a promotion and we don't feel we need to push a new update on everyone immediately just to get it to Merchants, but it's available now and we don't know of any problems with it. It is first in line for the next promotion though assuming that nothing really bad happens.
  3. You might try the "Big Bird" release candidate viewer - it has many fixes for attachment problems. See http://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers
  4. Theresa Tennyson wrote: If you prefer using the Linden Lab viewer you can use the "Obsolete Platforms Viewer" on this page. Make sure you go to "Preferences" and turn off automatic updates. No need to turn off updates; there won't be any. That viewer is in its own update channel and we won't be building or releasing any more in that channel. Most systems that can run XP can at least be upgraded to Windows 7, which would get you back onto supported viewers.
  5. Sorry - Second Life simulators rely on a very large set of backend services to work. Even we can't create a standalone simulator.
  6. Samual Wetherby wrote: Which is what several of us in this area need. Some sort of multi user data information that points to an ISP issue. But everything I see points only to a CDN issue. From where you're sitting, it's impossible to tell the difference. What tells us that it's the ISP is that there are many customers successfully using that same CDN node from other ISPs in your region without the same problems. As for finding information to give to your ISP, here's how to find it in your SecondLife.log file. There are two similar log entries that will show up that show an http request failure: 2015-03-13T02:01:48Z INFO: LLTextureFetchWorker::doWork: HTTP GET failed for: http://asset-cdn.agni.lindenlab.com/?texture_id=65e28e31-9700-7784-4181-796869041279 Status: Easy_28 Reason: 'Timeout was reached' 2015-03-13T02:19:50Z INFO: LLTextureFetchWorker::doWork: HTTP GET failed for:http://bake-texture.agni.lindenlab.com/texture/4c4ab9a6-0d19-4428-957e-bd283729474c/head/874a0639-79e0-c470-149b-fbd1b20c3d4d Status: Easy_28 Reason: 'Timeout was reached' The entry with 'asset-cdn' is either a texture or a mesh, and the one with 'bake-texture' is an avatar baked texture (either may be followed by .agni.lindenlab.com or .gbl.agni.lindenlab.com). The names are different mostly for historical reasons - they go to the same place. If you (or your ISP) looks up the translation of the domain names in bold in those messages, you'll see which CDN node they point to. That mapping may change depending on configuration changes. A traceroute to those names will show a network path to the node (depending on how your ISP is configured, there may be more than one... sometimes diagnosing these things from the edge is just hard).
  7. Samual Wetherby wrote: Just so odd to go up to mid Feb without a problem. Everything popped info place. No rez issues then like clockwork failures. Up until we began using the CDN, all your texture and mesh fetches went to our datacenter in Phoenix. Now, those fetches go to the CDN node, while the rest of your communication still goes to the simulator in the datacenter. Those used to be the same path, and evidently that path was pretty good for you. However, it's a different path to the CDN node now (we verified this during the testing), and that path exhibits high packet loss during the times that you're having problems. That won't show up in the packet loss stats reported by your viewer, because that stat is only for UDP traffic - which all goes to the simulator and is apparently fine.
  8. The times you cite are in fact not even close to Second Life peak times - those are (roughly) Noon to 5PM SLT. They are, however, exactly the peak times (evening tv streaming, online gaming, and web surfing) for a primarily residential cable ISP on the US east coast. That the network path(s) between such an ISP and a major CDN node would be more stressed during those times isn't at all surprising. We've done quite a lot over the last year to make the network behavior of the viewer less stressful to and more efficient in its use of the network, and that work is continuing (look forward to other asset types like sounds and animations being delivered faster in the coming months). As I mentioned in the Jira issue, we also plan further improvements to the CDN configurations (I don't have a time frame for those changes yet, and probably wouldn't post them here now if I did because they might change). We can hope that those changes will help with the particular problems working through your ISP - we're confident that they will be better in other ways, but since we don't know enough about the network topology, configuration, or load at your ISP we'll have to wait and see.
  9. There are any number of things that can cause rez failure, but you have not given any actual information that might be useful helping to find what's afflicting you. Incidentally "the latest update" isn't descriptive enough for us to identify even what viewer you're using. As I'm writing this, we have 4 different candidate viewers in use in addition to the most recently released default viewer (3.7.25.299021). You can find all the information about which viewer you have in 'Help->About Second Life'.
  10. Whirly Fizzle wrote: Their content can still be used though, there's nothing stopping them from wearing it and seeing themselves correctly. When this new automute feature is out, all that will change is for those users who decide to enable the feature (maybe it will be enabled by default for very high draw weight avatars?) will see the high draw weight avatars as an imposter - unsure yet if LL are going to keep the multicolour jellybaby imposters for this feature (current behaviour) or change it to the normal "2D cutout" imposters. The current thinking is that we will use the mono-colored avatars for those who are over your limit (I've toned down the brightness of the colors a lot), and continue to use the "2D cutout" (really, we just leave out some of the fancier shader passes and update less frequently) style for more distant avatars. We've also changed the coloring of the avatar draw information display so that it's relative to your own limit, not some arbitrary values we've picked; those under your limit will be green or green-yellow, shading toward red for those far over your limit. The hope is that will help you decide how to adjust your own limit. Each avatar will also report to the simulator whether or not each of the other avatars it sees is over its own limit (without reporting what that limit is). My current thinking is that the simulator will use that information to report to each avatar an approximate percentage of those who are limiting rendering, so that you'll be able to tell whether or not others can see you in all your blinged-out glory.
  11. That was an awful lot to digest all at once. We have an active open source program; you're welcome to conduct some experiments to demonstrate problems and help develop solutions. I look forward to your contributions, but please give them to us in smaller bites so that we can keep up.
  12. Alas, no, there isn't. There's a lot of information on wiki.secondlife.com (some of it, like most wikis, not as up to date as we would like).
  13. I didn't discuss linux crashes in that post because the 'version' reported for Linux isn't very useful. We do collect crash statistics on the linux viewer, but the number of users running our builds on linux is so small that the sample sizes are too small to make meaningful comparisons.
  14. If you're having this problem, we could use a copy of your log file. Whirly Fizzle added a very helpful comment about how to collect the information we need and post it to the Jira in https://jira.secondlife.com/browse/BUG-7776
  15. Another small note about what this does and does not affect... The CDN (and HTTP in those viewers that have them) improvements for texture and mesh data are improvements to how long it takes to download the the data. Once they've been downloaded, your viewer caches them locally so the next time you need that data it doesn't need to download them at all. What that means is that these improvements mostly affect how quickly you see new things: places and objects you've never seen before. You probably won't see a big difference in familiar places because your viewer should be using cached data for those. So... now's the time to try checking out places you've never seen before! The use of pipelined HTTP for the initial load of your inventory when you log in matters every time, since while we cache some inventory data locally we always make sure it's correct by loading it all at the beginning of your session.
  16. Ai Austin wrote: I read the tech paper from HighWinds on the CDN.. and with all the caching and proxies I wonder if it will work well when there are rapidly changing assets such as presentation screen content, moving objects meant to be seen synchronously by others, and changing clothing and hence baked textures for avatars. Does this get pushed quickly to all cache copies? May be worth a test and see if its more delayed than before? Texture and mesh assets don't change... what you're seeing when the appearance changes is that one asset is being replaced by another, so the cache for each (whether in the CDN or in your local viewer cache) remains valid.
  17. There are no rendering changes between this viewer and its predecessor; any differences you're seeing are for other reasons. All this changes are how we download textures, mesh data, and inventory.
  18. The CDN will improve texture and mesh load time for anyone on any viewer. (in theory, maybe not for a very very small subset of users who happen to be very very close to our datacenter, but even they shouldn't get much worse). The viewer changes are complementary to the CDN, and when those code changes are integrated into a TPV you'll see another performance bump.
  19. Sparkdaemon wrote: Improvements? i didn't noticed anything. But i noticed that the ping (who were ~ 120 ms before the update) is now around 240 - 300 here (France). it's now impossible to do some think like drive, fly precisely (Was already hard before) and all the stuff who need precision. Don't tell me that it's my connection, I have ~22ms on google servers. EDIT: I use Firestorm, and same problem with Singularity and Alchemy Firestorm and Singularity have not yet adopted all the improvments we've made (doubtless they will soon). I believe that Alchemy just released a version with pipelining. The changes we've made shouldn't have any negative effect on the ping time that's reported in your viewer. That number depends most strongly on the network path between your viewer and the simulator and to some extent on how loaded the simulator is. A difference as large as you're seeing is certainly in large part a change (hopefully temporary) in the way the network between us is behaving; something we can't do much about. Since Google is on entirely different systems elsewhere in the network, times to them don't tell you anything at all about time to us; the path is likely completely different beyond the first hop or two.
  20. We moved out of the facilities we had been using in Dallas; it's all in Phoenix now. Well, we call it Phoenix... I assume it's in that general area somewhere - I don't need to know, and usually you won't either. With the use of the CDN, your network distance from the datacenter will make much less difference than it did before.
  21. Looking at the code (I had not had occasion to look at this before), the Ping Sim measure appears to be based on a separate Ping message (our own message type transmitted over UDP, not ICMP). Those messages are mixed in periodically with the other UDP messages that are more or less constantly flowing between the viewer and the simulator. Because it's the application that is turning that message around rather than a low level part of the network stack, the fact that it is consistently higher than ICMP ping to the same host isn't surprising. It's hard to guess what that 7 second display meant... it's possible that the simulator was temporarily not responding for a few seconds but eventually caught up, but without much more data that's just speculation. When we first set up the Snack channel, we deliberately used regions that were getting a lot of avatar activity so that we would get a better sample of the resulting texture and mesh fetching activity and how it changed the load on the simulators. Due to some unforseen aspects of how we did it, we ended up making some simulator hosts handle quite a bit more activity than is typical; in a very few cases, that resulted in noticable problems for users (we moved some regions out of the test as a result). You may have seen one of those episodes. The tests of the same CDN change on the BlueSteel RC at normal loads have not shown any problems like those, so we are confident that they were just a result of the unusual load pattern. As others have commented here, both the Ping Sim and the packet loss numbers are based only on the UDP; they don't reflect what may be happening on the HTTP/TCP connections, since any packet loss on those is detected and corrected automatically by the network stack. One of the reasons that it can be bad to set your Bandwidth setting very high is that it allows the amount of UDP to increase too much; since UDP does not have any other form of congestion control, too much of it can cause loss of TCP packets, resulting in much reduced performance on those connections.
  22. Try the Benchmark viewer: https://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers#Second_Life_Project_Benchmark_Channel it is designed to once and for all solve exactly the problem you're having. Let us know how it goes...
  23. report in Jira as usual. It should be sending a crash report, but it doesn't hurt to also file a BUG.
  24. You didn't mention what viewer and version you're using... without at least that much, it's hard to offer advice. The first step is going to be to figure out what's different in how you're accessing SL, since as far as we can tell after the Interesting changes were deployed (some time ago), things got better not worse.
  25. I believe that statement is just incorrect. Getting the wiki fixed....
×
×
  • Create New...