Jump to content

Monty Linden

Lindens
  • Posts

    207
  • Joined

Everything posted by Monty Linden

  1. Ayesha Askham wrote: One of the worst aspects of general performance, aside from the dreadful inventory issues, at least to my mind, has been the woefully slow rate at which textures are sent by the sim to the viewer. On a sim with more that one or two avatars on it, it might take 10-15 minutes for a highly textured sim to be properly presented to a viewer with more than a 64m draw distance. The more highly loaded with avatars a sim is and the greater the viewer's draw distance, the longer it seems to take now. "Twas ever thus", you say, but no, this is FAR slower than it used to be even using UDP. Has some overly severe throttle been applied? On highly textured and occupied sims such as those of Fantasy Faire, it is taking so long to load textures that folk are giving up and leaving without: 1) Seeing the exhibits and 2) Donating to the Charity...RFL. Now Lindens this is a RL Good Cause, but this issue is blighting it. For us, the challenge before we can take action is to receive actionable data. For something that's not a small feature request or defect or regression, something that looks like infrastructure, this is more important. A solid bug report (as per wiki) including actual locations and times, measurements of performance (how long did textures take to load) and well-defined start and end points of the measurement (started with clear cache, stopped timing when texture console emptied) and log files. That said, a few minutes ago, I visited the host that's currently running the 'Crimson Fields', 'Fairelands Junction', and 'Magnificat' regions. It was undergoing the heaviest sustained mesh download I've looked at as well as a healthy load of textures. The result is a significant delay getting into some HTTP services, something I've seen since working on SVC-6760. Some causes are known to me, some may not be revealed. But good bug reports will help identify them. As for workarounds, I don't have any yet. If it is mesh-dominant, UDP textures won't help so much. Deleting cache constantly will make your experience worse.
  2. There is work underway on animations and avatars so if anything anomalous is happening, it's in your best interest to report a bug via Jira. Gather up as much supporting information as you can and follow the outline here: http://wiki.secondlife.com/wiki/Bug_Tracker
  3. There was a significant networking event today that has cleared. Back to normal at this point...
  4. Ciaran Laval wrote: TP'd away, came back, saw a suspicious looking guy and missing prims again: Did you click the suspicious looking guy to see if he'd disappear? (I absolutely love this region...)
  5. Alicia Sautereau wrote: Deleting cache manually results only in the need to download everything again, the objects some time rez the first time, but after a relog, alot more become "missing" I think Andrew was referring only to the 'objectcache' portion of the cache. It's a directory (a peer of 'texturecache') and deleting just it may be worth trying. Not a fix and it may not even be a workaround but much less of a reload hit than clearing the texture cache as well.
  6. tristangarrard wrote: Something I noticed tonight, and this seems to happen on multiple sims, is that the textures will complete loading and the viewer stats will show a bandwidth of circa 10kb/s as normal, but my firewall (Little Snitch) still shows data constantly downloading from the sim IP address at a rate of about 150kb/s. This does cause some inevitable lagging as well as hammering my bandwidth, I think I saw about 215MB come down in total from the sim before I relogged. Relogging seems to clear it for a bit but then it restarts. Anyone else seeing this? The Texture Console speaks truth for texture fetches, either http or udp. If that is quiet while this transport is going on, it's something else. Little Snitch can tell you more and here are some rules that will determine the traffic: Port 12046 but textures are quiet => mesh fetches Port 12043 (corrected, was 12042) => other HTTP services ("Capabilities") UDP port 12035, 13000-130XX => simulator communications
  7. Glad you found a solution. Noted the success in my tables (which I'm trying to turn into wiki pages or something useful). If you later decide this router wasn't such a winner (sometimes it takes time to find the faults), please let us know. m
  8. The difficulty with Wireshark, or any tool like it, is that it raises a security concern. These tools can reveal any and all information visible on a network. All data collected needs to be handled and treated accordingly and never made available publicly.
  9. 16, I would actually like to get a Wireshark packet trace from the Thompson if it is that bad. I'm going to see about getting some router pages up on the wiki. I'd love to collect suggestions somewhere in the forums but I'm not certain how effective that will be... m
  10. *sigh* Phone companies and ADSL. More cut-corner engineering, I'm smelling. For your particular case at this particular moment, disabling HTTP textures may be a best first step. This is another environment where more attention is needed. There's a community involvement role for those who are interested and capable of the work. Some things I'd love to see: Packet captures using Wireshark or similar tools. Need to be able to setup useful configurations, run reliable tests and be aware of the security and privacy issues involved in this. Vendor lock-in environments. This applies to ADSL, some cable setups and regional practices (I'm looking at you, .eu) where customers are stuck with mandated equipment. It isn't advertised but this equipment can generally be put into a bridged mode where it is no longer performing NAT, dhcp, etc. and users can take over the routing tasks with their own equipment. To do this, you need some technical skills but there is a course of action here with several payoffs. Faster service for those who like to do this. Evidence to take to communications vendors that their equipment isn't adequate. Adding to the knowledge base of known good and bad hardware. Anyone interested?
  11. So far, ports are unchanged though response headers will change in the near future. Ports and URL structure can always change as well. As for caching, no comment on squid per se, for good or bad, our URLs do not really look like resources making caching requests fragile. But the viewers have had their caching limit bumped in the past year or so should you want to try more local disk caching.
  12. Fiddlejenny, I like to know what make/model of router you are using in your setup. tnx
  13. The inventory DBs on Aditi should be back now. We do still have an issue with imports triggered by password changes. If you trigger one, you may not be happy with the result.
  14. Still underway. Getting closer but it's taking longer than expected.
  15. Aditi has been having inventory DB problems. We're trying to get things fixed before Server Beta group tomorrow.
  16. Before the commentary buries the message: all I want is the four simple items from the original posting: Operating system Number of active network interfaces Full list of DNS servers known by your computer Additional information about certain files on OS X machines if and only if you have the DNS problem or can temporarily revert workarounds and make the DNS problem manifest ifself. Current response level hasn't reached underwhelming so don't be afraid of contributing to a flood. I'll post again when I have enough data.
  17. For the moment, I'm interested in the information exactly as stated: the view of the network as seen from a machine experiencing problems (or one that can be returned to a configuration that has problems). The hope is that this is entirely a local phenomenon (or phenomena - I think there are at least two distinct problems in play) and I'll start the attack from that point.
  18. What is your router's make, model and firmware version?
  19. Looking for information on such problems here: http://community.secondlife.com/t5/Second-Life-Viewer/DNS-problems-at-login-a-request-for-information/td-p/1862703#
  20. Jusden Jonstone wrote: Would you also be interested in any such reports coming from Windows 8 users? Absolutely. I just didn't have a Win8 system at hand to create instructions. Vista, too.
  21. In my spare time, I'm trying to dig into the source of the viewer DNS lookup failures that continue to appear.  This problem is identified by the following popup on login: Login failed. DNS could not resolve the host name. Please verify that you can connect to the www.secondlife.com web site. If you can, but continue to receive this error, please go to the support section and report this problem. and by error messages in the SecondLife.log file such as: 2013-01-31T20:50:53Z WARNING: process: LLXMLRPCTransaction CURL error 6: Could not resolve host: login.agni.lindenlab.com (Could not contact DNS servers) If you experience this despite workarounds such as the Google DNS server configuration or because such workarounds aren't available to you, I would like to get some information from you.  If the Google DNS server workaround did work for you, you're invited to revert the workaround, gather the following information and restore the workaround. The information I'm after and which can be reported here, in a private message, or via email to monty@{obvious company domain} should include: Operating system Number of active network interfaces Full list of DNS servers known by your computer Additional information about certain files on OS X machines What follows are more detailed instructions for getting this information from various operating systems and what to report.  Other OS releases will vary from these descriptions. Windows XP: Start > Settings > Network Connections Find all 'Connected' interfaces, report the count. For each such interface: Right Click 'Status' Click the 'Support' tab Click the 'Details...' button Report all 'DNS Servers' Windows 7: Start > Control Panel > Network and Sharing Center Find each network with 'Internet' Access Type; report the count. For each such network: Click the connection to bring up a Status window Click the 'Details...' Button Report all 'IPv4 DNS Servers' Mac OS X 10.6.8: Open 'System Preferences' Click the 'Network' panel Find all 'Connected' interfaces.  Report the count. For each such interface: Click the connected interface in the left column Report all 'DNS Server' entries Start a shell in Terminal.app Execute and report output of: ls -l /etc/resolv.conf Execute: cat /etc/resolv.conf Report lines from the output with 'nameserver' in them.
  22. Camille, if you could go to this Jira reply: https://jira.secondlife.com/browse/VWR-25627?focusedCommentId=335819# and answer the three questions and attach your SecondLife.log file, that would be a good start. Or as a reply to the following Jira which has a link to information on finding this file: https://jira.secondlife.com/browse/SVC-7248?focusedCommentId=303129
×
×
  • Create New...