Jump to content

Monty Linden

  • Content Count

  • Joined

Community Reputation

44 Excellent


About Monty Linden

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Occasionally, there may be hints of problems in the event logs. If you don't mind digging through a lot of noise: Windows Administrative Tools > Event Viewer (or some variation of this depending on windows) Then in the viewer, Event Viewer > Windows Logs > System to see what is going wrong and when Recently caught a failing disk with that while it was still possible to clone the disk...
  2. Build a japanese-inspired region and I will visit. :-) It's true, most of the young nerds like a high-spec machine but I'm a contrarian. I don't code randomly so continuous compilation isn't required and I like old hardware to fly the flag for residents. It's just a bit painful at times...
  3. Not an official Linden recommendation but I've used this site as a reference based on their correct assessment of the classic WRT54G: WRT54G is a lousy router. If anyone is still using routers like that or early Belkin, etc., please, please consider an upgrade. Their charts (Router Charts) list some potentially interesting tests like Max Simultaneous Connections but they're not collecting data on them. Still, some other tests where data is available are relevant. And if anyone has links to better evaluation sites, please pass along the links.
  4. This linden dev has an HP z600 with a gtx 660 card. How high do I score?
  5. Never rely on second-hand information. If you're using Windows, go grab SysInternals tool suite and poke around with Process Explorer. (You can also do this with MS Performance Monitor, it's just more annoying.) Go ahead, I'll wait here.... o |~~~| /\_ _| | \__`[_ | ][ \,/|___| Okay, you're back. :-) What did you see? Depending on specific build, OS, etc., there are about 20 threads in the viewer. Some rarely if ever do any work. The Main thread is generally pinned to the wall eating a full core. But enter a new area where you need to pull in new content or deal with other dynamic situations and you'll see more activity. Peak, averaged over human-scale intervals of seconds, can be around 2.5 cores or so.
  6. No such udp port should be in use between Viewer and a Simhost. If you see this again, please record as many details as possible (date, time, timezone, linden sim IP address <216....>, region, etc.) and file a Jira or at least reply here.
  7. The cache (or more correctly, the caches, there are many, all different), isn't a simple file cache as with a squid/http cache. Right or wrong, we implemented a bunch of special little snowflake caches each with its own challenges. One common one is that the compiled, in-memory structure of objects is often reflected in the cache. We have an imperfect method of indicating changes between LL viewer releases but none between viewers. The only solution there is separate caches. (Extra credit: discuss 32 versus 64 bit builds.)
  8. Any perceived improvement from playing with that setting is pure Placebo Effect at this point. It isn't connected to anything in the viewer. You can get a few more details in a nice little diagram in this old post: https://community.secondlife.com/forums/topic/343472-meshmaxconcurrentrequests-does-anybody-know-the-real-setting/#comment-1112283
  9. I'm not familiar with our support and recovery processes so take this with a grain of salt... In theory, with some tooling, that could be used to aid recovery. Would have to be cross-checked with activity logs, etc., and recovery would likely be partial. But in theory... Continuing with the whiteboard exercise on backup possibilities. User could take possession of a Linden-signed Inventory manifest to be presented in case of disaster. On the server side, recovery checkpoints might be an interesting idea. Any such things would be subject to anti-theft guards against, e.g., no-copy scamming. Possible parts of a solution that would hopefully include more robust Inventory operations. And no argument about the need for that.
  10. By any chance, are you using a VGA cable for video? Do you see black, unused screen areas at the right or left of screen?
  11. For unusual connectivity problems, filing a support request is the best place to start and it looks like you might already be on this path. The *exact* error message you are getting may matter critically here. There are several similar messages possible with distinct causes. Is the actual message: "The system has logged you out because you are attempting to log in from another location."
  12. Rabid Cheetah wrote: ...sometimes it's some weird alternative stuff with a voice over of Presdent Kennedy talking about going into outer pace. Sounds like 'Misson Control' on SomaFM. A favorite stream.
  13. Callum Meriman wrote: EliteData Maximus wrote: wouldnt it be great if those of us with Terabytes of storage could download all or selected mainland/private/world/sim caches that have not already been cached to disk, during the times we are not active on Second Life ? Sadly the VFS file system the lab invented to be a cache is one of the world's worst implementations of an LRU cache. It fails after about 2GB of size, becoming exponentially slower, and also buggier to the point the whole index is broken. We can dream of an efficient LRU cache, but sadly the Lab are putting too many of their programmers onto the white elephant of Sansar. Or... It could be that Sansar provides secondary duty as a rapid-cycle development testbed to proof out ideas that could then be re-implemented in SL with fewer iterations. Various cache aggregation schemes have been mooted internally as long as I've been here. And Sansar is actually demonstrating that something other than a global, dynamic, "LRU" cache might be a better experience in some cases. But there are some SL-specific aspects that might be attacked first with greater impact: Too many styles of caches. Nearly everything that caches does so in a unique and special (and buggy) way. VFS system is limited in size and has some performance and serialization issues. VFS system solves a problem (poor native filesystem performance for many small files) that doesn't exist on supported platforms in this decade. Image cache (PNG, textures) has an index that limits the size of cached textures. This may also be a source of silent and deadly bugs. Processing of cached data to ready-to-wear data slows viewer. Caching of post-processed data might improve experience. Eviction logic might be better. Inventory caching could use a review. There's stuff in the above that could be a nice win for a TPV...
  • Create New...