Monty Linden

Kama Center/Charlesville look fine on win11 with 7.1.2 SL viewer.

Not seeing (or expecting) any such change. Any more details?

We're still rolling back some RCs. Sorry for the inconvenience and I hope we'll have some more info for everyone shortly.

Is this always on login for you?

This is one fingerprint of a spurious inventory failure scenario that we're aware of. A relog will likely complete without error in this case (was that your experience?). If failure does persist, that indicates it is time to escalate to support. But let us know about the transient failures as well. Pressure and feedback drive development.

An open API for the anonymous exchange of PGP-signed biometric data. Hmmm...

Yeah, the vehicle unpacking and repacking code is 'interesting.'

Duplicated (or worse?) RegionHandshake messages came up in one of my deep digs earlier in this thread. Found one source for them. Code appears to be very deliberate in the addition but no one knows the explanation now. And it wasn't documented. Smells like simple carelessness or whitewashing of something not understood (two messages are better than no messages so...). As you've shown, viewer and simulator restoring synchronization after an RC/TP takes time (it's a protocol exchange). So there's always a race scenario where queued or stale or retransmitted data becomes invalid or irrelevant after the full exchange. And the problem is worse when it's a 3-body problem (one viewer, two simulators). All participants must be prepared to detect and reject these cases. That situation exists between simulators as well. The transition milestones represented by the messages between viewer and simulators aren't the only transitions behind the firewall. For example, an avatar or vehicle making a crossing isn't fully functional until sometime after the destination simulator declares the move complete. This internal transition can come before or long after the viewer has acknowledged the movement. In the meantime, such an object is free to initiate *new* transitions such as an RC/TP or even just a logout (which requires updates to inventory). This is part of the reason why 4-body transitions (one viewer, three regions) are so fraught. Viewers do experience these problems in other ways and DMs are one such area. A version of avatar presence is maintained as global state outside of the simulators. One use of this data is to direct DMs to the correct simulator for viewer uptake. But that service is subject to all the delay, ordering, retry, and other protocol issues of any other distributed system. It's notion of presence can be stale or very wrong in certain cases. So each message in a DM stream takes that information as a hint and proceeds to hunt down the actual avatar location according to simulators. But that is also a protocol exchange and doesn't necessarily produce a correct result when transitions are in-flight. In this case, the IM system gives up and tosses the message into persistent storage for later recovery. And that's one way messaging does really, really surprising things.

@Will2024 if you created your account in December or later, this may be a bug we're currently working on. Run through the checks as @Rowan Amore outlines. If they're good, it may be on us. We don't have our Github Issues access in place yet but look for issue 593.

I can't speak for Catznip but I suspect this was related to deprecation of certain UDP inventory operations. Those UDP messages are unlikely to come back and the way forward, good or bad, is the HTTP-based system.

not even a mouse?

Understood. Happy to have any insight into a possible pattern. So thanks for the report, there is something to dig into there.

Are the timeouts consistently to the login endpoint host (login.agni.lindenlab.com)? Worst-case metrics look good there so it's either stuck in front of the service or some *really* unhealthy instances.

We're coming up on the holiday break and Lindens are going to start disappearing (myself included). If you are comfortable posting viewer logs to Jira, file a BUG jira, attach the logs from a bad session, then mention the Jira number here so it can be found quickly.

The SecondLife.log or SecondLife.old file associated with a bad session. It can be attached when filing a support ticket.

Correct. We're happy to get any kind of traceroute between your home systems and a simhost in support tickets. But here are some hints on better trace routing: Better in the sense that it will terminate. It doesn't, for example, detect problems unique to UDP.

I don't see it either, either in my own travels or in the metrics. But I can believe something's wrong. We just need data from the field.

Support should bug you for more information soon enough. They are standing by hungry for your calls...

Need to see those log files to know what's going on. I just did 10 TPs in 60s so this smells regional.

Nothing really going wrong on the grid. Get some support tickets in and try login and TP to other regions.

May be expected. SL viewer is shipping five or so expired certs right now. 2025 is when the magic cert expires and that will be an interesting day.

Looking at something on Aditi's bake service. Things may or may not get better...

That's nice but it's not OpenBSD nice.

FWIW: we just had an escalated case resolve with the ISP being responsible. They were handing out router/modems with shoddy firmware. Trust but verify.

Let me fix that Linux install for you: https://www.microsoft.com/en-us/d/windows-11-pro/dg7gmgf0d8h4 Agreed. I lost that battle for now.