Oz Linden

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.

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.

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.

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.

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.

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.

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...

report in Jira as usual. It should be sending a crash report, but it doesn't hurt to also file a BUG.

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.

I believe that statement is just incorrect. Getting the wiki fixed....

You have that exactly right, Qie. We're working out the details of exactly how a user gets additional keys, but the goal is to keep it simple.

For all practical purposes, anything you use a given key for is part of the same experience; that's what defines an experience. You could use it for things that are not otherwise related to each other, but internally they are all relying on the same key, so if the key is turned off, they all turn off.

It's on the list of fixes to be done.

This is one that the Moles had asked for when building the Cornfield, and one of my personal favorites...

I disabled "http textures" and "http inventory" and sculpts and textures rezzed for me. My character and meshes dont show yet. Interesting. That points to your filter as being the problem. Character and mesh data can only be fetched with http. You didn't say what sort of filter it is, but whatever it is is way too aggresive.

Perrie Juran wrote: Just get a friend who owns an Estate Region to do a restart for you. You could even plan an Earthquake party! Besides, I want to know if it makes everyone's boobs jiggle. Now that would have been something... alas, no, it doesn't. We just shake the camera...

By default, the viewer checks for an update when it is launched (even before you log in), and then once an hour after that. If you have not logged in yet, it downloads any update as fast as it can... once you're logged in, it throttles that download so as not to affect your viewer performance. If you disconnect before the download is complete, it will try to resume where it left off. The combination can mean that you can get the update any time during your session (especially if you have a slower net connection). You should be able to decline to install an update if you're already logged in... if you do, it will do the update automatically on your next viewer launch.

"latest Linden viewer" isn't enough information... at present we have 5 "latest" viewers. Which do you have?

With full appreciation for how frustrating crashes can be, a post like yours doesn't give anyone enough information to even begin to help you. Start with exactly what viewer were you using (copy all the information in the 'Help>About Second Life' floater and paste it into your description... there's even a handy button in that floater for doing the copy) what were you doing when you crashed? what exactly happened (did the the window freeze, did it just close, was there a message displayed, if so the exact text of that message)? it sometimes helps to look in your SecondLife.log file for lines with ERROR on them As much as we'd like to be able to magically solve your problem, you need to do your part too.

Nalates Urriah wrote: A version like 3.7.2 should have all the changes places into 3.7.1 and prior versions. I get a bit fuzzy on what is in which build version... build numbers are like: 286707. I have seen versions like 3.6.1-288080 where the build number is greater than the build number in a 3.7.2 version. The 3.6.1 does not have all the fixes in the 3.7.2. But, because it is a higher build number there is something newer than what is in 3.7.2. But, we will not see whatever it is until that build is upgraded with the changes in 3.7.2. Here's a quick tutorial on the viewer version numbers... A version number is four integers separated by dots (3.7.2.286707). Numbers at each level are incremented when something new happens; the more important the something, the further to the left the incremented number (so "Fitted Mesh" changed the second level number from 6 to 7). Most versions increment the third level (2 in this example). If the first three numbers in a version are greater than those numbers in a given default release viewer, then that version (which may be a project viewer or release candidate) has everything in the release viewer. When we decide that a given version is going to be the default viewer, all the changes in it are added to all the projects we're working on, so all the fixes and features in 3.7.1.286557 (which was the default release until this past Monday) are in any viewer whose number is 3.7.2.anything. If two viewers have the same first three numbers, they probably have distinct sets of changes compared to that common base. The fourth level is special - it's the 'build number'. It's a monotonically increasing number generated by our build system, so basically it tells you which viewer was built first. It's useful only within a specific project and doesn't tell you much between projects.

Gadget Portal wrote: LL doesn't read the forums. You just wasted your time. Not true. For bugs, Jira is certainly the best thing to do, but there's no reason to discourage people from making suggestions here.

Did you try the lower right corner?

Second Life 3.6.2 (279258) Jul 30 2013 That's a 6 month old viewer... try updating it.

The name of the viewer executable was inadvertently changed in 3.6.12 from 'SecondLife.exe' to 'SecondLifeViewer.exe'; the folder and shortcut names did not change, just the actual executable. Unfortunately, the old executable was not removed as part of the upgrade. I suspect that you are launching the viewer through a shortcut that you copied or created somewhere that is not updated by the upgrade, so you're still running the old executable each time instead of the one you upgraded. Check your shortcut and correct the name, or just delete it and copy from the default shortcut on the desktop. That will use the new name, and you'll escape that cycle. We plan to stick to the changed name, but a future update will clean up the old executable (it's perfectly safe to just delete it yourself now). Sorry for the inconvenience.

The Belkin routers are generally underpowered for running a firewall when there is a lot going on (and an SL Viewer is a lot). I suspect that what's happening is that while the firewall is deciding what to do with one set of requests, a whole bunch of others are getting dropped. The symptoms match.