Monty Linden

Nope. That's just the first time I've ever seen ISP license management as a reason for reduced bandwidth. That's beyond dog-ate-my-homework.

Another possibility is that your cable ISP isn't installing all their licenses correctly:

For some perspective, I checked logs and you personally had 13 network blocking events on that region in a 24 hour period. The region as a whole had 100 and the simhost on which it was running had 2000 (one every 43 seconds on average). Yours correlated well with region entry and rezzing/derezzing operations. None of this is necessarily a problem on either end. But you might see some of this in action by pulling up the Windows monitoring tools and watching the network adapters. The numbers may be adequate to show the correlation between these events and packet activity. (Shift-Ctrl-1 needs better visualizations... )

Usually, that's not useful. There may be 50 hops between your computer and SL servers and very little overlap with a path to google. You can catch a problem with your ISP or modem/router or a firewall/AV being really awful. So it may eliminate those possibilities but doesn't help beyond that.

This is in the UDP system so it's based on slow acknowledgements from the viewer. The problem can lie anywhere in the path. From the socket held by the simulator to the OS scheduling the viewer and everything in between. A bit more data from this one event first: the simulator was very quiet, one avatar (yours), a few on neighboring regions. Scripts using email for communication (grrr). But metrics and logging all very quiet, nothing exceptional happening in the region or on its simhost. In this scenario, the likely cause is elsewhere. I.e. "the Internet did it." I can also look at the viewer log from your session to confirm what happened from its point-of-view. You can email it to monty @ you-know-where or we can arrange other means. We can't make the internet (or cable ISPs or home operating system) behave but I'm interested in a few more events to see if any pattern emerges. If so, we can turn this into a visible Jira. Also inviting events from others here.

From our side I see: 17:43:41 - Attachment removed to be returned to inventory 17:44:00 - Congestion declared while sending updates to your viewer 17:44:05 - Appearance requested and congestion declared cleared So it appears like a stall in the network somewhere. I'm curious just how awful the updates were but I don't have that here. But there is a why to this event.

I'm curious about these events. I'll happily listen to details on particularly awful instances of this problem. Jira or here: where, who, when (to the second, timezone), and what happened. (Have looked at some bad rezzing/attachment events - this is a different problem, I think.)

Bwahaha, wrong tree, dog! The roadmap still stands but things may change. Watch for updates, monitor the user groups...

Oh, dear god, do we. I walked through that recently for the first time ever and despaired. A non-linear function of three terms, one of which uses the result of a loose, converging (maybe) iteration. I suspect that wiki page needs some updates but, yes, that is relevant.

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.