SecondLife's list of DOs & DON'Ts reguarding 'lag'

This is where I end up on the horns of a dilemma.

I have a RAID of 2 36mb 10,000rpm Raptors as my C: drive. I run 3GB of PC4200 ram on my ASUS motherboard and have windows virtual memory turned off entirely. Also it's a P4 dual core running at 3.0gHz and video is provided by a ATI x800 XT PCI-E card.

So, given my C: drive set up (RAID-y Raptors) and that my other two HD's are big-ish 250mb and 300mb 7,200 rpm drives, would you:

a) install SL to the C: drive because it's a LOT faster than the other two drives and oh well the OS runs on that drive too or
b) install SL to the slower drive options just to get it away from the OS drive

And, don't tell me to un-RAID and reinstall Windows on one 36gb Raptor and run SL on the other 36gb Raptor. I'd like to do that if I'd thought of it in the first place, lol, but I'm not diving into a complete OS rebuild here if I can help it.

I only post this on this thread for the (hopeful) benifit of others who've read that it's best to install apps on a seperate drive from OS but who's OS drive is much better than the other drives they have installed. Also, I was only reading this thread because in spite of having a reasonably powerful machine I am usually in the 5-10fps range. /sigh/

Well Kari Niven, sounds like you have a great system.. surprised you are suffering lag, but as you are...

The one part that concerned me slightly is when you say you have turned off the OS cache! The sole purpose of which is to remove from memory any programmes that you are running, but who's services aren't required at that time. Effectively, you are trying to squeeze both the OS kernel and the SL client into 3gb. 3gb sounds a lot, but then when I began in computers, we thought 64kb was a lot of memory My advice, turn it back on but switch the settings to one of the drives that SL isn't installed, assuming you have XP, I know that possible relatively easy (sorry Linux and Mac users I dont have your answer). Something else you might like to try, turn on Indexing for your drives, so it builds up a fast index file which is quicker than any FAT or similar system. Oh and while your at it, run scandisc on your boot drive once a month, it clears any errors in the file tables and MBR (Master Boot Records), check the Auto fix errors and scan for bad sectors.

