Ardy Lay

Where's the documentation? 😉 Did it go away? Oh joy, clicking Knowledge Base and entering "away" in the search field yields THIS FORUM THREAD and a few others. Hmm, okay, can limit search to Knowledge Base. That gives many unrelated uses of the word in articles then I find this: https://community.secondlife.com/knowledgebase/english/setting-your-preferences-r58/ which merely mentions the existence of "away timeout". I am gonna go with: "This originated because someone had to ask and they got a reply from some joker that wanted to start something."

https://spectrum.ieee.org/the-first-transatlantic-telegraph-cable-was-a-bold-beautiful-failure

Ah, the dreaded "oversubscribed" issue, I see. UDP traffic, if SL is still using it, is often what gets early discard-eligible marking when entering a switching platform and subsequently what gets discarded when an egress-interface is congested. I like how carriers like to tell people their data travels at "the speed of light". What some people do not know, and it's not their fault, is that, because glass is denser than vacuum and air, light is slower when traveling through it! Light in optical fiber is even slower than signals in coaxial cable! I had some fun setting up a demonstration of this for out CEO 21 years ago. I used two reels of cable that were the same length, 1,000 meters. I set up my time-domain reflectometry test set to run tests on both. He boggled at the result then started looking at cable specifications. "Oh, so that's what 'velocity factor' means!", he shouted a few minutes later. He had taken notes, did the math, then showed it to me. Bandwidth is not speed (velocity) alone. @Monty LindenI wonder if some sort of tunnel could be used by subscribers to encapsulate their UDP traffic within a long-life TCP flow, to get away from the "UDP is expandable" attitude coded into much of the equipment that makes up The Internet?

@Monty Linden What's wrong with "sea cables", and what's the alternative(s)?

Klytyna gives free forum points! Probably not the intent, but is the overall result. Some people get upset about all the laughing. Don't. It's like they have cans and cans of laugh-track they are trying to purge. A quick glance at their post history, which ended December 27, 2018, leads me to suspect "cat's got their tongue". Will the "cat" ever give it back? Unlikely.

Thanks!

It worked similarly to @Adeon Writer's Portal simulation.

It was in region Perry, but has been gone for a long time now.

You don't want that anyway:

Nah, not a problem. Read the legislation, not the click-bait "press".

Nortel Networks tried to sell to me a product specifically for modifying web pages in-transit to replace existing ads, insert additional ads, and do even more unthinkable hooliganism. The CEO was interested, but I, the CTO, told him to not even think about it or the company WOULD fail. We were busy building a Fiber to the Home network in 2001. We really could not afford to alienate subscribers in an environment where people thought 1Mbps was more than they could ever want and we were offering that as the absolute bottom tier. Looks like I am still here, in the same building, still at the core of the network like a good little packet pusher. I have and will continue to defend the subscriber's ability to use which ever DNS resolver(s) they want, while providing a pair of on-net resolvers that are 8ms near or better, to each served region. So, as you can imagine, the CDN hijacking you described disturbs me. What's to stop any of the publicly accessible DNS resolver operators out there from doing the same, or worse? What would be their motivation? No, scratch that. Somebody will reply with their political rantings. Could the Second Life Viewer, and derivative works, have some sort of CDN validation mechanism? I know that anycast-IP routing can be used to hijack CDN queries without modifying DNS queries or results. Could a method be employed to thwart such efforts? What would be the desired action in the viewer when such hooliganism is detected?

... or WiFi repeaters ... repeaters ... repeaters. I have seen some silly WiFi "range extender" behavior. I have also seen some long multi-path weirdness. Both types of echos SHOULD be discarded by the WiFi adapters, but, some some are just crap.

