Category Archives: News

SL project updates week 44/2: server, viewer, issues

Darkwood, for a Calas Galadhon Halloween

Darkwood, for a Calas Galadhon Halloween! (Blog post)

Server Deployments Week 44 – Recap

As always, please refer to the server deployment thread for the latest information and updates.

  • On Tuesday, October 28th, CDN support was deployed across the Main channel, meaning that the entire grid now utilises the Highwinds CDN for texture and mesh fetching. As the 130 regions deployed to the Snack channel were all originally from the Main channel, they have been reabsorbed into that channel, and Snack has once again be dissolved
  • On Wednesday, October 29th, all three RC channels received the same server maintenance project. which includes some minor improvements, which wer described by Maestro Linden at the Server Beta meeting on Thursday, October 30th, as, “just some code cleanup and some extra optional debug logging.”

SL Viewer

On Wednesday, October 29th, the Lab promoted the HTTP Pipelining RC viewer (version to the de facto release viewer. As I’ve noted in previous blog posts, this viewer:

  • Can issues multiple asset fetches on a connection without waiting for responses to earlier requests. This reduces the impact of a user’s physical location on scene loading and generally improves the experience for everyone
  • Includes significant improvements to inventory folder and item fetches, which can markedly decrease the time taken for inventory to load.

All other SL viewer remain as per my Current Viewer Releases page.

Issues and Problems

Mesh Loading Issues

There have been mixed reports of mesh loading issues, which may or may be linked to some long-standing issues with mesh attachments. During the Server Beta meeting on Thursday, October 30th, the issues of mesh items which should be cached by the viewer being slow to load, don’t show up at all or show up with a low LOD, requiring a relog. Interestingly, the meshes can appear correctly when using one account, but not with another, either though both accounts are drawing from the same viewer cache.

Whirly Fizzle noted that there is a potential (and equally weird) fix for odd mesh loading issues, commenting:

There’s a weird mesh loading issue (not new) that’s “fixed” by deleting a certain per account file. I don’t even know why it should even work but it does. Sometimes a certain mesh gets stuck and will not render for a certain account. Relog doesn’t fix it & neither does a cache clear. You have to delete texture_list_last.xml in the per account settings files.

Texture Load Issues

There have been a couple of reports of texture loading issues which are still under investigation.

In the first, there have been  some reports that textures are getting stuck when “half loaded”, so that they remain blurred or may fail to render. It’s not clear how widespread this issue is, or whether it might be related to BUG-6382, although this is also unclear.

In the second, one content creator has reported customers are suddenly having issues with a HUD-based system for changing the colour of their shoes. When used, the textures rez very slowly, or the shoes get stuck as grey for up to 5 minutes at a time, or get stuck at a 1st level load until the wearer teleports or relogs. This is apparently a completely new behaviour with the shoes in question, and it appears to be exacerbated when using the HTTP viewer.

AMD Catalyst™ 14.9.2 Beta Woes

The latest AMD Catalyst™ 14.9.2 Beta drivers will not render rigged mesh unless hardware skinning is disabled. The current workaround is to either disable hardware skinning (which is not ideal when it comes to rendering mesh in general, and ALM features like materials will not render) or to remain on / roll-back to the 14.9.1 beta drivers if the problem is encountered. See BUG-7653. As was mentioned in the Server Beta UG meeting, this could be particularly confusing to new users running AMD GPUs and who are using the Lab’s default mesh avatars.

The latest AMD Catalyst™ 14.9.2 Beta driver issue: with Hardware skinning enabled, rigged messhes will not render (l); disable it, and they'll render OK (r) - click for full size; image courtesy of Maestro Linden

The latest AMD Catalyst™ 14.9.2 Beta driver issue: with Hardware skinning enabled, rigged meshes will not render (l); disable it, and they’ll render OK (r) – click for full size; image courtesy of Maestro Linden

E-mail Communications Issues for In-world Objects

A further JIRA has been filed in respect of e-mail communications with in-world objects hanging for no readily apparent reason (see: BUG-7554). similar issues have been reported in the past (although this one has a publicly viewable report), and Caleb Linden is currently poking at things.

Continue reading

Lab asks: how is SL for you?

Just Another Tequilla Sunrise, Isle of Love; Inara Pey, October 2014, on FlickrSL should be looking and feeling a lot better for many of us as a result of recent work by the Lab – how’s it going for you? The Lab asks you drop them a line in the forums or via Twitter (image: Just Another Tequilla Sunrise, Isle of Love (Flickr) – blog post)

Following-on from the grid-wide deployment of CDN support and the promotion of the HTTP pipelining viewer as the de facto release viewer, the Lab has blogged about recent improvements to Second Life, finishing with the question “how is it for you?”

The blog post, entitled, Performance, Performance, Performance, opens thus:

Has Second Life seemed a bit faster for you lately? Improving performance for all Second Life users has been an important focus for us at Linden Lab, and we’ve recently seen some great results from several projects that should make your Second Life experiences faster, smoother, and more reliable.

It goes on to make fair mention of the CDN / HTTP work, noting:

Faster Texture & Mesh Loading
The entire grid is now using a CDN service for textures and meshes. This change means that textures and meshes should load more quickly, particularly for those who login to Second Life from places that are far from our US data centers. Our testing showed dramatic improvements: average download times for textures and meshes have been reduced by more than 50% on average, and the improvement is even more dramatic outside of North America.

Quicker Viewer-Server Communications
Another way we’re enhancing Second Life performance is through our HTTP project, which improves the way your Viewer communicates with grid services. With the HTTP Project Viewer out now, the faster content download times you’ll see thanks to the CDN change get even better – we’re talking 80% faster!

For those who may have missed news on the HTTP pipelining viewer and the CDN support, you can catch-up with things via a couple of posts on this blog: SL project updates week 42/2: Monty’s HTTP update and the HTTP pipelining viewer, and HTTP pipelining viewer reaches release status as CDN support is grid-wide.

Mention is also made of the recent Group Chat updates (work is still continuing on this, and you can get updates via the Group Chat tag in this blog).

However, perhaps the most interesting aspect of the blog post is the news that there have been some significant infrastructure updates with the SL Marketplace, which appear to have slipped mention through other mediums such as the var UG meetings. Here the blog post notes:

Speeding Up the Marketplace
If you visit the Marketplace today, you should be seeing a much snappier experience than in the past. We recently deployed infrastructure upgrades for the Marketplace, and the site has since shown some of the best performance we’ve ever seen from it. Even during peak usage periods over the weekend, when in the past performance would degrade, we’re seeing response times that average 70% faster and page load times that are 30% faster than before the changes.

I’ve not used the Marketplace of late – although I have been covering the upcoming Viewer-managed Marketplace (VMM) changes that will be occurring in 2015, and which the Lab is currently gearing-up for, along with merchants and TPVs.

So have you noticed changes and improvement in your Second Life experience? If so, then why not follow the Lab’s request:

So, How’s Second Life Performing for You?
Performance improvements are generally behind-the-scenes work, and we know it’s not always as exciting as rolling out a new feature, but these changes directly impact all our Second Life experiences and our daily lives in-world. We hope you’re starting to notice the effects of these improvements – if you are, please let us know in the Forums, on Twitter, or however you prefer.

Note that is let the Lab know – not me (although general views are always welcome here, they might not be picked-up by the Lab)!

HTTP pipelining viewer reaches release status as CDN support is grid-wide

On Wednesday, October 29th, the Lab promoted the HTTP pipelining viewer to the de facto release viewer, a move that came just after the grid-wide deployment of CDN support on Tuesday, October 28th. While the two are complementary rather than reliant upon one another, both should help improve the majority of users’ Second Life experience to some degree.

Monty Linden: the HTTP pipelining viewer marks the culmination of over 2 years of work inproving SL's HTTP capabilities

Monty Linden: the HTTP pipelining viewer marks the culmination of over 2 years of work improving SL’s HTTP capabilities

The HTTP pipelining viewer is the latest phase of over two years of work on Second Life by Monty Linden, and which has involved both the viewer and the servers and back-end services which support SL.

The work, originally a part of Project Shining, which was itself heralded as complete in June 2014, initially focused on texture handling between the servers and the viewer. Since then, Monty has gone on to tackle a number aspects of improving the use of HTTP in Second Life, such as making connections more robust and reliable, improving throughout to the viewer via HTTP, and so on.

The HTTP pipelining viewer, as the name suggests, leverages HTTP pipelining, a technique in which multiple HTTP requests are sent on a single TCP connection without waiting for the corresponding responses, which significantly improves the download of data (currently avatar baking information, texture data, and mesh data) to the viewer. The upshot of this is that the impact of a user’s physical location on scene loading is reduced, improving their overall experience.

As well as this, the HTTP viewer includes significant improvements to inventory folder and item fetches, which can markedly decrease the time taken for inventory to load, particularly if a user’s local inventory files have been flushed as a part of a cache clearing (or similar) exercise.

These inventory updates alone are liable to be appreciated by users as the viewer-side HTTP code gains wider adoption by TPVs. Tests have shown that a decently structured inventory (e.g. one that uses a folder hierarchy, rather than everything dumped into just a handful of top-level folders) of 100K can have a “clean” load time of 16-18 minutes reduced to around 3 minutes.

Earlier in October 2014, Monty blogged on his work, showing how both the CDN and the HTTP pipelining viewer, coupled with his earlier HTTP improvements have benefited texture and mesh fetching in SL. If you’ve not read that blog post, I recommend that you do.

Monty Linden's recent blog post shows how the HTTP work has improved texture and mesh fexture within SL

Monty Linden’s recent blog post shows how the HTTP work has improved texture and mesh texture fetching within SL

As well as working on HTTP, Monty has also been engaged on rebuilding and cleaning-up many of the third-party libraries used in the building of the viewer. This work should not only improve the viewer build process and such third-party libraries are consistently used in the build process, it may also help pave the way toward the Lab producing 64-bit versions of their viewer in the future.

Continue reading

Poodle vulnerability: Lab issue RC viewer with browser fix

On Wednesday October 15th I blogged about the Lab having issued a Grid Status update warning, those who use the viewer’s built-in browser may not be able to access certain websites. The notice was issued by the Lab as a result of the Padding Oracle On Downgraded Legacy Encryption (Poodle) vulnerability reported by Google.

As noted in my original article, the Poodle vulnerability exploits a flaw in the design of the SSL 3.0 protocol, which despite being 18 years old, is used as a fallback security protocol within most browsers. By using a series of connection failures between a browser and website, an attacker can trigger what is called a “downgrade dance” where the browser eventually falls back to using the SSL 3.0 protocol to maintain communications. When this happens, the attacker can use the exploit within SSL 3.0 to grab sensitive data.

How a Poodle attack works (image courtesy of Critical Watch)

How a Poodle attack works (image courtesy of Critical Watch)

There are a couple of caveats to the vulnerability; for the attack to work, the attacker must be on the same wireless network as you or in the path of your communications (as shown above), and your client must be running JavaScript. However, it caused Google to issue an advisory that SSL 3.0 support is disabled or that tools that support TLS_FALLBACK_SCSV (Transport Layer Security Signalling Cipher Suite Value) are used be websites, which prevent the “downgrade dance” attacks. This prompted some websites to remove / disable SSL 3.0 support, which in turn resulted in some websites becoming inaccessible when using the viewer’s internal browser or browser-related services.

At the time the Grid Status update was issued, the Lab indicated they are working to fix the problem within the viewer’s browser capability. This has now been done, and release candidate version of the viewer, referred to as the “Browser Fix” viewer, removes SSL 3.0 usage from the viewer’s internal browser, allowing it to connect to sites which have disabled SSL 3.0 support.

If you do use the official viewer and prefer accessing websites using the internal browser, you may want to download this RC. For those not using the official viewer and who have experienced issues accessing websites through the viewer’s internal web browser, try switching to using an external browser to open web links (set via Preferences), as per the advice on the original Grid Status update from the Lab.

Related Links