Tag: HTTP updates

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

Posted on by Inara Pey

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 “HTTP pipelining viewer reaches release status as CDN support is grid-wide” →

SL project updates week 42/2: Monty’s HTTP update and the HTTP pipelining viewer

Posted on by Inara Pey

On Wednesday October 15th, Monty Linden blogged about his HTTP work and the CDN, using the rather unusual title, The Sky Over Berlin (and Elsewhere). It’s a great piece of reading, although I can’t help thinking that Monty’s sign-off at this end of it would have perhaps suited the subject matter far better: nous sommes embarqués – “adventure is ours for the taking”!

The first part of the post recaps on Monty’s initial work in improving Second Life via the HTTP project. This started as far back as mid-2012, with the first pass focused on improving the   mechanism by which textures could be obtained for rendering via HTTP, which entered widespread use around  November 2012, with the release of the 3.4.3267135 viewer.

This work was followed by Monty labouring to improve mesh fetching as well, and to improve the overall reliability of HTTP, which I blogged about in March 2013.

At the start of 2014, Monty blogged on his work up to that point, and looked ahead to future activities. As a part of the post, he included a graph showing how the work carried out up to that point improved texture and mesh request handling.

The HTTP project has improved "under the hood" performance in SL in a number of areas, starting with texture fetching, anf through greater robustness of connections through the use of "keepalives"
In January 2014, Monty blogged about his HTTP work, and indicated how the work had raised the request rate ceiling within the viewer for texture and mesh data from A up to the blue line of C

In his latest post, Monty picks-up where his January post left off, demonstrating how more recent improvements are starting to improve things further – notably through the use of HTTP pipelining (the release candidate viewer for which has now been issued – see below), and the ongoing deployment of the Content Delivery Network service for texture and mesh data delivery.

In his latest blog post, Monty indicates how both HTTP pipelining and the use of the Highwinds CDN service should further help improve data transmissions and performance
In his latest blog post, Monty indicates how both HTTP pipelining (the “post 3.7.16” markers, denoting the introduction of the pipelining viewer) and the use of the Highwinds CDN service (denoted by the DRTSIM-258 markers) should further help improve data transmissions and performance

All told, Monty’s work has been a remarkable undertaking which benefits Second Life enormously, and helps to set the path towards possible further improvements in the future. As such, he really is one of the heroes of Second Life and the Lab.

HTTP Pipelining RC Viewer

The HTTP Pipelining viewer was issued as a release candidate viewer shortly after Monty’s post went to press.

Version 3.7.18.295372 enables the viewer to issue multiple asset fetches on a connection without waiting for responses to earlier requests. This should help inprove things like initial scene loading quite aside from any additional benefits gained through the CDN deployment work. In addition, the viewer includes improvements to inventory fetching, as Monty noted in his blog post:

The HTTP Project has focused on textures and meshes. But the inventory system, which maintains item ownership, is often described as… sluggish. So as an exercise in expanding the use of the new HTTP library, the pipelining viewer was modified to use it for inventory fetches. As with textures and meshes before, inventory is now fetching in the ‘C’ region of its specific performance graph. The difference can be surprising.

Having had the opportunity to test the pipelining viewer somewhat prior to its appearance as an RC, I can attest to this. While I keep my “active” inventory to a modest size (around 10,000 items unpacked, the rest boxed until needed), I found that an inventory download with a cleared inventory cache (nothing saved on my computer) averaged 9-10 seconds using the pipelining viewer, compared with an average of 2 minutes 50 seconds to 3 minutes with the current release viewer (3.7.17.294959). Whirly Fizzle, using a 105K inventory had even more impressive results: with a cleared cache, her inventory loaded in under 3 minutes on the pipelining viewer, compared to 16-18 minutes on the release viewer.

The release notes for the viewer contain additional information about the updates, again written by Monty, and these make worthwhile reading alongside of his blog post.

Related Links

SL project updates 41/2: server, HTTP, Group Chat

Posted on by Inara Pey

Pigeon Island, Neverending; Inara Pey, June 2014, on FlickrPigeon Island, Neverending (Flickr) – blog post

