LAG: Windows vs Mac vs Linux

We were discussing lag issues in another forum... and the idea hit me to throw this out there for discussion:

How much does Micro$oft Windows itself lag Second Life?

I know that SL lags under Windows. Does it equally lag under Mac? Under Linux?

Does anyone out there use SL on multiple OS, similarly-configured computers?

For example, I would love to see SL tested on a Windows system and Linux system, identically configured, at the same place and same time... to see if one runs more smoothly than the other. Would also like to see a commonly-configured Mac take the same test... and see what the results are.

The hypothesis is that Windows is becoming so glutted and such a resource-pig that it's taking significant speed away from the applications themselves. I use Windows myself, but I know what Windows should have been-- and what it isn't. I am not it's biggest fan.

I have tested the Windows and Linux versions of SL on two of my dual-boot computers. In both cases, the performance of both versions was comparable, except for the missing features in the Linux version (no streaming music or video). I have also heard from people with Boot Camp installed on their Intel-based Macs that they have gotten similar performance from the Mac OS X and Windows versions of SL.

Bottom line: if you have enough memory in your box (1GB or more), I doubt that the OS makes much difference. If you're running SL on a machine with low memory, it might have a larger impact, because the different operating systems have different virtual memory implementations which could affect SL performance. I have used the Windows and Mac OS versions on (different) limited-memory systems, and they behave very differently; Windows gradually slows down and you get continuous hard disk activity; Mac OS seems to mostly run normally, but then the client will COMPLETELY freeze for a second or two at a time once in a while (and if you listen closely, you can hear the hard disk madly thrashing).

This gives me the giggles and makes me mad both at the same time... it is so silly the stupid things that people say about Windows, especially when comparing it to something as back-yard as Linux.

Let me look for the threads....

In the Mac windows Bootcamp thread, Loki Elliot found that SL ran 20 FPS faster under Windows versus OS X on a MacBook with 2 GB RAM. This is the low end notebook with Intel Integrated Graphics. In contrast, PetGirl Bergman found no difference on a high-end MacBook Pro, also with 2 GB RAM. Main difference between these machines? The high-end Pro has ATI graphics with 256 MB VRAM. And this is 10-12 FPS better than her G5. FWIW, I saw little difference as well on my lower-end MacBook Pro with 128MB VRAM.

There are more comparisons at that thread and the following: WOW! SL under Win XP on the Core Duo iMac

Some see a difference, some don't. It's going to be hard to pin down exactly why. LL's Intel code is definitely faster than the PPC code. Other differences, where they exist, might be accounted for by driver issues.

I don't have enough information to make any conclusions, but this is a start. I don't know if anyone's gotten Linux running on the new Intel Macs -- then you could compare all three versions on identical systems, because it would all be the same system -- a Mac.

Well, I have no desire to get into a Windows vs Linux debate; that's been done to death elsewhere and by folks with far more expertise than I. But IMHO, Windows is a user-unfriendly, memory-hungry, security-issue prone, glutted operating system that's put together like a patch-quilt. The fact that it's priced about 5 times higher than it has any need to be just adds to the problem. I have no choice but to use it, but like many, many people, am not pleased with its operation and obscure functions.

I attended an official Micro$oft conference once and the official representative of the company admitted that they were aware that the price of Windows was above the reasonable pocketbook of the average computer user and were considering options to that (such as charging a $30 a year license fee per computer). Yet, a brand new copy of Windows Home still costs $195 and a copy of Professional costs $295 (standard retail). And Bill Gates is one of the (The?) richest men in the world.

Obligations to stockholders set aside (because stockholders will demand all they can get their greedly little hands on)... if Bill and Micro$oft wanted to become everyone's heros... they should drop the price of Windows Home to about $49.95. That would virtually eliminate piracy, because at that price it would be beneficial to have a legit copy of the thing. Micro$oft would earn a bundle from all the people who refuse to spend $100 to $200 for an OS, the end user would be happy, merchants would be happy... everybody benefits (maybe even the stockholders as sales of Windows increase).

OK, enough soapboxing and my humble opinions. Thanks for the feedback all. From what I understand thus far, SL operates about equally on Windows, Mac and Linux. If that remains the general consensus, then that allows us to rule out the OS as a significant lag factor.

it still mean "operate crappily" why aren't they taking some counseling from guys like ID software?

