Elf Clan Social Network

Inworldz is a stable platform... moreso than any other grid I know.  But some folks mention crashing and performance issues.  So here are hints and tips for how to avoid such problems.


Mind you, nothing totally prevents lag and crashing.  Crashes happen.  But these hints should help reduce crashing significantly.


CCLEANER.  (yes, that's 2 "C's").  If you use Windows, this is one of the best "cleaner" systems I've seen and has done more to help me maintain a stable computer system than anything else.  It's free.  Download and install the program and use the first two options.  Sometimes that's all that's required to get your system to run smoothly.


ADJUST CACHE.  Edit/Preferences/Network.  Your disc cache size is likely set to 512mb.  Unfortunately in Viewers there seems to be nothing which tells your system, "Oh, you've reached maximum cache... stop bombing the system".  Cache works poorly.  Cache should be somewhere between 512mb and 1024 for the average user, but it's difficult to tell what is best.  We recommend 512 and if you can increase to more, try it and see.  

CLEARING CACHE.  Edit/Preferences/Network. If after time you find yourself crashing regularly, simply clearing cache can often fix that problem.


OBJECT OCCLUSION.  Technically this is supposed to speed up your system by not rendering items that are blocked to your vision.  Unfortunately it doesn't work at this time... and can cause severe lag.  So:     advanced>rendering>object-object occlusion [uncheck this].

VIRTUAL MEMORY.  This is one few people know about, but is very important.  In Windows, Virtual Memory is your computer using hard disc drives to store constantly used information-- kind of an artificial RAM (I don't know how it works on Mac.  You'll need to research).  Chances are your VM isn't set nearly high enough.  Low Virtual Memory is one of the major causes of crashing.

   When I checked my system, my VM was 2 gigs.  I increased it to 9 gigs by using two hard drive partitions.  Any setting of 4gigs or more is probably sufficient.  There is a limit as to how much VM any hard drive is allowed, so if you have more than one hard drive you can set additional VM... although this may slow down things a bit as your system pulls info from additional drives.

   In Windows XP, follow these steps to set Virtual Memory (it may be different in Vista  or W7, dunno):

   Start / (right click) My Computer / Properties / Advanced / Performance Settings /

       Advanced / Virtual Memory / Change

   (Yes, that's a lot to go through, but that's how it's done.)

   It's fairly safe to set  most hard drives to at least 4096megs (4 gigs).  Save these settings, exit and reset your computer.  When you come back in, go back to that area and double-check the new settings have been established.  Once you increase your VM, time between crashes should increase significantly.

   Unfortunately, there is no way to prevent memory-based crashing altogether, because current Viewers are based on the original SL Viewer, and all have a significant memory leak issue that eventually fill up your VM and cause your system to crash.  Nevertheless, doubling or quadrupling your Virtual Memory should significantly decrease crashing.  In all but the most texture-packed sims, it may reduce crashing to the point you'll hardly ever experience such.


ADJUST BANDWIDTH.  On the same page, check your bandwidth setting.  Different systems will require different bandwidth.  After experimenting I settled on 1500 kbps for mine.  Your internet may require less, or allow more.  The best way to test this is to look at the bandwidth indicator bar in the upper right corner of your screen, and see which setting keeps that bar on green the most.  If you're constantly going into the red, your bandwidth needs adjusting.  Experimentation will determine which is the best setting for your system.


ADJUST GRAPHICS.  Edit/Preferences/Graphics.  Graphics are even more important than your computer when it comes to VR performance. 

   Graphics cards.  A single-core 2ghz computer with a killer graphics card will likely perform better  than a quad-core 3ghz computer with a poor graphics card.  A good graphics card is more important than a killer computer system and will have more to do with your overall performance.

   Low-Medium-High-Ultra.  These settings in your Preferences / Graphics area will directly determine how much stress Inworldz places on your graphics system.  If you have a low-power computer you may wish to use the blocky-but-adequate LOW setting.   Medium gives a bit better graphics while requiring relatively low system resources.  High will require a faster computer and good graphics card, and Ultra will require a "gamer" level system.  

   Graphics Settings. The graphics settings on your computer will greatly affect your performance.  Very few people can use the Ultra setting to advantage.  Most people find that Medium or High is best.  For low-graphic laptops (especially anything using Intel-based graphics), the Low setting will be needed.

   Draw Distance.  Most people can have a draw distance of 128 to 256 meters.  Low power systems will do better at 64.  When in avatar-crowded areas, drop your draw distance to 64 even if you have a good computer; avatars take a lot of system resources.

   Avatar Impostors.  Avatar Impostors imitates avatars at a distance, but it also destroys those avatar details.  Unless your system is low-performance, you're probably okay to click this off.  Currently there is a reported bug in the Avatar Impostors system, so having it turned off is probably best.  However if you have it off and find yourself crashing regularly, try turning it on and see if it helps.   If not, leave it off.

   Detail Sliders. On the right of your graphics window are detail sliders.  If you're having crashing problems or serious lag, it is amazing how reducing those sliders to Med or Low will increase performance.  Unfortunately it will also reduce the detail of your graphics (on Low settings, cylinders turn into hexagons)... but your performance will improve significantly.

  Shadows and Advanced Shaders.  Shadows are pretty.  Shadows are graphics hogs.  Unless you have the most powerful of systems, leave shadows and Advanced Shaders off.

   Emergency only:  Basic Shaders.  Some users report serious problems using any shaders at all.  If nothing else you've tried seems to be working, turn off Basic Shaders.  This will majorly affect the quality of presentation, but if you're on an old, slow computer with minimal graphics, it may make the difference between being able to use the system consistently or not. 

CLOUDS.  Most folks aren't aware of it, but the routines that created animated clouds in the sky take more graphics resources than one would expect.   If you're having regular trouble with lag or crashing, try turning off clouds.   You'll wind up with just a clear blue sky... but it may make the difference you need.

AUDIO AND VIDEO.  If you're standing in one spot (like a a dance, regardless of animations), audio will likely not cause problems.  With very low performance systems, audio can increase lag.  But most people don't care at a dance; they're not physically moving much anyway.

   Video.  My recommendation:  don't use video.  Unless you're on a Mac, don't even install QuickTime.  In my experience it messes with Windows.  If you want to view a video, ask the land owner for the direct-access link (if possible). 

   Video loading can create stop-dead lag, serious performance issues, and crashes systems like a fiend.  I have never once, in 12+ years (and growing) of using VR, ever made it through an entire in-world movie without either me or the video crashing.  VR video was never implemented correctly and simply isn't worth the major performance drop.  You can run a direct-to-computer video (such as YouTube) and Inworldz at the same time with far less drag on your system resources.

    In most cases, turn off "auto loading" of both video and music.  Switch them to manual so they're not being triggered every time you cross a parcel line.

ADDITIONAL TWEAKS.   The following changes may assist greatly in handling texture tracking and other lag issues:

Preferences->Graphics->Hardware Settings
Turn off the option Enable Streamed VBOs

Advanced / Debug Settings / XferThrottle
Change from 15000 to 1500.

Advanced / Debug Settings  
FSDestroyGLTexturesImmediately = TRUE

    Don't be afraid to tweak graphics settings.  You can always reset them to default if necessary.   But if you are crashing regularly, the system being stable or unstable may depend on one setting you haven't yet tried adjusting.  So take the plunge:  try setting your overall settings to medium instead of high, try setting terrain detail and sky to low, try turning off clouds entirely.  If it helps, it helps.  Don't be afraid to try something you haven't tried yet.  It may be just the trick.


So these are areas in which you may significantly reduce poor performance and crashing issues.  As I hear of more, I'll add them to this blog. : )


Views: 417

Comment by Wayfinder Wishbringer on June 14, 2012 at 3:41am

It's true the faster your CPU and motherboard bus and RAM the faster your system will work overall.  That goes without saying.  However, be assured a 6600 Quad and GTS 450 card is more than sufficient to run Inworldz / SL.  That's exactly what I use and I can honestly say I hardly ever lag.  In truth I often experience no lag at all when others around me are talking about lagging.  On the rare occasions I do "lag" it's when lag would be expected (multiple avatars teleporting in, when I first teleport to a sim and textures are loading by the thousands, etc).

The trick to this is that there's only so fast the servers can process bad code (of which there is still plenty and Tranq and adventurers are working furiously daily to overcome, GO GUYS! YAAAY!)... and there's only so fast they can send information across the Internet.  As an example:  My cable Inet works at 10mbps, yet the highest I can ramp my bandwidth from Inworldz is about 1500 (more than that and packets start dropping like flies on moonshine).  Is that my system?  No, because I can use Inworldz, watch Netflix, retrieve email, use Photoshop and play solitaire all at once and my system not even work up a sweat.  That's what's nice about quad-core and a good graphics card.  It's simply limitations of current VR code structure-- structure that was inherited from SL viewers and OS code (neither of which were well-written).  So Inworldz is stuck with the unfortunate job of "fix other people's mistakes"... and we're stuck with being patient and rooting them on. : )

I will say that at least for me, Inworldz runs far, far better than SL.   My computer is less stressed out (oh wait, that's ME)... and I'm having far more fun. : )

Comment by Minethere Always on August 13, 2012 at 7:52am

xayesha has opened a new thread on similar things...tho, already, some are adding misinformation and incomplete information http://inworldz.com/forums/viewtopic.php?f=4&t=13095

Comment by eekee eebus on August 15, 2012 at 11:30am

The discussion of ping times (aka latency) in that thread is good. Constanza's test results in particular are very interesting, they support my long-time hunch that an expensive high-bandwidth connection may be a very poor choice for these virtual worlds.

Comment by Wayfinder Wishbringer on August 15, 2012 at 1:45pm

I'm not sure it's so much the high-bandwidth connection as it is the bandwidth settings.  I have a 10mBps connection and do fine; I just have to adjust my viewer to throttle that quite a bit.  I think Zauber is probably the real pro when it comes to understanding how bandwidth works in these things.

But in principle Cyall yes, I agree.  High bandwidth (above a certain level anyway) really isn't necessary.  It's somewhat like graphics memory.  I was going to get a 2meg graphics card but was clued in there's no need to do so; the VR worlds can't take advantage of it. 

Same goes for multi-CPU computers.   From what I understand the VR software cannot take advantage of say, an 8-core processor.  The only reason for having more than a single core is so one can run other programs at the same time.  That's why even a single-core netbook can host an Opensim region efficiently.  The software isn't coded to take advantage of additional power.  (At least that was the case a year or two ago.  I don't know how much things have changed in that time.)

Comment by eekee eebus on August 15, 2012 at 5:02pm

You're right about CPUs as far as the viewer goes. I just redid a little test which I first did 4.5 years ago when I first got my quad core: watch a per-core cpu monitor while walking around. ;) The results were much the same: 3 cores are used when idling and 4 when walking around. There is a little difference now, walking with very little visible won't use the 4th core noticeably, and standing looking diagonally across Ardhon en Ceredir is keeping that 4th core at 50-66%, I think because of all the flexy tree leaves and my high draw distance.


On the flip side, I evidently wasn't clear about bandwidth. Some very high bandwidth connections actually have attrociously bad latency (ping times). As Balpien explained in rather technical terms in the forum thread, LLUDP is a protocol which is limited really badly by latency. What it does is send one packet, wait for acknowledgement, send the next, wait for acknowledgement, completely in series. If the packets take a long time to get there and the acknowledgements take a long time to get back, the overall speed is severely limited. In fact, someone did a little math a couple of years ago and found that the speed of light alone is enough to cap the bandwitch of such a protocol. Consider that 4kilobytes (32kilobits) is large for a packet, add in all the routers and gateways along the internet, and I think someone said copper wire carries signals at a third of the speed of light, and it's a miracle our inventories ever load! :D Inworldz doesn't stick strictly to the protocol, it sends 3 packets at once to aleviate the problem, but it's only 3 at once, it's not the full pipelining we really need.


I've got an ADSL connection of maybe 10Mbps (I forget the details), and I got 160ms ping time to a server in San Diego when I tested with speedtest.net. I'm in central England. Constanza Amsterdam who is no more than 10% further away from San Diego than I am and who has a whopping 60Mbps fibre-optic connection, and her ping time is 346ms, more than double mine! I don't remember any details but I'm sure I've seen this before; the very fastest home internet connections you can buy can be burdened with unreasonably high latency when compared to ordinary service.

Comment by Minethere Always on August 15, 2012 at 5:15pm

as well, arkady has a very low bandwidth..i think he said 1 mgbt...he has thoughts on the matter...unsure why he hasnt added to that thread...but them i aint keeping a very close eye on it..lol

i recall the days when it was difficult to run much software due to pc limitations...that has reversed for the most part now...as well, i recall the days when there was much worry about internet bottlenecks

always interesting this particular blog...smiles [u peeps are sooo smart!!]

Comment by Wayfinder Wishbringer on August 15, 2012 at 10:54pm

Ah yeah Cyall, I understand what you mean about bandwidth now.  It's kind of like digging a rose garden with a backhoe; sometimes less is better. 

I have wondered for years why LL ever chose UDP (very fast but lossy unless one configures it very, very well)... in an environment where lossy cannot be tolerated.  No wonder we lost inventory and textures didn't load.  Add that to an extremely bad cache system... and like you said it's a wonder it ran at all.  (Come to think of it, quite often it didn't.)

I've heard that after they get PhysX working Tranq is planning on diving into deep-core once again to try to update some of the inner workings.  The problem that we've all discovered is that the viewers are as much to blame for bad performance as the server software (which makes sense; they're half the process and the viewer software was initially coded by LL).   I currently consider viewers to be the "Achilles Heel" of VR (including Inworldz).  That's not going to change until Inworldz gets their official viewer as streamlined as their server software.  For example, no amount of tweaking server side is going to improve viewer texture rendering; the protocol and cache viewer-side must be fixed.  Only when both sides of the coin are polished will the whole thing be shiny.

Comment by Minethere Always on August 16, 2012 at 4:28am

well..i just cant stop myself from sayin'...[grr] 'get physX working'...well..uh...from what i have seen, every grid update seems to require more fixes...we are supposed to be getting one soon, soooo

then, physx, whenever it drops down, will likely need fixing as well...all im sayin is...i wouldnt hold my breath...lol

is this a reality check, or am i just a naysayer?? i dunno, i need more coffee still........

Comment by Wayfinder Wishbringer on August 16, 2012 at 10:28am

That's how it seems sometimes.  Along with existing code bugs (of which there are thousands-- not a one of which Inworldz is responsible for)... every fix brings its own bugs (it's very difficult if not impossible to foresee all issues).  Coding is a process of release, debug, release, debug until the major bugs are found and fixed.  In all my life I've known only one coder who could write flawless code first pass.  He was a mutant.

PhysX will likely bring with it its own problems.  But at the same time, IW is getting ready to release a new update that fixes over 200 significant bugs.  That's quite a bit of progress.  One major difference is that whenever IW announces an upcoming release, I look forward to it.  On SL upcoming releases were like a knell of doom and everyone dreaded it, because we knew those releases had not been properly tested before release and likely weren't what we wanted/needed in the first place.  Comparatively, Inworldz rocks. : )

But no, I never recommend holding one's breath for too lengthy a period.  It results in passing out prior to seeing the awesome new releases.  : )

Comment by eekee eebus on August 31, 2012 at 12:39am

> as well, arkady has a very low bandwidth..i think he said 1 mgbt
I remember the days when a quarter that was enough and a few people just-about managed with dial-up. :-J The first quad dragon avatar I ever saw was made and worn by someone on dial-up. That was before the UDP junk, I'm sure, it was before texture and prim loading became lossy and slow in one of the early 1.8 versions.

>It's kind of like digging a rose garden with a backhoe; sometimes less is better.

Still nope, sorry. :D It's more like buying a super-fast car that has to slow down to a crawl to get around any corner; perhaps a hot rod in the "pro street" category of more than 20 years ago. Pro street cars are street-legal dragsters and the front tyres are as narrow as is practical, in the 1980s and earlier that meant barely 3 inches wide. Newer pro street cars are better in that area or I would have linked pictures, for example this linked car has much wider front tyres than they had then! Extending the illustration, LLUDP is like a very twisty road where HTTP only has one bend at the beginning and then it's all straight. Some very expensive very fast internet connections are just like those pro street cars. A cheap internet connection can still be bad in that way, or it could be good like a cheap but sporty compact car; a Volkswagen Golf (Rabbit) GTi, perhaps.

> I have wondered for years why LL ever chose UDP

It's bad, but to be fair they are far from the only company to do this. I don't know details, Bavarin Fleetwood told me the other day, but it's quite typical of the insanity prevalent in computing today, where "bright" ideas get popular when they are in fact worthless, and any serious consideration of the issues is likely to be met with mockery or simply overriden by the sheer number of people in love with the "bright" stupidity. Wayfinder, if I were you I'd be very glad to have retired from the computing industry already.
 I don't want to elaborate this, it really does upset me.

On the other hand some features are just difficult even when they are necessary, such as caching. To quote one of the brightest minds in computing today, "There is no such thing as a simple cache bug."

As for PhysX, the physics engine is (or was) tied in with some surprisingly deep parts of the simulator, so I'm not surprised Tranq is planning to go (or has gone, by now) there in the implimentation. I think we'll see a lot of unexpected improvements alongside PhysX. That said, we might not.

I'd like to write about bugs; for all the testing there is always a chance a truly spectacular bug will slip through all testing. Living on Ardhon en Ceredir perhaps makes me more aware of this than most, it's a main-grid beta-test sim. 10 days ago the major functions of the sim locked up; I could neither move nor receive most updates. I could log in, log out, and teleport just fine, which must be the new sim-crossing code which was being tested, so that's something good right there, but we can't have main-grid sims freezing up. :) It is always possible something will slip through even the main-grid-beta net. That one update had been running for a week in Ardhon and was due to be rolled out that day. It was held up for two days to fix that freeze, but imagine if the sim had received less use, perhaps I or another resident of Ardhon had been away, the rollout proceeded as planned without the freeze being discovered, and all the sims with busy clubs started freezing up in much less than a week! Or even IDI... Living in Ardhon is fun but that was a close call. :)

I'd like to talk about Aurora-sim too. I set up a tiny grid of my own with that in the last week. Before I talk about it I should talk about my router, it's a peculiar little thing. You know how you need a loopback-capable router to access your own OpenSim sims at home if they're open to other people connecting at all, and some routers are not capable of loopback? Well my router is perfectly fine for normal internet use, but when asked to loop back it turns into one of those old pro street dragsters. In loopback its latency makes it seem as if the server is on another continent and then some. It's also capable of dropping the occasional packet.. in loopback! I didn't notice until I started using Minecraft which has a little link quality display in the server list. This problem was noticeable when I had a little OpenSim grid. With the grid based on Aurora-sim instead, it is not noticeable at all! Aurora is _far_ faster, it's almost unreal. I can build and move quicker in Aurora with a loopback connection than I can in Minecraft with its simple blocks. It's vastly smoother than any OpenSim. It's not bug-free, but I won't talk about that since it's turned out I'm running a fairly old version. I'll try to blog about it in a few weeks.

Finally, as if I needed to wander even further off topic, I've noticed Minecraft, as simple as it is, is an even less stable build platform than the worst of what we use. Twice now I've got a little base going that I'm really happy with and both times the server has corrupted its database in such a way as to make itself crash every time it tries to start up. Supposedly the problem can be fixed with MCEdit, but using MCEdit even for something as trivial as moving the position you log in at can result in bizzarre artefacts like waterfalls coming out of nowhere in the sky and all the contents of your chests; all the materials you've gathered, being removed; gone. Worse, forget about updates merely introducing bugs, you can lose access to your entire map, whether through the game refusing to load it or actually wiping out everything you did in it. It's easy to upgrade and very difficult to downgrade, and you must have the same version as any server you want to connect to. It's not obvious how to back up your game properly. Oh you can back up the map easily enough, but then on restore you can find yourself loggin in 100m in the air where the only thing you can do is fall to your death, unless you backed up something else entirely and it's not obvious what.


You need to be a member of Elf Clan Social Network to add comments!

Join Elf Clan Social Network

© 2017   Created by Wayfinder Wishbringer.   Powered by

Report an Issue  |  Terms of Service