Texture Thrashing is something I’ve written about several times now. This is a problem that is coming up in the SL Forum and various support groups. See Second Life Texture Thrashing for an explanation. As yet this is something that is NOT on the Linden radar. I’ve listed some fixes for it in the linked article. Mac users are more prone to it as there is a viewer gotcha in a Debug Setting that prevents use of all the VRAM they have. (RenderTextureMemoryMultiple)

If you are seeing this problem and can reproduce it, file a JIRA. When you do refer to BUG-2514 – Dam Textures won’t stay fully rezzed or don’t fully load at all – FUZZY DETAIL. 2514 was filed by Loki Eliot. Most of you probably cannot see that report or any BUG reports. These JIRA items are related: MATBUG-372 (I think most can see this one), BUG-3701, and BUG-2488.

There was a house around that would reliably reproduce the problem. It has since been de-rezzed. But, the vendor has a demo of it up that you can see. Visit: SAU. Look for the house in the image.

House Triggering Texture Thrashing in some video cards.

This is a gorgeous house and well furnished. But, the LoD and texture thrashing drive me nuts. I’m not getting the REAL texture thrashing where textures are getting swapped out when the avatar is stationary. But, as I turn and walk I get things re-rendering.

Monty Linden visited and said, “I looked at region ‘sau’ quickly and that’s definitely a detailed build. What I saw was GL texture thrashing as the mouse moved around. My graphics card is old (512MB) and fills to limit and as focus moves from object to object, something gets evicted. What the viewer is choosing may not be the best and it does seem to hit the network so caching may have issues. Build was dense enough to get 503’d on both meshes and textures when it starts loading.”

HTTP Pipelining is on the RC channels. All three got the same package. Refer back to: Second Life News 2013-36. Monty Linden showed up at the Beta Server group and explained a bit more about what this package does and has in it.

There is a new api/cap named GetMesh2, which is like GetMesh, but pipelined. GetMesh is being throttled at the servers because of people setting the Debug Value of MeshMaxCocurrentRequests to ridiculous values. Its counterproductive to do that, but too many go an belief without out testing facts. So, the Lindens throttled the connections at the server. The result is lots of 503 connection errors are piling up in those peoples viewer logs.

If you visit the house in SAU, you can check your logs and probably find lots of 503 errors, more if you have changed MeshMaxCocurrentRequests.

GetMesh2 will use an HTTP pipeline, meaning just one connection and lots of downloads through it. Those with high bandwidth, high latency connections will see a significant improvement when the viewer supporting GetMesh2 arrives. High latency means long ping times. GetMesh2 should fix the problems being caused by those changing to MeshMaxCocurrentRequests to high values.

Monty says, GetMesh2  will have 8 default connections per viewer, plus keep-alive’s and  plus better retry logic. There will be a Debug Setting: Mesh2MaxConcurrentRequests. (Notice the 2.) While it was not said, I do expect the viewer to clamp this value to some reasonable maximum, possibly 32 the current default for MeshMaxConcurrentRequests, no 2.

Monty also says the viewer’s Texture Console (Ctrl-Alt-3) is going to change. Mesh download status is going to be added so one can see what/how mesh download is doing. Right now you can use ‘netstat’ command and filter for port 12046 (I think that port is for the coming GetMesh2  cap – I’m not seeing it in use right now, only 12043, but I didn’t look very hard).

When a server cannot handle an HTTP request it is required to send at least a response header. In the case of GetMesh a 503 response is sent. The current problem with that is the viewer is programmed to IMMEDIATELY retry. The result is a cascade of failures and consumption of bandwidth as the viewer retries and the server issues 503 errors.

In the new GetMesh2  the 503 header will include information on WHEN to retry. The new viewer will then wait that time before attempting another download via GetMesh2. So, a very busy server might say talk to me in 60 seconds (well that is pretty long but this is my example) and a slightly overloaded server might say come back in 5 seconds. Real times will likely be measured in milliseconds.

Monty says this new retry logic is going to apply to any request that is subject to cap throttling.

On the viewer side GetMesh has use lots of threads (independent processes) with mutex locking to avoid flooding cap services. (mutex = mutually exclusive use of resources.) The viewer spends time locking things, other tasks wait for the locks to lift so they can lock the resource and use it, then they have to release it so other sources can use it. Lots of CPU cycles are used up locking and unlocking. This is not the best way to use multi-threading. GetMesh2  using a pipeline can provide simpler traffic control and avoid mutex locking. So, while fewer processes are used, there is less waiting. There should be fewer stalls in mesh and texture downloads.

The new viewer code is working pretty well according to Monty Linden. This means we may soon see it in an RC viewer.

Monty says another aspect of the new viewer is, “One other small change is to ensure that final requests from services from capabilities are transmitted with ‘chunked’ encoding. The value of this is that it provides redundant length information for response data which allows libcurl and the viewer code to validate that it really received a full response.

If someone has a bad ISP or a bad network driver, they may see error messages indicating short data. (partial file transfer, or range header invalid)

We’d like to hear about these but they likely indicate a weakness in the networking path.”

That is about how HTTP communications work. Basically the server is saying I’m done and I sent you a message 80,477 bytes long. If the viewer didn’t get 80,477 bytes, there is a problem and the viewer needs to retry. That is a bit simplified, but it is the idea.

llXorBase64 and llXorBase64StringsCorrect are changing. See the previous news release for more information.

llSetTexture() has had a problem where the event CHANGED_TEXTURE was not firing. This is supposed to be fixed in the current(?) RC. This apparently affects a number of vending machines used in SL.

Maestro Linden tells us, “[A] decision [made] was to nerf the autoreturn bypass technology completely — since it violates the spirit of the parcel settings.

If ObjectA rezzes ObjectB, ObjectB will inherit the temp-on-rez and parcel time of ObjectA. So both ObjectA and ObjectB would be returned to the owner simultaneously, if autoreturn was in effect.”

The previous way things were griefers could avoid parcel return triggers by having a griefer object rez a copy of its self, effectively restarting the timer, and the copy of the copy rezzing a copy of its self and so on. Thus avoiding a temp-object time out or a parcel return time out. That has changed. Now the copies and parent will all time out at the same time.