The following notes are taken from the Server Beta meeting held on Thursday October 9th, 2014. The transcript is available here, and the support agenda notes here.

Server Deployments Week 41 – Recap

  • Server deployment thread
  • The Main (SLS) channel and the Snack RC received the same server maintenance package as had been deployed to the three primary RCs in week 40,which fixes a bug related to viewing parcel details in gaming regions
  • There was no deployment to any of the primary RC channels (LeTigre, BlueSteel and Magnum).

CDN and the Snack RC

There are now some 270 regions on the Snack RC and which use the CDN for texture and mesh data fetching. The majority of these are mainland regions, although there is still no public list of all of them. Those who would like their region added to Snack are asked to contact the Lab at cdn-test@lindenlab.com.

If you’re using a TPV that can display region details in a dialogue box following a region crossing, you can use it to identify regions using the CDN, or you can check the About Land floater for the region you’re in. In both cases look for “Second Life RC Snack” in the region’s descriptive text. If you see it, the region is using the CDN.

Group Chat

Simon Linden’s work to both reduce the volume of additional group chat information messages (people joining leaving group chat sessions, updates to the group members list as people log-in or out of SL), and the frequency with which they are sent appears to have satisfied the Lab that they will produce some measure of improvement. There has already been a deployment of the updates to some of the back-end chat servers, and according to Maestro Linden, it is anticipated they should be on all of the chat servers some time in the next week. There may be more to add to this following the TPV Developer meeting.

HTTP Pipelining

Monty Linden: HTTP guru
Monty Linden: HTTP guru

The new HTTP pipelining viewer (referred to by the Lab’s QA team as the “weaponized” viewer, it is apparently so slick), is due to hit RC status. “Project Drano”, as Monty Linden, who has been spearheading the HTTP work over the last 2+ years, jokingly calls it, offers both improvements of its own and should further assist in data downloads via the CDN. Commenting on the viewer, Monty said:

The next viewer adds HTTP pipelining support to mesh and texture fetches. This allows multiple asset requests to be issued without waiting for intervening responses from the server, and it goes very far towards making client-to-server ping time irrelevant in throughput metrics. It’s a huge step on its own making our services perform as well as they can. Combined with CDN it’s even better. I won’t mention specific numbers but a region can show up in a very few seconds … Right now, we plan on skipping the project viewer stage. We’re going out the door [as an RC] once it passes QA (maestro heading that up).

Mesh fetching via the CDN should see an improvement because the viewer-side throttle of 100 meshes/second has been removed (this won’t affect non-CDN regions, as the throttle is also applied server-side on those).

As well as the core HTTP work, Monty has also done some work on inventory fetching within this viewer, particularly the code which is used to initially populate the inventory floater. This has been converted to use HTTP, and reduces the number of connections it uses. Again, no precise figures were given, but it should lead to improvements in inventory loading in situations where inventory data has been removed from cache (see the Firestorm wiki for information on removing inventory data files from cache). In one test with no inventory data, Monty saw a 100K inventory load around 10 times faster with the new viewer.

Whirly Fizzle (based in the UK) carried out inventory load tests for an 105K inventory between what was at the time the SL release viewer and a pre-release version of the HTTP pipelining viewer, both starting from a clear cache, and achieved some impressive results:

  • Second Life 3.7.16 (294015) Sep 10 2014 11:08:26 (Second Life Release)
    • Session 1: 16 mins 28 secs
    • Session 2: 17 mins 53 secs
    • Session 3: 17 mins 18 secs
    • Session 4: 17 mins 51 secs
  • Second Life 3.7.17 (294571) Sep 26 2014 12:32:36 (HTTP pipelining viewer)
    • Session 1: 2 mins 29 secs
    • Session 2: 2 mins 17 secs
    • Session 3: 2 mins 11 secs
    • Session 4: 2 mins 27 secs