Well, the standard answer you'll get is that "SL doesn't operate like Quake and Unreal, it has ever-changing content, etc etc etc". Which is true in part... yet at the same time the operation of Quake and Unreal and other games is so near-perfect that-- like you said-- someone from SL should take note of what they're doing right. ;D

I've played Unreal Online with two dozen players and about double that many monsters coming at us, in full firefight and about a million things going on at once, with super-hi-resolution graphics and effects... with no lag. Put together differently and operating differently or not, static vs dynamic content or not, they do seem to have conquered the lag problem. In Unreal I never find myself rubber-banding back to where I was 10 seconds ago, I never find myself walking through syrup, I never have my chat appear long after I typed it, I never freeze and I never get booted offline. In short: their code is written well and steamlined and works, because they have some serious competition to deal with. They can't afford glitchy code. If they mess up, every gaming forum on the planet is going to announce that fact. So they keep it tight and lean and very impressive.

SL is a fascinating and unique community, but without a doubt the graphics functions need fixed, the caches and databases re-examined, and a lot of things gone over with a fine-tooth-comb to see where the problems lie. Once they kill the Lag Monster, they can concentrate on new toys that will make the system even more interesting.

Man, that reminds me of the many times I've heard "I'm not a racist, but [insert racist comment here]" =D

I run SL on three machines in my house (Me, my wife, and teenage kid all have accounts!). None of these machines is identically configured with any of the others, so I cannot provide any actually useful information, but...

The Kubuntu machine with 3GHz processor, ATI Radeon 9800, 1GB RAM, Raid-0 320GB SATA hard drive runs about the same as one of the WinXP laptops with 1GHz processor, 1GB RAM, some kind of nVidia card, and 80GB HD.

Both fall very far short in performance compared to my other WinXP laptop with dual-core 2Ghz processor, 2GB RAM, nVidia, and 200GB HD.

I see very little to indicate that by virtue of not being Windows that Linux would run with any less lag, and always think that such assumptions are ridiculous.

My Linux box runs well, and I'm happy to use it, but never do I find myself thinking that it's more performant than any of the other comparable machines I have in my home or my office networks.

This has nothing to do with "racism", which is an unreasonable and biggotted viewpoint without rational basis. My professional opinion of the Windows operating system is based on years of daily use and my experience both as a programmer, system designer and computer consultant.

Well, not being acquainted with what a "Kubuntu machine" is... what I read here is that you have three systems, at least 2 of which are running under Windows, two of them run about the same, but the dual core with double the RAM runs faster. That's not a surprising result. (However, I do have to question: a 3ghz machine running the same as a 1ghz machine? No offense, but difficult to believe).

There was no assumption. But why would such be ridiculous? Do you believe that all operating systems run the same?

Haven't you ever been curious? Have you ever tested to see? Myself, I'd run a benchmark program or run identical apps such as Open Office to see if the performance excels on one system. Then I'd know for sure. But again, running such three diverse systems, a 1ghz, 3ghz and a dual core-- doesn't really lend itself much to benchmarking, as the CPU and bus speed would be the major influence there, I would think.

I ask this because I'm not a Linux user (nor would I be considered a pro-Linux person, as I know very little about the OS, just as I know little about Mac OS). However, I've seen all kinds of posts on other forums from Linux users stating that Linux runs cleaner, faster, with less security issues and less headaches than Windows. So again, not to get into a Linux vs Windows debate-- but surely the question isn't that all off-the-wall. And surely people compare MacOSs to Windows every day of the week.

The primary question here is simple: Is the deep-core lag on Second Life at least in part attibutable to the OS being used? From other comments I've seen here, likely not. That eliminates one possibility-- which puts the ball right back in LL coding and system design court.

the only problems ive seen running SL on Windows machines, was when the users machine was having issues not related to SL... Wither a virus, major fragmentation, or tons of spyware...

other than that, Windows usually runs graphical game like programs better, because it has highly optimized drivers... Linux being barely used dosnt have as much resources thrown at it, so much of the hardware will run less efficiently.

a Kubuntu Machine would be a machine running Kubuntu Linux distro...


I havent tried SL on Linux since the client is beta anyways... but for OSX vs Windows, the client isnt much different. The only people that will find SL running faster on Windows than on OSX on their intel macs, are the ones with the Intel integrated graphics. The Windows driver is much better, and there are speed issues with the OSX driver currently.

