Jump to content

Carol Darkthief

Resident
  • Content Count

    49
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Carol Darkthief

  • Rank
    Advanced Member
  1. 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.
  2. 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.
  3. 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.
  4. 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.)
  5. 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".
  6. 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.
  7. 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.
  8. Even in California, it has stopped being Sunday, so I am not astonished that things have improved.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. "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.
×
×
  • Create New...