Come again? I don`t to me a smart rabbit but ..............AAAAAAAAAAA?

Can you be more specific about what perplexed you?

If you have set everything and carried out the regular checks I have suggested, and your SL client still lags (its rarely going to remain perfect due to the very nature of the Internet), then.. you can consider it might be your ISP... you have narrowed it down to that factor and not simply keep looking at SL as being the problem.

In the main we employ the services if an ISP to connect us to the internet on the basis of cost verses bandwidth. What is overlooked and rarely posted by the ISP suppliers, are things like Contention Ratio's. So you have your nice new shiny 5gb bandwidth connection and it only costs 5$ per month! Well you don't get something for nothing, not in SL or RL. What you have probably signed up for is to Share that 5gb bandwidth with half a continent. 'Usual' contention ratios here in the UK are 50:1 for private/public use and 20:1 for company installations (although there are variations). The math is simple, users divided into the bandwidth advertised, in reality you can halve that again because little Johnny around the corner is downloading his favourtite music MP3's and is using more of the bandwidth than you (they don't monitor or throttle individual connections, its almost a first come first served service). Johnny's downloads only start to slow down as the demand becomes greater.
You can of course obtain a static IP connection (most are dynamic assigned by your ISP) from specialist providers, at a cost!

Don't listen to the marketdroids. You won't notice a difference between running SL from either drive. But since Windows (which you really shouldn't be using, given its suckitude, but that's neither here nor there) comparatively rarely hits the hard drive for code once things are running, it should be no problem running them on your RAIDed drive.

shakedhead......never mind

Oh well guess you have never tried it.... The difference won't be like the WOW... just by doing this. However, if SL and the OS reside on the same disc, when the API makes calls to the OS to do something, it has to share not just the CPU cycles, but also the Disc cache and the single IDE channel controller. 2 Hard discs on seperate IDE channels/controllers can continue to work independently. Another thing to consider is the Caches, both of which are dynamic and constantly changing, both using so called free disc space, subsequently both fragmenting eachother.

If you also have other things running while you have SL running - things that are actively doing something and not just sitting idle - then what you say is probably true, especially if you have an older system.

If the rest of your machine is pretty much idle while you're in SL and/or if you have new hardware, I'm not sure it will make much difference. Like, if you have SATA-2 and your system is mostly idle except for SL, I wouldn't bother moving it to a separate disk.

If you're "low" in memory, like 1GB or less, and have an extra disk in your case, you would probably get a better LS performance boost by splitting up your paging files across multiple disks.


Not sure I buy that part..

My last post in this thread...
No OS is ever idle, the API calls made by any programme make sure of that, also consider any adware, virus checkers, software firewalls etc that constantly run. Most of which live on the same hard disc as the OS and make their own OS calls. I didn't make this post on one single assumption, I offered a range of things combined, all of which, in their own small way, build towards making things more bearable. I was simply replying to the single question made.

Have a great one...

You may want to Optimize your Computer for faster performance first.

A really nice utility is DiskSaver. It defrags your harddrive and optimizes it... everytime you hear noise from your computer (with the exception of fans and the optical drive( its your harddrive. your harddrive has to search, write, and read all the time for Second Life.
I've found using this utility, increases performance by 15 percent.. well, at least on my system.. Its free, give it a shot...

you can get it at http://remotepclabs.com click on Software and its the first program listed.

Uhm, sorry for being too lazy to wade through all five pages. (I'm a terrible person, I know.)

Anyway, not sure if this has been said before, but one easy way to tell is to hit ctrl+alt+1, and then look at that little box that opens up in the top right. You'll find a number of different numbers, but probably the most important two are your frames per second, FPS, and the sim/server time dialation. If the first number is low (60FPS is considered ideal but is hardly ever reached ~ 10-20FPS seems more common on SL) then it's because your computer can't keep up with everything that's going on (I.E. tori / prim / texture lag,) and it's called Client-Side lag. Time dialation's ideal number is 1.00 , and usually hovers around that. When this number dips, it's because the server's going under a lot of strain and can't keep up, usually because of things like script perforation and lots of avatars. If Time dialation dips to levels below .1, you can expect everything to work as though the air's turned to cold syrup. If it reaches .001, be prepared for a sim crash.

My solution is simple...

Spend some of the millions of dollars you bring in over the coarse of a month and
hire a professional networking staff out of Japan to fix your miserable database.
99.9999999% of our problems are with LL database and server system, data requests etc. Dont try to confuse the issue.

Ive lost several corporate clients who sent representatives into Second Life to tour the potentials of this platform. The instability, and consistent lag spikes render it in opperable for any business considerations from their experiences.

Have you been to welcome island.. Have you seen how the FIRST impression is
to any SERIOUS corporate sponsor comming to view this platform and its OVER hyped possibilites?? Many quite and never return before even leaving the island.

We all know this is in fact not necessarily true under a functioning and smoothly operating database. The potentials here have been written and spoken of since the inception prior to 2003.

No matter what the cost, I would think that with all the bankers and investors involved in the Second Life Platform that wether it costs a million or a billion dollars the proof is in the final result.

Spend what is needed and just make it work.

The web as we know it would not function the way it does if all the website servers that make up the world wide web were located in one central location.
You cannot continue to run this platform if you house all this in one closet sort to speak.

Linden Labs needs to allow private servers (fee based) to host their regions and then data linked to the main grid. However this is done.. Or if it can be done.

The entire world of second life will never work efficiently under the current blueprint. Technology wont allow this many data requests from a centralized
point of return with any ammount of speed. Forgiving of coarse that the programming itself that runs the database is faulty.

I remember back in 2004-2005 how wonderful things ran with sub-quality equipment in those days. Growth is inevitable. I would hope that before one of these secondary platforms pops up that Linden Labs can find the solution needed to save what they originally started. I know of 2 known grids in development as we speak that are looking to bring SL avatars free to the NEW world once they get up and running. Boasting the same type of 3d modeling design abilities and configurations that clone the second life world of operation. Your going to lose it all if you dont just fix it or solve the issues that have plagued this system for the past year.

At one time I was laughed at for the suggestions of this platform to businesses in the ways it can open new doors of marketing and operation on a corporate level.

Now.. Im laughed at because if its lack of just... running period.

Fix it. Expense should be no cosideration.

/rant off

I guess the data server in Dallas along side the one in San Francisco is just a figment of our imagination. The move to Amazon servers for client downloads is a waste of time too. Man, you need to update yourself as to what is actually being done with SL. Also, keep in mind most of these "business" people are logging into SL in their bottom of the barrel, 4 year old Dell or Compac "business" grade computers with integrated video or craptacular video cards , 256 system memory and skinny internet pipes.

With my dual core cpu, 2 gigs of memory. Nvidia 6800Ultra and a fat 4000kbps internet pipe, SL doesn't lag nearly so much. No one expects Oblivion or Doom3 to run well on a business system but every day people complain about SL not working well on their Wal Mart special Emachine. Once you have a machine that can handle everything SL throws at your computer and your pipe is big enough to handle the load then lag tends to only be server side and server side lag is usually due to a gazillion avatars in one sim. I can routinely get 15 fps in a sim with 40 avatars though and 50+ in a moderately built up sim with a couple of avatars with the First Look viewer and all the visual goodies turned up to max.

SL has it's faults but you have to recognize you have to have your own house in order before laying all the blame on LL.

Well said, and I do know about the other servers locations. I was not aware that they were patched and operating segments of the grid currently.
Good, a step in the right direction.

However..

Today alone.. my minimap went RED 4 times. This indicates a Sim crash/ Server crash. I highly doubt it had anything to do with my comcast connection pipeline.

Im also well aware of what is serverside and what is clientside.

I run Second Life on various machines.. The one I use most (for convenience) which I built myself is a AMD 900MHZ running 100mhz FSB with 1 gig of SD RAM. The only component worth mentioning that makes SL work is really the AGP 256 Card. SO I too know what to expect from different workstation setups. There
is little performance changes inworld wether im on my 900mhz or my duel core
using the same settings. I cant tell you the ammount of times ive sat and calcualted FPS, Packet Loss statistics with all 4 of my machines to analyize and pinpoint specific values of adjustment.. its serverside issues 95% of the time.

The other 5% is as you stated.. walmart computers with onboard graphics using
a celeron processor while having graphical SL settings up unreasonably high for that particular production line home computer.

Now dont tell me i dont know the difference.. I surely do. Ive been an avid gammer for over 8 years in all the FPS and MMORPG titles. I run SL with nearly all my settings on max minus the draw distance which is set for 80m.

A vast majority of my time on my land it runs well enough for me to do the business work I do for other clients abroad. The lag spikes which occur approximately every 10-20 minutes and last from anywhere around 2 minutes to 18 minutes are not on my end because my avatar sits at the same location in his office staring at the same 4 walls throughout most of the session time.

I agree with you there are extenuating circumstances that cause some negative experiences due to Client Side computers... but most of the time.. to nearly all of the time it isnt you.. (over 95% lets say) unless your on dialup.

Devin.

And how many of those crashes are due to flaws in the system or griefers bringing them down? I spend a fair amount of time in Furnation and I would guess 85% of all sim crashes are due to griefers and noobs.





There is something definitely wrong somewhere if your dual core runs no better than a 900 AMD. I get 20 - 30 fps difference between my 2500+ AMD Nvidia 6600 1 gig and my 4400+ AMD 2 gig using the same 6600 card. With the 6800 Ultra I can run up AA and AF to max with little loss in fps compared to the 6600. The 900 is on the nearly won't run SL list and my 1800+ AMD is slow and laggy itself. YMMV I guess.



Ummm, if your avatar is sitting and not moving and you are experiencing lag how can that be server side? I don't understand, I can disconnect from the internet and sit in one spot for hours, spin around in all directions with no lag what so ever. We've all used animations when the connection drops and not know for a long time since it appears to be working fine until you try to move. I always thought if you lagged while not moving to be a client side issue since the server only comes into play when the avatar moves across the landscape since the avatar, animations etc are client-side. However, I will concede to your extensive experience.

Servers are constantly streaming data to your connection.. wether your moving or not. you know this dont mix the facts of operation.

Ill give you example:


Put yourself into an enclosed box where you see nothing but the walls you are behind. place a nice cozy chair and sit. watch your fps meter, packet loss meter. ahh this is nice isnt it, well peaceful and serene. take note over the next 10 minutes of the various data set numbers while you sit in your own personal paradise. Ahh yes they do fluctuate a bit but not greatly perhaps...

Lets pack up our box... head over to a more populated area.. and quietly reposition or little peice of paradise.. Interesting isnt it.. we are neither viewing new scenes nor making any movements whatsoever but yet our numbers are drastically changed. Yes yes.. your right.. its the sim.. the darn thing! lets just sit and enjoy our darkness and watch numbers for a spell.. Ok enough of that.. come troops lets pack it up!

Now we find ourselves a entirely new sim.. lets choose a nice category 5 server this time. A newer sim less developed! Go ahead and set your box. so comfy, so serene, so cozy. Now dont move... we sit and watch what is going on. ahh better numbers i see. After 10 minutes certainly you will see large JUMPS in the data.
But wait.. we didnt move.. didnt cause the server to redraw anything? what is this? why is it happening?

Our next test would be sending a chat messsage to a friend. now this cant really be tested exactly as i state it but you all know what im saying cuz its happend to ALL of us many times over the past 2 months...

Send a message and there is a lag delay of 10-15-20 seconds before it shows up in the client. now we havent moved.. havent changed anything (according to your account.. sitting still doesnt require any streaming from linden labs) NOT TRUE!

Even while you sit in your box.. although you are not seeing outside animations or lighting or movements or redraw.. it is there.. and the server is CONSTANTLY feeding this from their network. The only lag you speak of my friend is what is being handled by your Graphics card. And that surely isnt the case in point we are trying to show here.

To take it a step further.. you can put your box in the sky... ahh yes the old 2004 remedy!! put your crap in the sky to reduce lag.

BS! The only thing that the atmosphere helps us with is draw distance objects which IS client side which IS our computers not linden labs.. but i note... even in the sky doing this test will result in the same torn performance comming from linden labs database serving system.

I know what my computers can and cant do.. I know what is on my end vs their end. And i can tell you without a doubt that on this subject and the problems we ALL have been having over the past 6 months is the degridation of the Linden Lab system being able to feed data to the masses.


This was of coarse all along my point. Linden Lab needs to find a solution which will feed the world better wether it be HUNDREDS of private servers linked to a database or partioning the grid into several regions abroad. I do not know the answer and what will work .. but i stand firm that 1,2,3 segments of THE GRID placed in OHIO, CALIFORNIA, TEXAS (wherever) isnt enough to break the work up in the pipeline. NOR is it a fix for the root of the problem.. the DATABASE program itself.

Nuff Said On That..
Just know people.. its not your walmart computer... not 95% of the time.

I return this thread to more productive discussion and assistance.. point proven.

The funny part about this thread is you are both right!

The very dynamics of the internet, coupled with the fact that everyone using the internet and or servers linked or unlinked to SL, its all shared! Just the same as your connection. Contention ratios aren't just about your own telephone line back to the ISP servers, it's the whole thing.
LL's servers are all shared, irrespective of whether your system is top of the range, or bare minimum specs. The only real effect is the Client Machine being able to render the information given to it faster than the next guys/gals. Server cpu cycles are shared on a first come, first served basis, your only drawback is if you suffer packet loss during the ardious journey between your PC and the intended destination and back. Loose a packet and you are back of the queue.

It is true, that if the database servers and sim servers at LL are overloaded your precious data packet will not even reach the queue to begin with, thats irrespective of your connection speed.

I started my VR experiences with Adobe Atmosphere back in 2001, which was developed for the sole purposes of business environment. It was the 3D version of net meeting whereby companies could not only hold conferencing across the globe, but had the opportunity to 'showcase' demonstrations of VR work. The creations of actual buildings and being able to 'fly' around them in real time, giving a 'true' persective of size and space, long before any hard decisions would be finalised and comitted to paper/construction teams was very real. The creation of museums, holiday destinations, theme parks, art gallieries etc now at the finger tips of VR artists.
The very nature of the programme allowed private hosting away from the Adobe servers of your own 'worlds' (islands and sims in SL), was encouraged.

SL is but a next generation of that concept, with only the limitation of no 'off world' worlds. Although I suspect with the forth coming open source server code, it will make that leap very gracefully. The security of the system is the major element preventing that at this time, although I believe LL are working on ways of overcoming that. This has a huge potential of reducing greatly the overheads and limitations of the SL architecture. Atmosphere sloped away into the darkness (although still there supported by some very enthusiastic users), simply because it did not take the next logical step of ingame commerce and trade through a comon currency. SL was built from the ground up with that at its core and will therefore thrive. The growth path will remain 'painful' for some until certain key milestones are reached and surpassed.. I can't wait for the open source server code release.

ClientSide: This is when your computer (yes yours, this is totally your fault! ) is unable to process and render the information provided by the server faster then 25FPS, (your eyes have a refresh rate of 25FPS, I think) so you see visible slowdown and choppyness on your screen. What causes your computer to 'lag': too many textures to render at once and too many polygones to render at once (ground, avatars, objects).

hello you told 25 fps is smooth for watching sl but that is for a movie.
building up a computer screen for a game is different and must be 45 fps or more to see nice.

An important distinction here is prim count versus flexi prim count.

High prim count affects both server and client side performance. This is especially true for the server if, like many hairs, the hair is also "physical" in the sense that it has a touch handler. (Turn on "View -> Alt Shows Physical", and see if the hair is highlighted.

However, if the prims are also flexi, this adds significantly to client side processing, because the client must recalculate each flexi prim in much greater detail, and factor in things like wind, momentum, and stiffness. (I believe this is not calculated server side, please let me know if I'm wrong!)

Bingo. Clubs that restrict simple jewelry bling don't understand how particle systems work. Most bling is relatively lightweight on the client, and doesn't affect the server much at all. Flexi hair with hundreds of prims is a far bigger drain. Necklaces with tiny links also probably cause more lag than jewelry bling.

Not that I'm all that big a fan of excessive bling.

I bet it's fiction. In fact, 'full bright' allows the client to SKIP processing: it doesn't have to shade the object based on ambient light sources. My guess is, if all objects were full bright, you'd see less lag. You'd go blind, but that's another issue.

Note that script lag and frame rate are somewhat unrelated. Also, script lag is entierly server-side, since that's where the scripts run. Networking latencies are inconsequential, although massive frame loss can undermine things.

Here's how I understand it, from scrutinizing the stats windows. IIt's an oversimplification, and some details may be inaccurate, but the overall picture would still be valid.

The server tries to run at its optimal frame rate (45 FPS, IIRC) to model the 3D world. If the world is simple, it finishes this way ahead of 1/45 of a second, and all the leftover time is given to scripts.

If the server can't quite keep up with that frame rate, it sets aside a minimum fraction of time for scripts, and uses the rest for modelling. The frame rate is whatever it can manage, and scripts get less time than they would in a simpler world.

This is the only interaction between server lag and script lag: a complex world can increase script lag.

Script lag (i.e., touching an object and waiting before it responds) does NOT cause modelling lag. You can have a huge number of the worst possible scripts running, and this will not cause the frame rate to decrease. However, modelling lag can exacerbate script lag. In any fairly busy sim, though, the scripts only get their minimum guaranteed time fraction, so once you begin to get a LITTLE modelling lag, it won't affect scripts if it gets even worse.

And there's one other kind of lag I didn't see mentioned above: chat lag. I suspect that chat lag is related to script lag more than modelling lag, but it could be none of the above.

This has been very interesting and informative thread to read, especially for a beginning builder like myself.

I still got few questons I don't think were mentioned. Mostly concerning so called graphical lag.

Which is better, to have bigger texture if you need texture for a big prim, than smaller one that you then need to use on that prim multiple times? Just thinking about old time internet-sites, that could have these "wallpapers" on them, and at least on my connection and computer at that time the smaller ones which were there multiple times took much more time to load than the big ones (even though the big ones took their time too, of course). I know this is kind of tricky though, might be so that the more cache space you have, the small ones would be better, but if your cache is small, then they'd have to be loaded multiple times from the server?

Also, about prims. Would it be better to build something from multiple prims that are simpler, than to use only one prim that could do the job on its own? Like cylinder vs. torus, for example.

The use of smaller textures used many times is far better, than a large texture, even used once, in that the smaller texture loads quicker and is 'applied' many times direct from your cache. The use of multiple prims question is one of mathematics and data packets. If you use a single prim, the actual data sent to each client is relative to each X,Y,Z coordinate of each facet of the prim (square having basically 4 corners), spheres are more complex in nature as they are not true spheres, but made up of many facets requiring many more coordinates to send data on to the client to render. However the majority of GC's are capable of rendering these basic prims (prims being short for primitives).
For instance someone dropped me a 'device' ingame that effected my FPS, when I checked this very small device was made from over 700 prims! The GC was having to content with rendering this many prims even before applying any textures (hence why hair texture is the last thing to load after the prolification of prims).
Each Avatar is also made from basic prims, each with its own set of coordinates. So your data stream has to content with not just static prims, but actual animations of those linked prims. VR games across the internet could not function without the use of prims, and GC manufactures have been battling to create pipelines to manlipulate these over the years, then add further pipelines to show rendered textured surfaces, combined with eyecandy such as shadows, reflective surfaces, fog/mist, hair strands, mirrors, water movements etc.

When I began creating VR worlds and avatars around 7 years ago, we only had dialup, very limited GC's, RAM etc... but with careful planning, we could still create stunning worlds and avatars. Todays bloatware exceeds the capabilities of most setups and will continue to ramp up the ever growing costs of the end user, until creators/designers become smarter. The current limitation will be the Internet itself, although many connections are much faster and have greater bandwidth, the bottle neck will be contention ratio's. Having a 8mb connection does not mean you have a potentially faster connection, when the contention ratio is 1:50, it just means that at times, you may have a faster connection.