I tend to have a very organised inventory, old / no longer used items are boxed, and anything not used in 6 months is similarly boxed (see: zdrop). Thus I only have an “active” inventory of around 10K (9,140 items at the moment), out of a total of around 70-100K. However, even with a “small” inventory like that, and working with a cleared cache, my results were impressive. The latest project version of the HTTP pipelining viewer (3.7.18.295146) averaged 9-10 seconds for inventory to download compared with an average of 2 minutes 50 seconds to 3 minutes for the current release viewer (3.7.17.294959).

Again, overall mileage on inventory downloads will vary, hence why Monty is hesitant to mention figures. However, it is thought that those with excessively “flat” inventories should see particular benefit (although they’d also be better off nesting their inventory into groups of folders).

Lab updates on viewer changes and CDN

Posted on by Inara Pey

secondlifeThe Lab has issued a blog post outlining some of the current improvements being made to Second Life.

Regular readers of my weekly SL project updates will already be familiar with the work referenced in the blog post, which focus on the changes being made to the viewer’s log-in screen, the removal of the viewer’s reliance on the GPU table when initially setting graphics preferences, the ongoing deployment of support for using a Content Delivery Network (CDN) for texture and mesh fetching, and an announcement of the upcoming HTTP pipelining viewer, which should offer some significant improvements in people’s SL experience, as well as including further adjustments to leverage the CDN.

Commenting on the new benchmark viewer, which will eliminate the need for the GPU table, the Lab’s blog post states:

This is a new way of figuring out the best default graphics settings. Maybe this has happened to you: you got an awesome new graphics card, fired up SL… only to discover your graphics settings are set to Low, and can’t be changed? No more! This Viewer does away with the old GPU table and instead uses a quick benchmark measurement to detect your GPU to assign appropriate default graphics settings on startup. The settings on shiny powerful hardware should really let that hardware shine. Get a Project Benchmark Viewer today and help us gather metrics!  Please file bugs in JIRA if you find them.

The new log-in viewer is currently the only release candidate viewer sitting in the viewer release channel. As such, it is liable to be promoted to the de facto release viewer in the near future – probably in week 41 (week commencing Monday October 6th), assuming the statistics for it haven’t shown up any issues.

As the Lab’s blog-post indicates, this viewer is being introduced as a result of several months of A/B testing with the current viewer log-in screen. This testing appears to show that new user retention is some 3-5% better when incoming users are presented with the updated viewer’s log-in / splash screens than when compared with those for the current version.

For those interested in finding out how the new viewer differs from the current version, I have an overview of the new version already posted.

The log-in / splash screen in the login RC viewer seen by users who have previously logged-in to SL
The log-in / splash screen in the login RC viewer seen by users who have previously logged-in to SL

A point to note with the log-in screen changes is that they do not impact the widgets, etc., used by TPVs. Therefore, these changes shouldn’t force those TPVs using their own log-in splash screens to replace them with the Lab’s updates.

The final two aspects of the Lab’s blog post are the deployment of the CDN, which is currently for texture and mesh fetching, and which I’ve also extensively documented through my week SL project updates. At the time of writing, the CDN is available in ten regions across the main grid: Denby, Hippo Hollow, Hippotropolis, Testsylvania, Brasil Rio, Brocade, Fluffy, Freedom City, Rocket City or Whippersnapper. However, more regions will be added as time goes on.

There is no requirement for any special viewer in order to get an idea of the faster downloading of textures and meshes users should witness on entering any of these regions (there may be some rare instances where things are a little slower if you happen to reside closer to one of the Lab’s data centres than to your local CDN node, but these instances are likely to be very rare). However, once the CDN service is available across the grid, it may see a final viewer-side update as a part of final fine-tuning, and well as potentially being extended to include the delivery of other viewer-consumable assets.

The HTTP work, which has been ongoing for the last couple of years and very much a focus of Monty Linden’s work, is something I’ve also reported upon through my weekly SL project updates. This should have some general improvements on performance, both with texture and mesh downloads through the CDN, and with other HTTP-specific SL services. This viewer code is allegedly so fast, the Lab refer to it internally as the “weaponized viewer”.

