Carol Darkthief
-
Posts
54 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Carol Darkthief
-
-
Summary from Europe: internet speed a little down, internet ping good, similar speeds to SL, other US locations, and Europe. Reported log-in number was lower than the recent usual by about 10% but has started to rise again. Was able to log in OK, SL stats are looking good.
In my experience, systems are a bit sluggish when they get over 45,000 total logins.
-
5 hours ago, Polenth Yue said:
I'd stay on the cautious side of behaviour when it comes to big event groups. They get griefed a lot and tolerance levels for rulebreaking are often very low. Which is why I wouldn't ignore regular group members, thinking that you'll get a proper warning from a moderator... often you'll just find you're banned. Those warnings from regular members are letting you know so that you can avoid that.
There's truth there, but how do you tell who is a "regular group member"?
Even in long-standing help groups, that's difficult. On what I have seen of this year's SL17B groups, even the "official" post warning of events have been spammy in style: multiple lines of uninformative "decoration", and little or no information about about what style of music the DJ or Live Performer is presenting.
They have not done a good job. The only event which piqued my curiousity enough to lure me into one of those overcrowded, viewer-crashing, lag-fests was almost invisible in the published calendar, and I would have missed it if one of the performers hadn't done his own promotion elsewhere.
Two more days... If I want music I can watch recordings from Glastonbury on the BBC
-
On 8/29/2019 at 5:51 PM, Chic Aeon said:
Just wanted to comment that as I understand it, "old" system files will work on BOM but are 512 resolution where as files made for APPLIERS are (generally) 1024 textures. So wouldn't it be good to know if the BOM versions are "updated" and 1024 for clarity. A 1024 texture is FOUR TIMES larger with four times more pixels than a 512 file.
That was kind of my argument on another BOM thread. If I am going to buy new texture clothes for a BOM body, I want them to be high resolution with clarity in the details that I am now used to === not going back in time. So perhaps some "star" annotations on how a creator is handing BOM. They could be making BOM for all their new stuff, the could be updating older files to 1024 (assuming they still have the active files) etc. That would certainly be something I would want to know if there wasn't a demo.
That's worth knowing, but the big textures quadruple the download, add to the cost of locally generating the mipmaps, and hit local storage and caching. It wouldn't encourage me to buy a product (and too many have permissions settings that block access to the pixel-size info, so even Demos are of little use).
Not all the textures even need to be 512s. How close do you have to get your camera to an eye before you see a 512, never mind a 1024?
We don't all have super powerful modern computers, but too many creators and pundits assume we do. Would it be so hard to supply a low-power version of a BoM wearable.
-
4
-
-
On 8/30/2019 at 8:04 PM, Henri Beauchamp said:
@Vir Linden
There is a feature I already wrote about on this forum (it was last year, in the initial thread about BoM), that I still think would be useful: have an additional set of bake UUIDs that won't trigger the auto-hiding of the corresponding parts of the avatar.
I encountered no later than yesterday a use case for such bakes: a mesh body avatar (that lets you use the SL avatar head) with a half-neck mesh part, that allows a smooth blending of the mesh and SL avatar head/neck: when applying the baked head texture to the neck (so that the neck part of the mesh is colored like your SL avatar neck), the head vanishes... You can't use a bake on the neck, meaning that particular mesh body cannot blend properly at the neck level...
Other use cases would be mesh bodies with parts of the underlying avatar showing (think cyborg, amputated avatars, etc): for those you don't want the full upper or lower body to vanish when using baked textures on the mesh parts, but instead would use appropriate Alpha layer(s)...
The implementation would be trivial, as I see it; in the texture picker, add a ”auto-hide body part” check box (and IIRC that check box existed in the initial BoM implementation, but was not ”wired” to any code in the viewer), and when not checked, instead of applying, say, ”IMG_USE_BAKE_HEAD”, the texture picker would apply a new ”IMG_USE_BAKE_HEAD_NO_HIDE” UUID to the edited face. Then, in the viewer code, skip the body part auto-hiding when any of the ”*_NO_HIDE” bake textures are used instead of their counterparts.
I have a mesh body that has that neck feature, and a few other features that may be problematic. I was using your Cool VL Viewer, which I keep on my system as a sanity check, and I think I shall wait and see if experienced Creators can get Bakes-on-Mesh working. Seeing some of the things they do, I don't feel optimistic.
The particular mesh body also has overlapping sections. They map OK to the class UV map, but there are panels which are distinct, such as the front, sides, and back of the upper body, which overlap. It's one row of quads (which each comprise two triangles), I suspect it avoids problems with gaps at extreme shape settings, and the body looks fine with the pre-Bakes-on-Mesh tech. But go Bakes-on-Mesh and you get all the seams showing, internal to the upper body and at the upper-lower boundary.
I do wonder if the Lindens responsible really knew what they were doing. Or was it whoever set the test criteria?
Another reason I wonder about the Lindens is the 1024 textures on those freebie outfits for SL16B.
-
I have a feeling that a lot of connection-related problems could need different answers now that so much has moved from UDP to HTTP, and there is the CDN.
What does the "Bandwidth" setting actually control?
What effect does the CDN have at my end of the connection? Can that traffic mess up the mostly UDP command and control traffic from the Server? That's certainly consistent with the horrible warnings I find else-net, but I don't know the details of just what you did. (You personally and the Lab as a whole)
I sometimes find myself wondering if I am even asking sensible questions.
-
I just tried checking that page.
I could tell it was bug SVC-22 which must be really really old, but the JIRA system seems to be unusually hostile this morning, throwing unclosable pop-up windows at me like a cheap porn site.
-
I see you got things sorted.
That error message looks odd.
I think I would have tried a reboot of my system, to clear up any lingering elements that might not have closed. And that might be behind your problems. If the program wasn't properly closed, the update could have fallen over.
Rebooting your system is one of those catch-all fixes. And, like all of them, it tends to dodge "what went wrong" questions. There are other ways of fixing a program that didn't close properly, involving Task Manager and such, but the details get hard to explain.
-
Anti-virus software varies in things like false alarms, but don't remove what you have. I'd disable it after downloading the installer, manually run a scan on the installer, and see if anything is flagged.
A Linden Lab download should be safe, but if anything turns up in the file, let us all know. There are false positives, but the Lab might have slipped up.
Then install without the anti-virus active. I'll go along with the other commenters about installing from scratch. You shouldn't really need to but sometimes it can make a big difference. And it is one of the standard problem-cures which can work without having to know what is wrong.
I know the Firestorm crowd have a web page on doing a Clean Install which tells you where things such as chat logs might be, and how you can keep such things safe. There may be something on the SL Wiki too. Folder names will differ for different viewers—a quick check suggests "SecondLife" can be substituted for "Firestorm".
In my experience, a Clean Install isn't as vital as some would say, but when things get like this it makes a huge amount of sense. It's like rebooting your ADSL-router, an easy no-thought answer that can make a difference. And at times like this, why not?
(And a part of me says you don't try every fix-it trick at the same time, because you never know what really fixed it.)
-
I know you're correct about the cache clear option, but "bake fail" is starting to look like another catch-all problem answer.
Some of the standard answers even look as though they could fix a range of problems that have nothing to do with the SSA system. Reboot the router-modem, Log-out and log-in again. How many other things will those fix, but it means the problem is confirmed as a bake-fail, and so "resolved".
-
Firestorm uses RLVa. So do most other viewers that are RLV-compatible.
The differences are slight, when you look them up, and Firestorm is reckoned the most widely-used Viewer. One I noticed was a restriction on channel numbers used, to avoid an LSL restriction on message length. I think if I were writing code, I wouldn't want to be caught by the difference.
The combination of slight changes and widespread use tips the balance towards RLVa.
-
I have sent you a Landmark in-world. There's a whole sim called "Lolas" with the in-world store. You may need to check the age-rating you have set for searches.
-
Even in California, it has stopped being Sunday, so I am not astonished that things have improved.
-
That sounds a little bit different from my experience; it seemed to be the SSA that was the chief problem, mesh attachments next, I didn't see any problems with prim attachments. I shall give things a try in a little while, I have one or two RL things to do first.
I do recognise a couple of names here from the chat logs I have from Sunday.
It's a long time since anyone threatened to pay me for my internet knowledge, but I have been known to get down and dirty with the internet protocols, especially DNS. This situation is easiest to explain through problems with the SSA servers or the Linden Lab network, rather than a wider ranging problem that was likely to be affecting other services sourced from the Phoenix area. But it isn't always easy to see the difference.
-
There seem to be a lot of reports of people in the UK having problems loading avatar textures. I has been affecting me.
Nothing seemed to be wrong on the UDP side. Viewer-reported Ping times were normal and there was zero packet loss. Attachments and scenery in general were loading textures without problems, which means the CDN network could have been hiding any intermediate problems. A traceroute to community.secondlife.com confirms a Bay Area location for this server I am typing into, and very different routing.
A traceroute to the sim server shows routing over the Level3 network between my ISP in London and Phoenix
Ping times and a Speedtest to Phoenix give me results in the usual range.
I am not sure how a network fault could be affecting just one sub-class of HTTP traffic between Phoenix and London. Some textures eventually loaded, but a wait of over an hour, with no changes from trying to force a texture rebake or from relogging, leaves me thinking that the problem is in the Linden Lab servers. But why does it seem to be only affecting one part of the world?
I am badly out of date on this networking stuff, but I would urge you to check the SSA Servers. If it's a network problem I can't see how it would be blocking one particular texture every time, but with only four "baked" textures that still could be chance. If it is a network problem I would expect it to be affecting other traffic to the Phoenix area, but how can I check that? Ah, Flying Buffalo Games! Their website loads OK, but I am not sure if their server location is anywhere near their postal address.
Can folk, if they have similar problems, do a traceroute to check which provider is carrying their data to Phoenix? It can take a little Googling to pin down the name, but there will be at least a clue in the server names involved.
I'm not sure, I only read English, if anyone elsewhere in Europe is being affected. Likewise, if the problem is between Linden Lab and the transatlantic cable, it might be affecting some people in the USA. Also, from past experience, I know that ywo supposedly independent network providers can end up running their data along one small cable duct. There was one time when a flood took out a bridge, and two completely seperate connections to the USA went down.
-
It's probably a coincidence, but I'm seeing a better connection now. There are still bursts of high Ping Sim, but they are much smaller than they were. They may be related to events such as the arrival of a new Avatar in the region, but I wouldn't lay a bet on that.
I am seeing some of the same when I teleport, and maybe a very short burst of packet loss.
-
Thanks, Oz. That clears things up a lot. Knowing that Ping Sim is UDP to the region server does eliminate a lot of my guesswork about the high Ping Sim readings I see.
May I suggest a revised wording for the description in http://wiki.secondlife.com/wiki/Viewerhelp:Statistics
Ping Sim: How long it takes data to go from your computer to the region sim server you're currently using. This does not reflect texture and mesh loading through the CDN service but measures UDP communication to the sim server itself and is affected by both by the internet connection and the load on the server hardware. It will normally be higher than an internet ping or traceroute time to the same address.
I have seen claims, some rather old, that combinations of UDP and TCP traffic on the same link can lead to problems. It doesn't matter where the CDN server is, it's all going to converge on my broadband connection, but the telco engineer vans are exhibiting breeding behaviour in my part of the world, Maybe something will suddenly improve.
-
And the DNS problem did get fixed by using a different DNS server. That still doesn't sound like the ISP messing with the modem the customer is using. There's a chain of DNS servers between the ISP's DNS server and whatever server is "authoritative" for a domain. And I've known that chain get a "bad" mapping between domain name and IP address when something has changed at the authoritative server. It takes time for the change to propagate. Maybe an ISP is running a DNS server with too long a TTL on the DNS entries. A quick check on the Wikipedia entry on DNS shows a link to a report on Slashdot but it was ten years ago.
That old claim does seem to linger in Google searches, and it would explain some things. But, unless Linden Lab are changing IP addresses very frequently it wouldn't explain anything I see. That sort of thing would cause a lengthy total fail, and I've never seen that for Second Life. It is something I have seen in the past for other services. And the fix of trying the Google or OpenDNS servers makes a very obvious difference if the ISP's DNS server were doing something weird.
It's not the place for solutions, but I do know what the scary devil monastery is. And sometimes Second Life and Linden Lab do seem to need a LART.
-
I know about the ADSL modem buffering problem, and how the only fix may be an expensive "office" quality black box which can handle a lot of connections. I did check with my ISP over the QOS settings they use for Second Life. They say they don't do any fiddling with my modem and, frankly, I am sceptical about that detail. You seem to be describing the buffering problem and then blaming it on ISP doing something.
It's not really my choice at the moment, but I did have a look at a couple of sales sites, and I can foresee having to deal with salesmen over that side of things. Not fun. Some of them haven't even heard of IPv6 yet.
-
"a few data centers"?
The last I heard was that the servers were only in Phoenix AZ now. That doesn't exclude more than one data centre, but I've not pinned down any direct-from-Linden-Lab source for that, and it would have been easy enough to post to a blog or official webpage of some sort. It was allegedly said by a Linden at a TPV Developer meeting, but I don't even know which one.
(I sometimes wonder whether the UDP bandwidth setting has any significance with so much now being HTTP. Maybe it could be set lower than the past recommendations? All I've found on that hasn't changed in the last couple of years, while Monty Linden has been hustling away at HTTP for textures and mesh.)
I can see what you're getting at about checking different servers, but why don't they say that? It's a plausible guess, but it also looks like users trying to find a current explanation for some obsolete documentation.
-
You're more-or-less summarising what I suspect about in-viewer Ping Sim.
But does anyone know? And why is the LL documentation on this so useless?
I'm trying to get my brain around RFC 1323 which defines TCP timestamps. It's not defined in a way which requires the clocks at each end to be in-sync or ticking at the same rate, so I am not sure how anyone thought they could give a seperate Ping Sim and Ping User instead of total RTT.
There are hints that it could get horribly complicated, with various possible methods of averaging RTT for controlling congestion. Speculating more wildly, with the TCP data for an SL connection coming from multiple servers, and now with a possible different route to the CDN server, the UDP/TCP combination could bite. But that's a MEGO situation for me.
-
And just what is "Ping User", because that's the only time that phrase is used on the page. Mostly, it seems to be something totally different on Facebook when you try to find it elsewhere on the net, an "are you there" of social networking apps.
I have found a reference to it in a book about SL published in 2007, which implies it's another number displayed in the Stats Window. And it ain't there any more. And, I'll be honest, I can't see how you can measure just the one-way time instead of the RTT. It makes me wonder, a little, if you know what you're talking about. But let me know if you can find "Ping User". I might have missed it.
-
What does the "ping sim" number in the viewer's statistics window actually measure?
There's a network utility called "ping", which uses special packets. Quoting Wikipedia, "Ping operates by sending Internet Control Message Protocol (ICMP) echo request packets to the target host and waiting for an ICMP response. In the process it measures the time from transmission to reception (round-trip time) and records any packet loss."
If the viewer is doing this, I'm not sure it would be reliable, and I don't see much point in sending an extra stream of packets to the server. I don't think an ICMP message would even be seen by the sim server.
The other obvious way of doing this is to time the reply from the sim server to a request for data. This doesn't need any extra packet, and can directly measure the server reponse. This could be affected by the change in the delivery of data, first with dedicated servers supplying textures, and now with CDN. I once saw Ping Sim increase to over 7000ms, with no reported packet loss, when on a Snack RC sim, which runs CDN
But I could be missing the packet loss. The Packet Loss indicator in the Stats Window may be failing to respond to sudden, short-lived, packet loss. I see the 0% occasionally flicker, but it doesn't hold long enough to read.
It needs somebody who has read and can understand the code to answer this. I have a feeling that there is something lurking in how the numbers are displayed which has probably come from the Linden Code, making what we see unreliable. Do I have rock solid 0% packet loss? I suspect not. Was that 7000ms ping sim a display glitch?
With the viewer labelling the number "ping sim" I am inclined to doubt that the measurement is done with ICMP, but what is it measuring? The SL Wiki is rather vague on this,
And if all you can do is point me at that Wikipedia article on Ping (networking utility) why do you think that answers my question? (A clue: I have just quoted that page and given you the link.)
The "ping sim" is giving me about 30ms higher RTT than using a ping, from the command line, to the same domain name, and the ping times to Phoenix have been similar for a really long time. (Well, Flying Buffalo is in Scottsdale, which is next door.) Either that extra 30ms is something wrong, or it measures something different.
-
The obstruction has now been cleared, and the junction is open. No word as to why it happened.
-
Griefers have been suggested, but I've never heard of anyone identifying them. There are so many possibilities, so little definite information, and no sign of any help from the Lindens. For something as new as this, on a special small relesae channel, that's a bit worrying.
Facebook
Instagram
Twitter
YouTube
Flickr
Hi Lindens & Moles: What is the actual conversion measurement of a SL meter to RL feet/inches?
in General Second Life Tech Discussion
Posted
I measure distances in Light Fortnights. What are you people wittering about?