Jump to content

Monty Linden

Lindens
  • Posts

    207
  • Joined

Everything posted by Monty Linden

  1. First a warning: be careful posting log files to public places. They can reveal information about yourself and others that you (or they) may not wish published. As for your session problems... The very first lines of your log indicate your session has already failed: 2014-04-26T05:29:26Z WARNING: llmessage/llcircuit.cpp(1071) : LLCircuitData::checkCircuitTimeout: LLCircuitData::checkCircuitTimeout for 216.82.46.72:13028 last ping 101.7 seconds ago. 2014-04-26T05:29:26Z WARNING: llmessage/llcircuit.cpp(1081) : LLCircuitData::checkCircuitTimeout: LLCircuitData::checkCircuitTimeout for 216.82.46.72:13028 still dead, dropping. The timeout usually indicates two things: Networking failure preventing UDP communication. This can be caused by firewall, NAT, router problems, computer problems, anti-virus, ISP problems, traffic shaping/control and other networking issues. Large, unorganized inventory. After login, the viewer creates some initial inventory views. With particularly large and/or unorganized inventories, this can take so long (~90 S or more) that the UDP circuit timesout before it can be established. (Another version of this involves having too many calling cards which results in a lot of inventory communication at startup.) Solutions include using a faster machine or network to get past the timeout and then reorganize inventory. Calling card problems can sometimes be resolved with a support or jira ticket. I can't tell which applies to you, the cause, if identified at all, will be earlier in the log file.
  2. Gwyneth Llewelyn wrote: Now we need more people to test it out. I've done a few tests with 3.7.4 and it is a bit better without any Internet Plugins, but eventually the chat delay will come back again. So there has to be something else additionally to that... I don't want to discourage anyone from stepping up and doing tests but I did want to add a technical clarification. Web-based rendering is handled in ancillary sub-processes running the SLplugin image. This provides a great deal of isolation between the viewer rendering paths and the rococo horror found in web frameworks. I won't say a causal relationship is impossible. But I would be incredibly interested should tests support it.
  3. Perrie Juran wrote: Thank you for the additional information. Is it OK if I add this in a reply in the KB? Sounds like a reasonable addition, sure.
  4. Perrie Juran wrote: OK, I'm putting this here because not sure where else to go with this. In this thread, where the OP got a little testy with those of us trying to help her she stated and posted a screen shot with the error message, "login failed (Waiting for server response)." I can count a half dozen other times this has come up in the Forum or Answers yet can find no reference to this error message in the Knowledge Base or Wiki. So the best any of us have been able to offer is the Knowledge Base article, Login Failures. Are any of you Server Devs able to offer any more insight into this error message and if there is more insight is it possible to update the Knowledge Base accordingly? That's actually a very specific error message that comes from the XML RPC system used, for example, by the login process. You can find it in viewer sources in llxmlrpctransaction.cpp. It indicates that a response was never received for a request or that a request was never fully sent to servers. Problems of this sort are usually due to maintenance or other issues on the servers. But if they persist, then there's an issue somewhere in the pipeline (client, networking gear, isp, backbone, linden). In this case, viewer log files are the place to start looking. Jira or support can be one way to get eyes on the problem. For those who want to self-diagnose from the log files, you can learn how to read some of their content here: http://jira.phoenixviewer.com/browse/PHOE-2707
  5. Conversion is performed by the upload. You can get more details here: Mesh Asset Format
  6. Possible viewer fix for DNS problems: http://community.secondlife.com/t5/Second-Life-Viewer/DNS-problems-at-login-a-possible-solution/m-p/2423913
  7. Since at least 2007, the viewer has shown intermittent DNS failures during login.  Typically, this DNS problem appears as a login failure with the following alert: This occurs on all platforms and for multiple reasons, not all of which are completely understood.  But they center on a DNS resolver library that issues DNS requests directly from the viewer.  To solve these problems, we're trying a scheme that uses threads and the normal operating system resolver library.  We now have a Project Viewer that implements this scheme and we're inviting those who've experienced these problems to give it a try and maybe do a comparison test. Release Notes and links to the Project Viewer installers can be found here:  http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Project_HTTP/3.6.13.284698.  A reminder about Project Viewers:  these are 'early access' releases that may be less stable than Release Candidate or Beta Viewers.  If you can't bear the risk, please consider waiting for a later release. Comparison Test If you had this problem and changed your computer's DNS configuration to use Google DNS (https://developers.google.com/speed/public-dns/docs/using) or other DNS service to work around the problem, you may be a candidate to perform a comparison test.  The test involves restoring your DNS configuration to a pre-workaround condition and then running your current viewer and then the Project Viewer. In detail: Before installing a Project Viewer, revert your DNS configuration. Restore your DNS settings to their original values.  In most cases, this will mean switching back to the values provided automatically by DHCP.  Visiting the Google page may jog your memory. Confirm that your current viewer again has the DNS problem. Login using your current viewer and see if you get the DNS error above. If it just works, that's good for you, bad for us:  we won't be able to see an improvement.  You might leave the DNS settings in their natural form (using DHCP) or go back to Google DNS.  Whichever works best for you.  You might test the Project Viewer anyway to verify there are no regressions.  (I'm happy to have good/good comparison reports.) If it fails to login due to the DNS problem, you've confirmed the original situation still applies and we can move on to the next test. Test the new viewer; confirm correct behavior. Install and login using the Project Viewer. Login and scene loading should work as expected without DNS errors. Teleport a few times and verify that scene loading continues without DNS problems. Report test results, good or bad. Tell us what you found in a reply to this topic.  If the Project Viewer gives you DNS failures, describe the circumstances leading up to the failure and the failure itself if you can. And if you experience other problems not related to DNS, please report them in Jira (https://jira.secondlife.com/).
  8. Mystier wrote: Please may we have an update Monty Sir Nothing new to report at this time.
  9. Just a note that this is getting attention under BUG-4644. No information as to when a fix will be available.
  10. By any chance, is this an HP system running HP Remote Graphics software?
  11. Pamela Galli wrote: And this is what I see when looking at content in my store, including Linden trees: Pamela, I'd love to see the SecondLife.log file from a session that produces scenes like that. I haven't been able to find your jira but if you'd attache the log file to it and point me in its direction, something might be learned....m
  12. Qie Niangao wrote: I see this went a month with no improvement; that's too bad. It's a weird one, though, given that you're only seeing it with the Linden viewers, even though the inventory processing is overwhelmingly identical across viewers. The one thing I can think of is a "stuck" preference regarding "HTTP Inventory" in the Develop menu. (If there's no "Develop" in your menubar, try pressing Ctrl+Alt+q first.) I would suggest trying this (turning 'HTTP Inventory' off). I believe the setting is dynamic (not requiring a relog). But relogging is safest. The SecondLife.log file may offer an explanation. Note the time, to the second, when you click 'Inventory'. Then examine the log file for problems concurrent with that time. These will also be valuable when filing a JIRA report.
  13. Dresden Ceriano wrote: I was under the impression that this, while once so, is no longer the case... As a data point... a windows viewer performing texture and mesh downloads can keep 1.75-2.5 cores busy averaged over many seconds. Burst demand can be higher. Steady state after all assets are resident on the host will be lower.
  14. Sarah Passerine wrote: I think the new Firestorm beta, found at http://www.firestormviewer.org/downloads/, contains the viewer fix for this issue. Thanks so much, Monty, for all of your help here. You're very welcome. But just a reminder that this is a workaround for a problem originating with carriers. They may change things and introduce similar or new problems. Getting after them to test and fix their stuff may help everyone in the long run. (Using SL to smoke test their gear and configurations would be a nice step...)
  15. Jaffee Gaffer wrote: When all is said and done, in MY experience, SSA/SSB/Sunshine is MUCH WORSE than client side baking was. But it does no good to complain. I just get told over and over "It works fine for me." So what? It's Jira time. A complete, actionable bug report is the way to go. Include SecondLife.log (or equivalent), a description of your local network (router, wired/wireless hops, ISP/Carrier), and regions involved. Create a descriptive 'Summary' and include the text "[sSB]" on the end. Should triage faster that way.
  16. Only specific suggestions I have are: 1) do as many sessions as possible in regions with other avatars and 2) clear cache between sessions so textures must reload. This 2nd item will slow scene loading but is useful for testing. Once some testing is done, keep your cache, it's valuable.
  17. Perhaps we should have a Heisenberg state where no one can assume a particular condition...
  18. Yes, this will be a viewer update at some point. It *may* fix your problem. But if this is a carrier-caused failure, there may be additional problems. If anyone is working with upper tiers of support at their carrier, I'd strongly suggest pointing them at two replies in this topic. The first gives them a test they can perform. They should replicate whatever setup you have (phone/wireless device, connection type, etc.): http://community.secondlife.com/t5/Second-Life-Server/SSB-via-T-Mobile-cellphone/m-p/2215959#M12043 And this reply shows what happens if they're doing something very wrong to HTTP: http://community.secondlife.com/t5/Second-Life-Server/SSB-via-T-Mobile-cellphone/m-p/2235061#M12155 What they need to check is that 'Content-Length' and 'Content-Range' are in agreement. The problem appears when they are not.
  19. Many thanks for testing that out. We'll try to get that out. There may still be breakage because there is still something defective in the carriers' network. So, if you (or others, this may or may not fix their problems) see failures again, speak up. We may need to do more....
  20. Bunderwahl Guisse wrote: I would be happy to be a lab rat, just tell me what to do and I will do it Happy to have you in the lab. The warning is that this is one that's for people already comfortable with building the viewer from source. It's not a simple checklist process.
  21. Monty Linden wrote: Let me prepare something there... The following is something Linden could do about this. It's a one-liner in lltexturefetch.cpp that could be tried instead of the change in llcorehttp. This has the effect of making large requests look like more typical GET operations. I'd be interested in knowing how well this works.... --- a/indra/newview/lltexturefetch.cpp Wed Sep 18 14:32:18 2013 -0700+++ b/indra/newview/lltexturefetch.cpp Mon Sep 30 15:39:14 2013 -0400@@ -1482,15 +1482,15 @@ << LL_ENDL; // Will call callbackHttpGet when curl request completes mHttpHandle = mFetcher->mHttpRequest->requestGetByteRange(mHttpPolicyClass, mWorkPriority, mUrl, mRequestedOffset,- mRequestedSize,+ (mRequestedOffset + mRequestedSize) > 20000000 ? 0 : mRequestedSize, mFetcher->mHttpOptions, mFetcher->mHttpHeaders, this); } if (LLCORE_HTTP_HANDLE_INVALID == mHttpHandle) { llwarns << "HTTP GET request failed for " << mID << llendl;
  22. Sarah Passerine wrote: So, it appears that the length and range headers are in disagreement with the curl grab of www.example.com as well. Many thanks for doing this test. This is making far faster progress than trying to reproduce this internally. Yes, it pretty much points to the network infrastructure as being that bad party. That said, the request is a somewhat atypical way of getting a page. Perfectly legal and has well-defined behavior but atypical. (No 'Range:' header or 'Range: bytes=0-' would either be more typical.) We do rely on 'Range' working and that won't change. But for SSA, there is another hack that might fix this problem as well as keep the 'Partial File' retry for those suffering different network problems. Let me prepare something there...
  23. I'm going to give the debug setting some thought. A loose/strict mode selector. I'd still like the 'curl' command tests against example.com though...
×
×
  • Create New...