* The client application always has all the same physics information as the servers. The entire simulated volume is loaded and compiled when you enter it, so the client's physics calculations can always precisely mirror the server's physics calculations.

SL could do this, by sealing each sim in an impenetrable box and only allowing you to pass from one sim to another by teleporting. When entering a sim you didn't have in cache you would remain "in teleport" until the entire sim had downloaded.

SL could definitely do a lot better, and they used to do better... but they can never get as close to perfection as a game where every system involved in the simulation has perfect information about it at all times.

* There are a limited number of *kinds* of objects in each simulated volume. Characters are only modestly reconfigurable, and all possible carried objects are known to alll client applications.

SL could significantly limit attachments and clothes, and give us a set of canned character types to choose from. They could make building happen off-world, limit the number of kinds of objects in a sim, and require uploads of new content to be done at specified times... you would place your new house, but if it was a new object you wouldn't see it until the next update cycle started or you teleported out and in again. You could rez your dominus shadow, but you'd have to wait for the update and if there wasn't a vehicle slot open it would remove someone else's vehicle that hadn't been in use in a while.

Again, they could improve things without going to that kind of extreme, but they would never get near the performance of standard MMORPGs.

I don't think this is necessarily a code quality issue (though I've seen plenty of indications of code problems... I could have writen a better parser than the one LSL uses 20 years ago, in assembly language, on an Apple ][, with 16k of RAM and an upper-case-only keyboard missing "{" and "}", in the snow, uphill, both ways). It's a design issue. There's some design problems they can and should fix. There are some that would require destroying what SL is to fix.

The lag monster will always be there. They can cut it down to size, but they can't kill it without killing SL.

And the graphics functions, given what they're of necessity doing, are amazingly good. I am, honestly, impressed by how well they're doing. Thay have been better (I really would like an option to use the rendering code from 1.9.1(13)) but they have also been much worse (1.7, 1.10).

Yup, all good points... but there might be a happy medium. For example, as you pointed out Unreal loads all objects at a time when you first enter the world. That world can be huge... but everything in there is pretty much static. It can shift positions.. but remains the same. Ie... it's not alterable.

In SL, one world connects with another, we can cross sim borders and things can change in an instant, both in size and shape and in content. However, there is one major difference. Whereas Unreal items are static meshes that consist of thousands of vector points... a prim in SL contains far less. In other words, it is far easier for a graphics engine to draw an SL object than an Unreal object. So graphics-wise, SL should be a whole lot less taxing on the graphics card than Unreal. When an item changes in size in SL, not all that big a deal, because the actual data that's being changed is far less than would happen say, if you were to try and change an Unreal static mesh vehicle. That's why Unreal and Quake look so much better than SL-- they're working with a whole lot more graphics data. It's kind of a trade-off, but the fact is that for the most part... items in Second Life tend to stay where they are unless a user is having direct contact. Yes... an item in a sim can change... but does it? Not usually. Once it's built, it tends to stay as is for a while. For sure nothing changes as much as a rampaging monster in Unreal. I know there are a lot of graphic technicalities involved, but to be honest... I just think the Unreal graphics engine must be a lot more sophisticated, a lot faster, a lot more streamlined. If that same level of speed existed in SL... we'd be able to get 200 avs on a sim with zero lag.

Valid point, but that could be fixed with a background loader that updates such things on the fly. Since it would be lower priority, it would never interefere with moving or uploading higher priority data.

I'm not sure, but I'd sure like to see them try.


LOL. That one actually got a chuckle.

Well, sometimes one has to destroy first in order to build. It don't think ultimately it would destroy how SL is used... just how it operates on the inside. I fully believe there are ways to make SL work as it does now, but a whole lot faster. But even if that meant allocating sims into 4-sim blocks and needing to teleport to places outside that area... that wouldn't be all that bad.


Well, I'll agree that it's unlikely that lag will ever be 100% destroyed. But it's like the ghost monster-- it can be made so rare that people hardly ever notice it and when it does happen... they'll just consider it a glitch and not really care all that much. If they just pound the turkey into whimpering submission, that'd be a good start. LOL

It's not that simple. Objects in SL consist of dozens of prims, each of which consists of an algorithm for generating a mesh. The mesh that's generated by combining 30 prims into a castle turret can be much more complicated than an Unreal castle turret composed of 1000 vector points in a single mesh. So it may or not be easier for a graphics engine to draw a castle turret in SL.

