Monty Linden
-
Posts
542 -
Joined
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Monty Linden
-
-
9 minutes ago, animats said:
Asset server bandwidth is consistently about 200Mb/s.
And Akamai's edge throughput runs around 250Tb/s for comparison. Landing in a new region is like a very, very badly constructed web page full of javascript and duplicate images.
-
18 minutes ago, Ardy Lay said:
Recognizable constellations and deep sky objects were a comfort to me. Silly me also liked Linden Trees swaying madly in the wind and the sound of the wind roaring past.
You are not alone.
-
2
-
-
49 minutes ago, Wulfie Reanimator said:
My favorite part about reading the viewer's source code is running into comments from the early 2000s warning about the following code being a hack/workaround... and it's still there.
We use a lot of load-bearing posters in our work.
-
4
-
-
8 hours ago, DaJessica said:
That Reference # code changes every time the page is refreshed and this "bug" has been going for 4 hours now and it hasn't cleared.
Take one or more of those Reference #'s (fresh, if possible) and include them in a support ticket.
1 hour ago, Aimena said:I did not get answers from the support, what I could understand is that my IP cannot connect to the SL server and they recommended that I change my IP.
Using a VPN is one way. Another that may work is having your cable modem/fiber box/router renegotiate a new IP address from your ISP. Both of these can fail for various reasons.
-
Take that 'Reference #' and include it in a support ticket. They will know what to do. And this should clear in time (hours).
-
3 hours ago, Aimena said:
I really don't know what to do anymore, the only thing I haven't tried yet is to call my internet provider.
- Open https://login.agni.lindenlab.com/cgi-bin/login.cgi in a browser on the computer with the problem.
- That will fail with an error. Look for a 'Reference ID' or 'Reference #' somewhere on the error page.
- Take that ID to support and that should help. (This kind of problem will clear eventually.)
- If you do not see such an ID, the problem is elsewhere and the answer starts with the SecondLife.log file.
-
2
-
Unofficial word is that 579248 (on RCs) will go the the main channel Tuesday. Lox tanking underway...
-
2
-
-
If you get something that works well, please share it here. There are good routers and bad routers and mediocre routers. Good to know which are which.
-
3
-
-
Memory used by SL and free memory available on the system. Can also look at network interfaces to see if they're saturated but that's doubtful. SL will be using a good amount of CPU, that's not an issue... not using CPU would be.
-
Yes to all of the above.
One more thing: it was a long-lived connection and the viewer may have had time to bloat up badly. If this happens again, bring up Task Manager (or equiv.) and see if there is a problem on the computer.
-
1
-
-
44 minutes ago, Hojo Warf said:
[LAN access from remote] from 35.167.249.75:13043 to 192.168.1.4:59069 Tuesday, April 04,2023 13:42:42
Bad typographic conventions always suggest some company tried to save money on software development. I don't know if that logging indicates traffic that was blocked or traffic that was allowed through NAT, but it leans towards 'allowed'. It doesn't even bother telling us UDP vs TCP though we know it's UDP. Inbound traffic around 18:42:30 and outbound traffic would be hints that the router was maybe trying to do the right thing, but...
What I can say is that from 18:41:48z to 18:42:45z your computer stopped communicating with the region. That is bad but it isn't long enough for the region to declare a timeout. When your computer did respond, it initiated a coordinated logoff. You can probably find some complaints in the SecondLife.log file around 18:41:05 to 18:42:51.
Other indications are that the simulator was running well so we're looking at local computer<->router<->isp issues and since the router is the thing that changed, that's still the primary suspect. Time to hit the Netgear forums, upgrade firmware, etc.
-
1
-
-
You can try it 'off' and see if it helps. It's another 'helpful' feature that thinks it knows how to rewrite packets. It shouldn't be trying on SL streams but you never know. There are likely other clever features that might get in the way. So you may need to wade through a few dozen screens to get rid of the blocking feature(s).
-
Set 'NAT Filtering' to 'Open'.
-
1
-
-
1 hour ago, animats said:
That's a failed HTTP request. It's to [54.184.239.121] , which is the IP address of simhost-0241427d9ea53b667.agni.secondlife.io.
That's a failed UDP message.
So it's failing for both HTTP over TCP and for SL messages over UDP.
Yep, but one is expected (the first, it's the long poll event queue) and one is not (sad udp).
All indications are that UDP is being blocked hard. I'm looking at the router setup in this case or a very, very bad NAT implementation that moved away from the original port. AV/firewall on the host could be at fault as well but it's the router that has changed so look there.
Addendum: looking at the manual for the router, 'NAT Filtering' looks a bit suspicious.
-
On 3/31/2023 at 6:16 AM, animats said:
Huh. The viewer is not reaching the sim at [54.184.239.121] via HTTP on port 12043. That's TCP, not UDP, and it's outgoing from the viewer, so that should just work.
No, his log is correct, 13043. That's a valid UDP port for a simulator on a simhost. It just *looks* suspiciously like a viewer capabilities port.
-
On 3/29/2023 at 8:59 PM, Love Zhaoying said:
LL did not create this thread, I doubt they know about it.
This thread is being monitored.
-
2
-
1
-
-
25 minutes ago, Profaitchikenz Haiku said:
If there is any guide to understanding the log files I would be glad to see it. (ETA I know, you're going to say "So would we")
Hahaha. No, the answer is even more hilarious. LL was never interested in that so the one bit of writing I did on decoding the log file was actually published in Firestorm's Jira. (Found it: https://jira.firestormviewer.org/browse/PHOE-2707 - damn, that was a long time ago.)
The log file *is* ugly but looking for missing events is a promising technique. There is a TP failure mode around missing 'TeleportFinish' messages and/or responding to them slowly. Something to look for...
-
1
-
-
47 minutes ago, Profaitchikenz Haiku said:
a) Why did region F pass across all of the details to region G and forget about me when it seems that region G wasn't ready/able to accept me?
Don't know but part of the reason may be hiding in your SecondLife.log file.
-
1
-
-
RCs were bounced today. Plan was changed late. (No gold star this week.)
-
3
-
-
It's not the most likely explanation but hardware faults do arise. Check the Windows Event Viewer for logged problems.
-
2
-
-
Yeah, that's a server-side problem to be fixed if true.
-
1
-
-
7 hours ago, primerib1 said:
Therefore, as the title of the thread asks: Is there a rate limit for the "cap" API? What number of in-flight requests should I limit my 'interrogation' of the "cap" API to?
A general guideline: these are very old APIs implemented on old tech stacks. So follow old recommendations such as keeping connection count to two or less (six would be the modern number) and be prepared to back off quickly when 502/503/504 status codes come back.
-
2
-
-
They should be in 577595 which is on the BlueSteel and Magnum RCs. Magnum Sandbox 1, 2, and A and BlueSteel Sandbox 1, 2, and A should have the calls.
-
This is going to continue for awhile. File a support ticket when it happens. The support team is well-practiced at handling it.
-
2
-
Facebook
Instagram
Twitter
YouTube
Flickr
Week of May 8th, 2023
in Second Life Server
Posted
Well, I can 'raise awareness.'