The benefit of the CDN and the HTTP viewer code – which TPVs are being encouraged to adopt as quickly as their merge / test / release cycles allow – is summed-up in the closing comments on the Lab’s post:

Separately, each of these will improve texture and mesh loading performance, but put together, you should really see some exciting improvements in how long it takes to load new areas and objects – making touring the many fabulous places in Second Life you have not yet visited even better!

Those who have been independently testing both the CDN and the pipelining viewer (in a pre-project viewer release state) have been reporting that results with either / both are impressive. Check Shug Maitland’s comment on this blog, for example, after she tried the CDN regions with a current viewer.

SL project updates 39/3: TPV Developer meeting

Posted on by Inara Pey

The following notes are drawn from the TPV Developer meeting held on Friday September 26th, and shown in the video above. Time stamps, where relevant, have been included for ease of reference to the video. Note that items are listed according to subject matter, rather than chronologically, so time stamps may appear out-of-sequence in places. My thanks as always to North for the recording.

Benchmark Viewer & GPU Table

[01:00] As noted in part 2 of this report, a new GPU Benchmark project viewer is available (version 3.7.17.294710), designed to put an end to the need for a dedicated GPU graphic table as the mean by which the viewer determines a computer’s initial graphic settings.

Instead, if there is no settings file for the viewer (such as after a clean install),  the viewer will measure how quickly data can be copied back and forth between GPU memory and your computer’s main memory. This, combined with a couple of other benchmarks, determines the initial graphics settings in the viewer. It may not always pick the most preferred settings (it might still set things a little high or a little low), but testing has shown it to be reasonably accurate,  and it does prevent the viewer opting for the lowest settings simply because a card isn’t listed on the GPU table. As is currently the case, any subsequent adjustments you make to the graphics settings should be saved within the viewer and take precedence.

Feedback on the viewer is encouraged (a wipe of any SL viewer setting files on your computer will be required), particularly if you encounter issues such as finding the viewer “sticks” with the settings it has determined, rather than allowing you to adjust them. When filing JIRA, the Lab requests that log files are attached.

HTTP and CDN

[09:39] The anticipated HTTP pipelining viewer should be appearing as a release candidate viewer in the early part of week 40 (week commencing Monday 29th September). This is the viewer that the QA team in LL have been referring to as QA,  “weaponized viewer”, it is so fast as a result of leveraging the HTTP streaming.

This viewer works with the CDN, with Oz Linden indicating a personal experience of logging-in to a CDN-enabled region with an empty cache and having the textures and meshes for the region loaded by the time the log-in process had finished, so it will be interesting to see how the viewer performs under more widespread use.

TPVs are being encouraged to adopt the HTTP updates as soon as their integration / release cycles allow. In the meantime, those wishing to test this viewer, when it appears, with the CDN can do so via one of the following regions: Denby, Hippo Hollow, Hippotropolis,Testsylvania, Brasil Rio, Brocade, Fluffy, Freedom City, Rocket City or Whippersnapper. It is anticipated  further regions will be added to the CDN channel (Snack) in the next week or so, prior to CDN support rolling to one of the server RC channels.

 Voice Updates

[17:16] Another batch of viewer updates due out, and which TPVs are being urged to adopt as soon as they can, are for voice. These mostly relate to managing voice sessions rather than voice improvements, and are aimed at helping Vivox with problems at their end, and should make troubleshooting genuine issues within voice a lot easier. However, this update should plug the hole where stalkers can track where someone using voice has teleported to just by monitoring their voice channels.

Z-offset Height Adjustment

Jessica Lyon demonstrated part of the avatar height offset issue at the last TPV Developer meeting: when seated using her preferred sitting pose, her avatar floats above a chair, and she has no means of adjusting the height so that she appears to be sitting in the chair
The z-offset hegiht adjustment option should help in situations where the current Hover option is unusable – such as trying to adjust you avatar’s height when using a preferred AO sitting pose

[18:42] Vir Linden is now working on the z-offset height proposal. The work is in the early stages, so no date on when it will appear in a viewer.