In addition, if there are 10 turrets in the castle, in Unreal they all have the same mesh. SL can't assume that, so it can't use OpenGL tricks to bake lighting into one turret and duplicate it. Also, it can't generate a raster image of the turret to map onto a cylinder and render that when you get far enough away.

So, it may be easier to the graphics engine to draw an SL object (though that's not guaranteed for an object made of many prims), but it's MUCH easier for the graphics engine to draw a scene in Unreal with a comparable number of complete objects.

And... a scene in SL is very unlikely to have as few objects as a scene in a game like Unreal.

To change the size of a static mesh, you can just apply a transform to each coordinate. For 1000 nodes, that's 3000 1d multiplications. To change the size of a Dominus Shadow SL has to recalculate about 20 parameters for each of about 30 prims, then relocate the prims, then regenerate the mesh by calculating the intersecting hull of the 30 prims.

I don't know if I'd describe them as looking uniformly better. The objects in Unreal, in particular, have a kind of "unfocussed" feel to them. The vehicles are blobby... like they've taken an organic approach to design... even in areas that one would expect them to be mechanical. Objects in SL tend to be boxy and geometric, but they're all very sharp and precise. Building good organic objects is harder, but it's possible and I've seen some amazing examples... and machinery and vehicles often look a lot tighter and more precise.

If it was simply a matter of the graphics, and you were to eliminate the chichi hair, you could. I've certainly not noticed lag when looking at the welcome area from a modest distance (letting LoD take care of the chichi hair) even when all four sims were showing a lot of users.

One thing that avatars do that 100 rampaging monsters in Unreal don't... is look into the world. Monsters in SL don't look around with each lingering glance represnting thousands of updates to a client. That's a significant source of sim lag right there.
I've flown from Lusk to Calbeck several times, sometimes at altitudes of 40 meters or lower, and I've gone ballooning all along the mountains in the Atoll continent. So I think I'll have to disagree there.

Well, that's kinda the point I was trying to make. If it's more difficult for SL to handle/draw a prim-based object that for Unreal to handle mesh-based objects... then that's a problem with SL graphic handling routines. They're not efficient... which is a concept that's been presented by many people in different threads.

One of the main points that have been made in a lot of lag discussions is that SL seems to be a graphics hog. From what I've seen, I'd have to agree.

Yes, but 200 rampaging monsters are a whole lot more active than say, 25 buildings filled with 8 chairs each. Yet SL glitches quite often on rendering buildings and other static items, whereas Unreal rendering 200 very active monsters is pretty flawless.

(I recognize and respect your opinion regarding Unreal graphics, but don't share that opinion. I think they're pretty crisp, well-defined and far more life-like than SL).

But on the other hand there's no central control that has to micromanage the behavior of those monsters. They can have their status updated with multiple seconds of delay, if need be, because the algorithmic behaviour of the monsters is completely defined... there's no possibility of rubber banding. So your 200 avatars on their 200 camping chairs might not actually be doing anything... but the SL application and server still have to sync their locations fast enough to avoid rubber-banding if an unpredictable user stands up... and have to do it for all 200 copies of the application concurrently.
What do you mean by "SL glitches on rendering buildings"? What are you actually referring to, because I don't recall seeing what I would refer to a glitch in the rendering of a building that isn't obviously due to dynamic content (like, for example, loading textures or blurred textures on a wall).

There are database problems with the server (mystery phantom root prims, for example), but these don't have anything to do with rendering.
It's a problem with the decision to use prims rather than meshes. I do not believe that the Unreal engine would do any better given the same constraints.

It's a problem with the decision to use prims rather than meshes. I do not believe that the Unreal engine would do any better given the same constraints.

Have you ever seen a wall disappear... but it's still there? Ever slammed into something that hasn't visually rezzed yet and is totally invisible? Every looked at a building from a distance and seen "flicker" all over it.. only to have that flicker disappear as you get closer? And probably the best example of all: ever see land parameters (mountain ridges especially) completely change as you get closer to them? What about Linden trees flickering and disapearing and conflicting with one another? Those are graphics glitches. And they don't happen in other 3-D systems. All sorts of excuses can be made as to why SL does those things, but the bottom line is... it does those things... when others do not.

Then the goal should be to render prims in the absolute fastest possible manner. Which I think we've all agreed could be greatly improved.

Nope. There was a bug a while back where prims would get two rotations, so that they would display at a different rotation than they were shown. But I haven't seen that in at least four releases.
Yep. How's that a rendering bug?
That one I have seen, andthe opposite. That's caused by having two prim faces exactly coinciding. I suspect that you would get the same problem in Unreal if there was a mechanism for putting two objects in almost but not quite the same spot... I have seen it in other games that had algorithmically defined objects. I would like to see that one fixed, but I haven't actually been able to figure out how LL could solve this problem in a general way... and it's not that hard to build
so it doesn't happen.
Seen that a lot, as your view changes from one resolution to another. I'm not sure how Unreal handles that... there are a couple of approaches... the simplest one is not to ever build a mountain range such that the high and low resolution versions of the mesh differ significantly. Based on the scenery I've seen in Unreal, I suspect that's what they do.

You can also see the same effect happening with prims. It's less obvious because they're, well, smaller... but I've had my spectacles turn into hexagons in some releases. Unreal, of course, handles that by having multiple resolution versions of objects precomputed.
That's actuallysupposed to be an *advantage* to Linden trees, and I've seen the same things happen with algorithmic trees in other games.
I'm not making excuses, I'm explaining why they happen. Some could probably be fixed, other glitches (like the rotation one) have already been fixed. Others (like the invisible walls) aren't anything to do with rendering... that's a download issue. You could fix it, by freezing you until everything was downloaded, like other games do... but I personally prefer LL's solution.

We have? I suspect it might be possible to do significantly better, but I honestly can't say I'm sure.

OK, as I already stated, there are all kinds of excuses regardingSL graphics glitches. Explaining "why" something doesn't work well is what I call an excuse. Example:

That bug was seen in v1.11... which considering we are now in 1.12... It is not an ancient problem. And no matter why... it was there. It was a coding problem. Glad they got it fixed. For the several weeks it was there, it was a royal pain for builders.

It's a bug because the item is physically THERE... yet unrendered graphically. It should either not be there at all... or regraphically rendered before physics sets in so we're not constantly slamming into invisible objects. One simple fix to this would be to render all solid objects in a standard gray texture the moment they are realized on the sim. They do that to an extent already.. but not completely. That is a graphics rendering problem. It doesn't matter why... it matters that people slam into invisible, not-fully-rendered objects every day of the week.


No... I'm a builder. I know not to interpose two objects on exactly the same plane. I am talking about two object occupying slightly different planes, and resolution dropping so that faces behind a foremost prim showing for a brief moment, then back to the foremost surface... causing flicker. This can also be seen in two alpha textures one behind the other... and builders have commented on that for ages. Put one alpha item in front of another, and it vanishes. It shouldn't, but it does. That is a graphics rendering bug.


Or.. maybe they just handle graphics resolution correctly in the first place. Whichever, the fact is that they succeed... and SL glitches landscapes.

Another example: Dig a hole. use prims as a ground cover. If done well, it can be almost flawless when close by. Start flying away. Look back. The ground around the hole has disappeared and the edges of the ground cover prim show clearly. Graphics rendering problems.

Another example: Dig another hole. Dig it deep. The deeper you go, the corners of that hole start rising up in sharp points. Look down at the bottom of the hole. The ground is all rippled. No amount of land flattening will fix those problems. Dig another hole. Set it to have a 16 x 16 bottom. Oops! Can't! Because as you dig, instead of the hole going straight down, it slopes. And there is no way to overcome that. Man, I have a $15 sim program that has better land tools than that. Those are graphics rendering problems. It's either bugs, or design flaws, or just plain shoddy programming... but it's graphics flaws that have been there from long before I joined SL.. and are still there.

Not that I'm just trying to pick on LL or SL. There are many very impressive things as well. I don't mean to seem all negative. But these are things users have complained about for at least 2-3 years... and they've never been corrected.

When I dig a hole, I want the sides to go straight down, I want the ground around the hole to be perfectly level and unripppled and... unless I tell it I want a rippled floor at the bottom (in which case I'll purposefully make the floor rippled)... the floor at the bottom should be totally flat. If a $15 zoo game landscaping tool can do that... why not a vastly more expensive SL?

Does it? Or does it just have really good graphics rendering routines that don't make blunders like that?

I seem to remember one quote...
Now while that is not graphic specific, I think it gets the idea across. And it still gets a chuckle out of me every time I read it.