Sure can. The target machine is running Windows 10 and using Microsoft's security software. I use the same with no ill effects and have added the same exceptions to seek improvement but noticed none at all on my Intel i9-9900k. We are, however, running on vastly different hardware and the other party was also running ESO, which I think is Elder Scrolls Online. This experience reinforces my opinion on why some people have very bad experiences with Windows 10 on their computers. I can replicate these painful symptoms on some older computers I have otherwise retired. (Intel Q6600 and Intel W3550) They 'run' Windows 10 but chug for significant durations after updates to malware signatures and detection heuristics. I suspect that, if I were to try running SL on them I would also get the choked behavior during HTTP texture downloads if I do not exempt them from analysis. I know I do see them hit very high CPU utilization when downloading files to them and that load is from either a Windows Defender process or a Malicious Software Removal Tool process.

I saw a simulation using a shiny prim floor with a projector shining down on it. The projection was a photograph of the room and contents. It was kinda strange but might suffice.

Given @Monty Linden's advice, some more analysis was performed. The problem was found to be in a local system, not the CDN or elsewhere. When the HTTP transfers from the CDN were flowing, the software analyzing the contents for threats was unfamiliar with the JPEG-2000 format and giving it the full treatment, using up a lot of CPU time, which, with concurrent transfers, exhausted the host's resources, slowing the transfers drastically. The operator of the system has applied an exception rule to prevent this unnecessary analysis and now the end user sees 40Mbps of flows from CDN for a while, tapering off as the viewer's request density tapers off. Sorry to cause such a kerfuffle with this bit of troubleshooting and thanks for the answer to my original question, Monty!

When I click the thread title I get the first post in the thread. When I click the bullet to the left of the thread title, I get oldest un-read post in the thread. If the bullet to the left of the title is grey, there are no un-read posts in the thread. If the bullet to the left of the title is round, I have not posted to the thread. If the bullet to the left of the title is a star, I have posted to the thread.

This has me wondering, is the logic to fall back to UDP per asset, or does it apply to all assets, once triggered?

Because it would affect the teleport-around bots Linden Lab seems to love so much?

Nope. And hey, look at this: No resident is forcing anybody to teleport. If you want to go without a fundamantal function of Second Life, do it to yourself without promoting imposing that restriction on others.

Nope. I am not allowed to play with it. They keep referring back to what happened to Hubbel!

If that happens I'll dump my land, log out and uninstall the viewer.

Catznip R12.3 on Win 10 20H2 I really doubt it's a viewer thing. Oh, and they had exactly the same problem on BT before they switched to Virgin.

This little bit of accidental hooliganism has prompted me to set a title.

I was using Second Life Release 6.4.21.561414 (64bit). "... found a viewer ..." was not from me. I was using a recent viewer from Linden Lab. Did the same on a previous release too. Second Life Viewer certainly can still use UDP. I was researching this because a user in Europe stated they were using UDP because "UDP is faster than HTTP here", and, indeed, in their instance it is! Evil, I know. CDN is failing them miserably. They are on an access provider called Virgin Media, in UK. They said they had really good connectivity to the CDN node the SL viewer was using but the CDN node was delivering at a paltry rate so they switched off HTTP Textures in the viewer and found UDP to be functional and slow, but much better than HTTP for them. They and I were both receiving textures via UDP at about 2 Megabits per second. They were receiving textures via HTTP at about 128 Kilobits per second while I was receiving textures via HTTP at about 54 Megabits per second. I am in USA. I suspect my connection details are irrelevant. So we have two surprises. HTTP texture delivery rate via a CDN node used by some residents isn't always what we expect, and UDP texture delivery seems to be possible again/still. The first is obviously alarming but is the second even an issue? Maybe it causes no harm. In this instance, UDP texture delivery makes a person's use of Second Life possible. @Rider Linden @Monty Linden I am asking the UK resident what viewer they use.

I have a neighbor that chops down all the Simarouba amara on his property every 5 to 10 years. People see this and freak out, asking why he removed all the flowering walnut trees, apparently unaware they are actually just HUGE WEEDS that look pretty good until they get so large the nut load on them starts breaking them down. I once suggested a more frequent and less extreme pruning but he stated that since they don't bring in any money it's not worth the effort.