The current plan is for a new option to be added to the right-click avatar context menu which will access an adjustment slider. However, at present, any adjustments made using it will not be persistent across log-ins, although it will work alongside the existing Edit Appearance > Hover option (allowing for the No Mod shape limitation of the latter).

It has been suggested the offset setting could be made persistent by tying it to a debug setting. This is something the Lab has said they’ll think about; should they opt not to go that route, there will hopefully be no reason why TPVs should not go that route if persistence was deemed vital to their users’ experience.

[48:13] Adjustments made using the slider will occur locally until such time as the mouse button is released; only then is an update message sent to the server & relayed to other viewers, to prevent multiple messages spamming a server as people make adjustments. It is hoped that this approach will also allow z-offset adjustments to interact with other active animations relatively smoothly (e.g. adjusting your height to prevent appearances of dancing on air when using couples dance poseballs).

Continue reading “SL project updates 39/3: TPV Developer meeting” →

SL projects update 33/3: TPV Dev meeting: HTTP, avatar height offset

Posted on by Inara Pey

The following notes are taken from the TPV developer meeting of Friday August 15th. A video of the meeting, provided by Chakat Northspring is included below. This report represents an overview of items discussed at the meeting which are liable to have the broadest interest among users. Timestamps are given against items and paragraphs for ease of referencing what was said within the video for those who wish to listen to the entire conversation on a given subject.

Note that subjects are not necessarily presented chronologically when compared to the video, but has been grouped under common headings.

My thanks, as always, to North for her recording of the meeting and linking to this blog post.

SL Viewers

[00:30] There have been few visible changes with the RC and project viewers this week. The library refresh viewer and the experimental log-in viewer remain unchanged, and while the Experience Keys project viewer has been updated, this has yet to appear in the Alternate viewers wiki page.

Oculus DK2 and Project Viewer Updates

Oculus Rift: the Lab now has the DK2, so work will be resuming on the project viewer
Oculus Rift: the Lab now has the DK2, so work will be resuming on the project viewer

[00:50] The lab has received around half-a-dozen of the Oculus Rift DK2 headsets, and so it is anticipated that further work will be progressing with the project viewer, and updates will be emerging over time. As noted in week 32, there are some substantial differences between the DK1 headset and the DK2, which currently make the project viewer largely incompatible with the newer headset.

Texture Statistics Logging

[19:15] With the roll-out of the 3.7.7 the Lab unfortunately broke the texutre stats reporting debug option LogTextureDownloadsToSimulator. As this is off by default (set to False) it has not been noticed by most users. However, the recommendation is that users do not set this option to True, as it will cause the viewer to immediately crash on start-up, at the next attempt to run it. This issue is common to all viewers using all code releases subsequent to 3.7.7 as well.

Viewer Build Process

[40:24] The Lab is shortly going to commence the process of upgrading the tool chain they use in the viewer build process (e.g. switch to Visual Studio 2013 for Windows and Xcode 5 for Mac) and switching over to the new version of autobuild. This work may also eventually help pave the ay for 64-bit builds of the official viewer. However, this is not currently the focus of the changes, as no decision has made as yet within the Lab on producing 64-bit builds of the viewer; the current aim of these changes is to improve the overall viewer build process.

[47:23] There are two points of note here. The first is that the new autobuild process includes changes which self-compilers must adhere to if they are using it, and details are available on a wiki page. The second is that it is probable that Windows viewers built using Visual Studio 2013 will not run on Windows XP. The Lab has already dropped Windows XP support, which is as much as it will currently say in terms of future viewers built using the new tool chain running on XP.

Group Chat

[02:00] The work on group chat has temporarily halted due to those working on it either being on vacation or working on other projects. Given this, and with a degree of ironic timing, there have been increasing reports of group chat issues over the last several days, including one chat server apparently becoming completely non-responsive.

It’s not clear to the Lab as to what may be causing the problems, but they have been noted. In the meantime, informal advice is that if your group chat is consistently failing, to contact support, provide them with the information on your group (name, etc.), and the issues you’re having, and request the chat server is restarted.

Continue reading “SL projects update 33/3: TPV Dev meeting: HTTP, avatar height offset” →