Monty Linden

Hahaha. It's long been desired. Short answer: it's work to implement. Viewer evolved without a reset-to-initialized transition and putting one in now would take some archaeology. But there's no technical barrier.

If that is still happening, file a support ticket and include that Reference #.

Under no circumstances should you set InjectLagEffect to False.

Mesh and texture loading are directed by independent, dynamically-prioritized queues that feed into multi-thread pipelines. There is coupling. Viewer needs enough of the mesh to generate texture references to add to the other queue. So there's a kind of 'meta-pipeline' that encompasses the entire process. When doing the CDN and pipelining work, I wanted to get both queues into the shift-ctrl-3 display but didn't have time and textures are probably more interesting. There are mesh metrics there in compacted form. No CDN operator will ever provide details of how they work. The business is similar to selling amphetamines. "You want to go faster? We have the best stuff!" Competition is fierce and business processes are secret. I will say this: they seem to have a remarkable ability to adjust to conditions. When trialing various CDN approaches, I got the impression operators were able to detect we were benchmarking and would optimize the pathway. To the point where, with a 2014-vintage viewer, it was almost faster to use the CDN than local on-disk cache for asset storage. Again, just an impression.

This is an optimization problem with many dimensions. On every scene change, a viewer needs to react. This includes initial login, teleport, region crossing, arrival of a crowd of avatars, taking a step backwards, or turning a bit to the right. Getting back to scene complete requires, among other things, downloading the missing information in the scene-to-be. Time to complete that has many dimensions but tends to be dominated by byte count, not request count. But software settings, computer, networking, geographic location, etc. all factor in. You can change the amortization and move things to the front (drop a curtain, load the next level), do it entirely reactively (as little as possible at every moment), or a mix of visible and at-the-ready assets for some continuity at all times as is done in SL. And no individual's experience will be a universal truth - that's where metrics come in.

This is trivial to implement and test for yourself. In the above-mentioned code, disable the insertion of a byte range in the mesh request and the entire mesh asset will be downloaded with one request. Repeat in the texture code, if desired. Report back what you find!

It's true. The process is described at the beginning of llmeshrepository.cpp.

Give Aditi a try now if you had problems before. Development is ongoing so if you find you have access, take advantage while you can and expect interruptions.

Fwiw, I can't log in either. This will probably have to wait for the work week. Sorry but Aditi is earning its keep these days supporting active development.

The login server doesn't but the full login process does. There's an inventory component that's aware of ID prefixes.

Not today's problem but a more honest site: https://stop.lying.cloud/

One addition to the blog posting.... In the Statistics Bar under the Server section are some timings of work performed during a frame. You may see times reduced in a number of areas (e.g. physics, net) and not just scripting (which is the one everyone pays attention to). Note that the qualifier is *may see* and not *should see*. Individual results will vary.

We probably should look at our throttling levels whenever the environment changes dramatically, as it has now. Not certain when or if reconsideration will happen but some are thinking about it. Different thresholds for different targets is less likely to happen. Throttles are an attempt at fairness as well as civility and special classes are not usually compatible with fairness. Practically, answering the question "is this targeted for us-west-2?" is more difficult than one would like. And as Jeff would tell anyone, hosting on AWS is its own reward.

That is one that hasn't happened yet. The Mono system itself is mostly unchanged from previous releases. So recompilation isn't expected to deliver a benefit at this time.

An SVC Jira? Now that's some ancient history. No, nothing new in HTTP throttle land. Just the potential for hitting local or remote throttles more easily with more script code being executed.

@Winged Heron I wouldn't expect that to be related. But it is worth a support ticket.

Not an accident and not a change in metrics. The latter are computed the same as they were before. I can't tell you everything that happened but the blog post gives you an idea of the breadth and depth of it.

Everyone is on the 567269 release with either an upgrade or restart as of today. Enjoy!

27 linked Jiras.

That is the plan. Released at last!

Someday... someday... we'll get it right again. Maybe when our viewer gets pie menus back.

Oskar was a bit stressed during that deploy cycle....

Restarted some chat services in server land. When this happens, a quick support ticket will get this done. They know this routine well...

Give it a try now...

Breedable Lindens. New product for 22/4/1. Don't tell anyone.