Animation Overrrider Kill

Well, you were man (woman?) enough to admit that you were wrong. I admire that

Thanks for posting the results of your tests. Maybe "mass hysteria" is too strong a phrase for it, but I believe there are many commonly held beliefs about lag that are no longer true since the new scheduler went in (1.7 or 1.8, I don't remember). "AOs cause massive lag" is only one of them. Things changed pretty drastically "under the hood" with the new scheduler, and scripts are handled in a completely different way now. Here's how the new scheduler is different, at a very high level - if a script is poorly written, it's the script that will run slower, instead of the sim working harder.

I'm glad you posted your results. Hopefully people who read this will realize that many things (about lag) that used to be true prior to 1.7 aren't true any more. The more people realize this, the more these misconceptions can be cleared up.

here's a rough ballpark on my own testings, in an empty sim:

1) HUDS can take 3-5 fps off. at 30+ to begin with, of course that's a hit i could live with... but in busy places where i'm already under 10fps, the loss is not acceptable.

2) using my own dance toy ('AOrta' - dialogcards, and i think 2 or 3 times a sec timer; listens to a couple high/low channels), barely even a frame off.

3) trying a favorite wig... MINUS 15-20 FPS!!! as pretty as it is... it's gone into my special 'BAD FPS' folder. i have others just as attractive that are not nearly so hoggish.

i've certainly encountered inefficient scripts and AOs along the way... but i would have to back up an earlier assertion that the prob much more likely resides in our visible attachments.

That works for me.



Well, since a verified conclusion has been reached regarding the subject of this thread, no harm in discussing copyright concept further.

First, I think it should be recognized the neither one of us are copyright attorneys... am I correct? You're pretty much in the same boat I'm in; we apply copyright law according to personal understanding of existant copyright laws. So neither one of us is an absolute authority. And since copyright law, like so many other laws is not a hard-science... such law is open to court interpretation based on individual circumstance. As happens every day in copyright legal cases.

You are correct, that there is a difference between copyright, trademark and patent law, and cases involving such sometimes overflow into the other areas. Perhaps I wasn't clear in making the point that I was trying to make: people often think copyright law covers areas that it doesn't cover, such as trademark and patent law (which as you correctly observed, is what happened with that computer company; they were trying to apply "trade secret" concepts to copyright law). Patent law is far more restrictive and all-covering than copyright law. Someone even hints at stepping on a patent, and they're in court. Trademark and Copyright law are about equal in level of enforcement. Copyright law is excellent in defending the areas it is designed to defend: author rights. However, often people try to use copyright law to impose personal whims on others. That's where we get into the concept of "slavery clause".



I think it's pretty obvious I haven't been ignoring any of the data you've presented. I just disagree with your take on it. A point of forum discussion: you can make all the points and present all the data you want. No one is forced to agree, nor accept the validity of presented data. It's nothing personal if someone doesn't agree... it's their right. That's called freedom of speech. And no one is required to do something just because someone else demands it. That's called freedom... period.

Regarding shrink wrap vs open source software, I'm not sure I see the point being made. Doesn't the same copyright law apply to both items? It's not a matter of different law (to my knowledge) but proper application of that law to the area of focus.

Here's an example, perhaps closer to home than previous examples: Open Source Software Widget Company releases a program to the public. Their license states "You may redistribute this software so long as you give us credit for the original source and provide our company name and copyright notice in your usage." Up to that point, they are 100% within their rights. That is a basic concept of copyright law. However, then they put in their license, "You are also required to place an advertisement for our company on your website and in all advertising that you do." Ah, then we get to questionable areas, because that is pushing the concept of the "slavery clause". Still, the company might argue that they're not providing their software free of charge, that such a requirement is part of the contract "payment" for redistributing their software. They might have a valid and court-supportable argument there... IF they can prove that is indeed the agreement between them and their clients. However, that is not an issue of copyright law... it is an issue of contract law... a totally different area.

However, then their license states, "If you use our software, you have to provide an open-source copy of our software with your software distribution"... then it becomes more questionable, because a court might rightly then ask, "In what way does this impact author rights? Such would seem more like a personal whim than protection of author rights. Then the court would start asking, "Will failure to include a copy of original source code deprive the author of potential income?" (no, the item is authorized to be distributed free of charge). "Does failure to include the original source code bring unjust profitable gain to the company distributing the software as part of their package?" (No, the company will earn potentially the same profit regardless of inclusion/exclusion of that code). "Does the matter involve plagarism?" (No, the distributing company has provided proper credit via copyright notice, as required by basic copyright license). These three tests failing, a court could very well conclude this is a "slavery clause", nothing more than a whim of the company and indefensible under copyright law.

Now, it has to be realized that one court may conceivably decide differently than another court, and such cases are tried and appealed every day, often with differing decisions than the first court. But bottom line: there are limitations as to what a company can demand for use of their open-source, publicly-released code.

Now, if GPL as an example were to state, "You may use this software for your own needs, but you may not redistribute it under any circumstance for any reason"... that might actually be protected. But then someone might challenge that the very act of releasing the package via public venue as open source completely negates the concept of such a license requirement. Why? Back to the point I presented earlier: GPL would have failed to take reasonable measures to protect their copyrights. They would have sent the software out via public means and said, "Here, but you can't distribute it further..." which someone might successfully claim is contradictory and self-defeating. Forbidding someone to mass-distribute a product that is openly mass-distributed, if my memory serves me properly, has already been tested as a principle in a number of cases. Such would be kind of like stating, "You can buy and drive our automobile, but you can't take your friends for a ride." The very concept is absurd, and could easily be ruled such by a Court of law. Some rights are implied by nature. Which is why the right of backup applies to just about every copyrighted thing in the universe, including books, tapes, CDs and more. It is right by common-sense implied necessity.

So again, copyright licenses are not legally valid just because some company decides to write something on a piece of paper. If a court decides it's an unreasonable license requirement, they can even go so far as to make the work public domain... which has happened to some copyrighted works of various media in the past.



Intent noted and apology accepted. It was mostly the wording... basically, "Did you do what you're required to do by law?" Such carries an accusatory tone. Simple rewording might have presented your thoughts better. Often when we use the word "you" in a sentence, we risk personalizing an otherwise innocent statement. Example, "Did you take into consideration" (implying the person either did not, was incapable of or failed to take into consideration) can be properly replaced by, "To be taken into consideration..." Old "Business 101" communication classes. However, we all fail in this sometimes and even often... me included.



Never meant to imply such, and my apology if it came across as such. Probably did the same thing I mentioned above. But I was challenged to present data/sitings to back up my statement. I was simply informing that I don't have the time to do research others are capable of doing themselves if they want to reserach the matter beyond simple forum discussion... nor am I required to do so by any concept of law, propriety or "unwritten code". A forum is primarily an opinion platform. Most advanced debate students know that their opponents are not required to do research. They themselves are if they wish to ascertain the truth. Many a debate has been won because one side presented totally undocumented statements much more skillfully and logically than the other. This is a forum. Anyone can make any statement. Requirements beyond that are nil and proof of correctness of the statement the responsibility of those who disagree. In other words, I don't have to "prove" my points to you. You don't have to "prove" your points to me. If I disagree with what you say, I have the choice of accepting that we disagree, discounting your statements entirely, or consider the possiblity that you're right (in which case, responsibility for determining the facts falls to me... not you).

So that is why when someone tells me, "Present the data to back up your statement" (or alternately as I've heard from several trolls, "Go do this experiment to prove what you say" my response is... find the data yourself. Go do your own experiment. Or as my dad used to say when I asked him the spelling of a word, "The dictionary is over there. Your fingers aren't broken".

[edit: to avoid confusion, it should be noted this is not in discussion of the original premise of this thread, namely.. AO DEVICES... but in response to a major diversion from the original thread, copyright law and propriety... which was really way off subject. )

First of all, thank you for actually replying with your findings after taking the time to verify whether or not what you were claiming is actually correct. This is more the way it should be.



And while that is a valid example, you were the one who came here claiming that AOs lagged up sims to the point where you wanted a area-wide function to turn them off. It's completely fair, and in fact should be ASSUMED, that we would want to know exactly what would lead you to believe such a thing that we actually have EVIDENCE to believe is not true. Telling someone to 'find the data themself' after you've made such a claim is completely disrespectful, somewhat insulting, and borderlines on willful ignorance. If you've made the claim, the burden of proof rests on YOU, not the person asking you to back up your claims.

Addendum: At the very least, it's annoying as hell, morseo than any lag I've ever experienced in SL.

One major benefit is that this may alert some to the idea that old perceptions of SL prior to 1.7 may now be totally invalid. (Of course, they've obviously been replaced by all new problems... but.... ).

It's pretty apparent that inventory access is far laggier and more glitchy than it once was (despite the wonderful addition of a search engine-- albeit the slowest search engine I have ever seen anywhere). Texture rendition is so slow it damages merchant sales (people don't buy when a picture takes ten minutes to rez). Sounds are rendered so slowly that many gestures have become totally useless (we see someone make a gesture, then 15 seconds later we hear the sound). These things are pretty much apparent across the board, no matter which sim is being visited, and points to a serious database/multiple database structure/routine problem that needs to be fixed by crawling under the body with a big hammer.

But as far as AO devices... it's actually kind of nice to know they don't seem to actually have much to do with sim lag any more. (I dunno though, I have this strong gut feeling that the new method of script operation/reporting demands more than meets the eyes). However, there is one aspect we haven't tested, and I don't know is even possible to test client-side: how much do AO devices affect overall sim script performance? Could a significant detriment in general script operation cause sim problems? I can't think of a way to even test that without a blank sim and a few dozen hours of work... and Linden Powers.

Yeah, that agrees with our findings today. Worn prims are LOTS worse than just about any script.

But HUDs cause av lag? That's a new piece of info that's good to know. I've been asking LL to give us a way to tell when someone is using a HUD, because there have been reports from other areas of dishonest users using HUDs to cheat at sporting contests (anti push devices, archery range finders, etc). Our solution has been to alter the targets to be MUCH harder to hit. And fortunately, most of our contestants are honorable. But it only takes one cheater to ruin an event. The total inability of land owners/sim owners/event hosts to detect HUDs is causing contest problems.

Firstly... I wasn't refusing to provide data for the AO concept. I was refusing to waste my time when I was challenged regarding my opinon of a totally off-thread concept... that of copyright law. This isn't a thread on copyright law; it's a thread on a potential AO problem. (and since we're being honest and blunt... those who fail to thoroughly read posts and post adversarial responses are far more irritating than any mistaken statement of opinion ).

So in defense... I assumed (as do most users on SL) that AOs still caused major problems... especially since often when 10 users congregated in an area, sims could slow to a crawl . Wasn't any reason at that time to challenge that basic concept. When some users mentioned that AO devices don't do that, and that they'd performed experiments to prove it, I considered that possibility but rejected it as unlikely. But the thought was planted and when more than one user voiced that finding, I decided to test it. I didn't actually expect them to be correct, but they were.

What I responded negatively to was the vehement insistance by one or two that AO lag was a result of mass-hysteria and was nothing more than that (really, if people want respectful response.. they need to be more respectful in discussing an issue, no matter how strongly they feel about it. Taking an adversarial position is likely to create adversaries).

It was obvious from past experiences and already existing findings that at one time (ie, prior 1.7), AO devices WERE a major problem. I knew this to be a fact from several experiences when our sims first opened and were fresh, and from one particular instance I remembered when a user came to an event and the sim lagged the moment he appeared (and continued to lag)... and that lag stopped when he complied with a request to remove his AO device. Then when we asked him to put it back on, the lag reappeared. That was pretty conclusive evidence that at the time that even one AO device could be a serious lag problem. The blanket statement that this was just a misconception produced by opinionated rumor was both insulting and incorrect-- and the vehemence in which it was stated produced predictable negative response.

So I at no time refused to produce data regarding AO devices (at least not to my memory). When it was apparent that such experimentation was necessary to determine the validity of the initial post, I told people I would be doing so, then went to the trouble to conduct the experiments and released the data-- even though it proved my original premise wrong.

I just didn't see the need to comply with a demand that I produce data/citings regarding a subject that was totally off-subject in the first place.

hehe -probably- only for the wearer, on the clientside - as HUDprims are invisible to everyone else. though if there's timing-pings going on too, that may affect others in the same area, too...

but most certainly, i get a measurable hit using huds - s'more prims, y'know... and each prim usually has its own custom texture. the figure i quoted above is with ZHAO... trusty and reliable, though i'd like to consolidate its features into my dancetoy, so i don't have so many timers attached at once.

I have an "Andy Warhol"-esque prediction for the future:

"At a future date, the total conglomerate of HUDs will encompass 85% of available screen area.. leaving the user with 15% screen visibility."

I'm sorry, but it really seems that you are. I described the way the GPL works, and the difference between its restrictions and typical "shrink wrap" licenses which attempt to deny rights that are granted under copyright law, and you came back with more examples of the latter kind of restriction. I stated that the GPL had been upheld in court and provided links to articles, and you came back saying that courts didn't uphold these kinds of licenses. I did a buttload of research, and you came back and said you wouldn't do my research for me. It really looks like you haven't even been reading what you're responding to.

For example:

The GPL actually goes further than that: it requires you to provide the source code to the entirety of any product you make that is based on GPLed software. But... and this is what I'm trying to get across... it doesn't matter whether you think this is or is not enforcable in court. In every case where a GPL violation has gone to court, it has been upheld by the court or the defendant has settled and agreed to the terms of the GPL.

All your theories about why the GPL might not be enforcable are moot, because the bottom line is that it has been held up every time it's been challenged, and even Microsoft has followed its requirements.

The thing is, your information isn't totally incorrect, and I can imagine before the script scheduler became active in 1.7, there were some scripts (not just AO devices) that could build up to cause massive lag. Indeed, and the reason why 'AOs cause lag' became such a widespread belief is that a particular popular open-source AO script called the Franimation Override used a very low repeating timer (I'm not sure what it was at, I think it was .001 or something) to provide very fast respons to avatar state changes. .001 means that theoretically, the script was trying to run a block of code 1000 times every second. Of course, it would never actually do so, but it would attempt it. A later modification to the Franimation by someone else and released free changed the timer to much lower, and is generally the script that is in usage by most popular overrides using this script (note: it was just a change to a single line, probably alot of people did it). Most people that didn't know anything about that script, or the overrides that used them, probably still went on believing what they'd been told all along, that AO's cause lag.

Then, 1.7 rolled along, and as you say, changed everything. Even if people were still using the old, OLD version of Franimation (which was used in a ton of different override packages, including the freebie WetIkon, and the abranimation's overrides, and a zillion other overrides), it wouldn't be as bad, simply because the script would NEVER be able to execute the timer that fast, even under optimal conditions.

I think what the poster above meant about HUDs is that they slow YOUR framerate down, not anybody else's. XD (although they can contribute to sim degredation with their scripts, just like any other script). You don't see other people's HUDs, so it doesn't slow anyone else's framerate, just yours. I believe the framerate hit is due to an extra 'scene' being rendered seperately over your view, which is disabled when you aren't wearing an HUD... although that's just a guess.

I apologize for my hostile tone earlier - there probably was another way I could have got my point across without resorting to satire.

It does, in some ways - it requires more thoughtful scripting IMO. Contrary to what some people were saying when 1.7 was released, the new scheduler does not give you the freedom to write laggy scripts with no penalties. Quite the opposite, in fact (again IMO). Before 1.7, if you wrote a script that used resources heavily, the sim would work harder to try and keep up. So everyone else would lag because the sim was trying to make sure your script ran properly. Now, what will happen is that the offending script will get slowed down, but other users' experience won't be affected. So a poorly written script that requires any kind of synchronization will actually lag *more* than it used to, but this will be lag within the script itself, not lag for everything else going on in the sim. So the only thing affected will be that script (and any objects/avs using it or interacting with it), and no one else.

In theory Obviously none of this is black and white.

Edit: Deleted. Best to not jump into a snake pit.

Interesting. And I'm not denying your statement. However...

Considering that GPL open source code is uh... open source...

And considering that certain computer commands are essential to performing tasks of similar nature (ie, if I want to script a vendor, I'm likely going to somewhere be required to use the llGiveInventory statement just like every other vendor on the planet)...

And considering that open source code can be significantly altered and reworked...

And considering that it is then compiled into end-user code...

How do they manage to PROVE it's their code in the first place?

Inquiring minds want to know. Unenforceable license is also an area of case law. Concept is called "burden of proof" as far as I remember.

You're right there. I remember way back in 1.3 days, someone gave me a really kewl device called the "Ama Omega Sky Particle Creator" to show how much a badly kluged script could affect a sim (and NO negative dispersions upon Ama Omega... this was an aldulteration of a very fine and versatile original script).

This script created two streams of diverging particles, heavy-coverage, that went so far into the sky I could not see the top. Was originally designed to draw attention to an event. Only problem-- it lagged sims to an absolute standstill. To my knowledge, I no longer own that device, but it taught me a lesson about good/bad scripting. One script, one particle creation, WHAM!

I don't think it could do that now. Almost wish I had it to test. LOL



Hey, been there, done that, regretted it later, vowed never to do so again, did so again, kicked myself again... LOL. Accepted and forgotten. XD

Well, in the real world (as opposed to Second Life) they get to examine the executable and point to "oh, look there's the easter egg I put in... see... run strings on the PROM and it says 'Argent Stonecutter rocks your code'".

If you don't have access to the source, or even the executable, it's harder. But when you click on a Tiny and you get a message that the Franimation Overrider can't find a notecard to give you, you've got pretty compelling circumstantial evidence.

Of course you can't prove violations in every case, but then again there's really no way for the cable company to know whether I'm running an ethernet cable through the roof space to another apartment and sharing my cable Internet with my neighbor either... you don't have to be able to catch all violations to have an enforcable license.

Errr... are you sure that it lagged the *sim*, and not the *client*? The whole point of particle generators is that the sim doesn't know they exist other than "this prim has this list of parameters that get sent to the client".

Good point. Like you said, particles are client-side, the sim doesn't generate them. A heavy particle generator could lag every client that was looking at it. To an uninformed user, this could appear to be sim lag. You'd really have to use the tools (check FPS, time dilation, script run time, etc.) to be able to tell if it was the sim that was lagging, or the client(s). Again, more scope for misconceptions to get propagated.

Yes, you make a valid point. But consider:

Server side or client side... everyone who can see that particle stream is involved. So if I'm standing within 100m or 200m of someone who releases the Godzilla of all particle streams, it doesn't really matter to me whether the server is lagged or I'm lagged-- the overall effect is still the same. I can't walk. I can't talk. Others can't see me walk or talk. Ie... the "sim" is lagged.

You make a valid and proper technical point and I agree. But when it comes to lag, there's a definition (I can' remember whether I came up with it or Foolish Frost came up with it): "Lag is best defined as anything which causes the customer to percieve a drop in performance time and ability". If that effect is perceived by multiple users, and especially if it's perceived in different areas of a sim at once, then we have a major lag source. That source may be server issues, it may be client side rendering of SL, but it's lag. It degrades bottom-line ability of the customer to experience the SL environment.

Now.. one great thing about client-side issues... they quite often can be controlled. We had that issue come up at Dreams Fair the other day. Someone had a huge particle generator. In that case, the solution was to tone it down because of the public venue. But... the fact remained that any user at any time can totally remove particle lag by simply turning their particle count to zero in preferences. Now, although particles are rendered client-side, there is still something that comes from server to indicate where, how, in what quantity, etc those particles are rendered-- and whether they are still being rendered or not... so I have to believe at least some of it is server-side... and no telling how much time it takes every cycle for that information to be relayed. So I wouldn't think that anything is totally client-side. There is always some kind of server communcation.

But for sure, if a person:
* Sets draw distance to 128 or even 64.
* Sets particle count down to 1000 or even down to 0.
* Sets avatar detail, tree detail and object detail sliders all the way to the left

... or does any of another dozen things that affect client-side performance, in many cases they can almost totally eliminate most lag... at the sacrifice of performance.

Some things that doesn't help. Slow inventory, slow textures, slow sounds... that's basic database/ data handling errors. But we can control a great deal of "lag" if we're willing to sacrifice visual detail.

No, it's not.
No... you're lagged. Other people in the sim with better computers or different settings can walk or talk just fine. If you say "the sim's lagged" and they're not lagged, they'll look at you and say "no, you're lagged".

This is not just a fine technical point, it's like the difference between being caught in a traffic jam and being out of gas.
Yes, it's a single list that's downloaded once when the prim containing the particles is first seen by the client. The impact on the sim is no different than the impact of a single comparably sized texture... and it's be a small texture at the most because the longest llParticleSystem list isn't that long.
Sure there is. It takes zero seconds per cycle once the prim containing the particle system has finished rezzing.
And if they can, then that's not server lag.

Yknow Argent, sometimes I wonder if you answer posts just because ya love conflict. LOL.

Originally Posted by Wayfinder Wishbringer
Server side or client side... everyone who can see that particle stream is involved. So if I'm standing within 100m or 200m of someone who releases the Godzilla of all particle streams, it doesn't really matter to me whether the server is lagged or I'm lagged-- the overall effect is still the same.



OOOOkkaaaay... if you say so....



When I was a teen, a close friend one time drove this point home. He made a statement. I blatantly replied, "No it isn't." He looked me straight in the eye and said, "Ok.. you're right." And he dropped the discussion.

Now, since I don't want to be rude, let's address your replies.



I believe I was pretty clear when I stated in the message that "when I am lagged and other people are also lagged, even in other areas of th sim"....

Argent, I have a dual core 1 gig ram, 6600 256meg PCIx Nvidia card, 250 gig high speed SATA hard drive computer with an internet connect speed of 5.5mbps. In the words of Jack Linden one evening, "You're not only faster than 99% of the people on the sim, you're faster than 99% of the people on the grid!"

So I would think when I experience lag, it's not because my computer is inferior to others. Now granted, sometimes that is the case with some people. They're using old Pentium IIs on a half-baked DSL hookup and they lag when someone chats more than 3 words. Such happens. But I have to believe in general that most people these days have at least a Pentium 3 or 4 with 256 megs ram, Cable access and a decent graphics card... especially if they're using Second Life on a regular basis. (note again... in general).

So when a dozen people are standing at Drum Circle and enjoying a nice dance and suddenly everyone there types "LAG!"... I really don't think it's because their personal computer is glitching client side. And if that lag is because someone just rezzed a particle generator that is supposedly totally generated clientside, at that point it doesn't really seem to matter whether the origin of such is created server-side or client side-- it's a lag problem that affects the sim... or at the very least everyone within visual distance of that device (which, if we're talking a particle generator strong enough to do that, they probably are, no matter where they're standing).

Which is the point I'm making.



We'll just have to agree to disagree. You're talking cause, I'm talking effect. Either way... running out of gas or caught in a traffic jam, you're going to be late for work. But does the analogy ring true? Just as I have often mentioned to LL in the past, lag is not the client's fault. It's not user content (because that content was working fine five seconds ago), it's not their computers (because they werent' lagging 5 seconds ago), it's not the customer holding his tongue the wrong way. I use Yahoo all day and never lag. So it's obvious that it's not generally client-generated problems. This is evidenced by the fact that lag often appears out of nowhere, for no apparent reason, then vanishes as mysteriously as it appeared... and the people on the sim have done nothing to change the environment.

Now, whether you want to call that server-side problems or client-side problems.. it's still Second Life. And I dunno about you... but I didn't write a single line of Second Life code.



Soo... what you're telling me (since I already made these points in the prior message), is that...
* Once a particle routine is transferred to the client, no information is generated by the server regarding that routine from that point on.
* The server does not tell the client when the routine has been shut off.
* The server does not inform the client of any changes that may be made to that routine.
* There are no calls to the server a particle routine might make to determine status of the environment around it? (ie, some particles shut off when it's daytime and turn on when it's night).

I dunno, I know pretty much nothing about how SL operates on a software basis. All I know is programming theory, and I find it pretty hard to believe that the server passes a routine to a client in an interactive environment and thereafter has nothing more to do with it.

But I do know this: lag is lag, no matter whether it is server side or client side. When I cannot walk in an area... and other people cannot walk in an area at the same time, whether it's an ill-behaved server routine or an ill-behaved client-side routine really makes no difference to me at all. I'm the customer. My only concern is being able to walk and talk and access my inventory. Linden Lab should certainly be concerned as to where the source of the problem might be... but the effect is the same. The customers in the area cannot move. And whatever the cause it seems to happen regularly-- in every sim, every hour of every day, 24/7/365.

Although, the funny thing is that you are correct. The server doesn't send any more information because all of that information can be gotten from other sources. For example, the client knows what 'time of day' it is because that information is sent to it by the sim - why would the sim need to update the client with more information about the particles depending on the time of day?

When a particle system is CHANGED by a script, yes, that information is sent - via partial update, I believe. You'd have to be explicitly calling llParticleSystem a billion times in several seconds in a script (not really possible) for any one prim with a particle system attached to it to have any sort of noticeable effect on sim performance... but the same could be said of pretty much any LSL command. 'shutting off' the particle system is just sending an empty list to the llParticleSystem function, and therefore falls under the above. In the case of a particle system that only plays for a certain amount of time, that information is actually sent when llParticleSystem was called, so in that case there is no other communication.

Particle Systems, in short, are properties of the prim in SL, just like it's position, size, shinyness, etc. That information, once sent to the client, isn't processed again once it's been loaded (unless you walk out of range, back again, and I assume it's not in your cache).

I think all of this is explained on the wiki at http://secondlife.com/badgeo though, and has been for.... well, as long as that's been around (since the dawn of time?). I think alot of the misconceptions you have about the SL client and server can be addressed on there.

If you don't want to be rude, then don't be rude.
That doesn't have anything to do with what I said about having your settings to high. It doesn't matter how good your computer is, it's still got limits, and you can still crank your settings up beyond the point where it can keep up. Your limits will be higher than my much slower and older computer, of course, but they're still there.
Whether you think it or not, if the lag is caused by someone doing something that's really hard to render then it's client-side. If it's client side, you can do something about it. If they drop a particle generator, you turn down particles. If they drop a bunch of lights, you turn off lighting. The point is, you can do something about it. If it's lagging the sim itself, you can't, you just have t wait it out.

It's like running out of gas, as opposed to being in a traffic jam. Learning the difference between the two is a pretty basic driving skill... and having a 50 gallon fuel tank doesn't mean you can't run out of gas.
I've run out of gas. It doesn't have to make me late for work, because I can grab a gas can and walk down the street to a gas station, or knock on people's doors and ask to buy gas. But if I go "oh, this is road lag" and sit there waiting for it to go away I'm gonna be waiting a long time,
I'm not talking about fault. I'm talking about cause and effect. The universe doesn't operate on "whose fault it is", it operates on "what is the result of this action".

If you want to call it all "Second Life Lag" I have no objections.
Correct.
If it just passes its age limit, no. If a script sets a new particle system (including an ampty one) yes.
No changes can be made to a particle system. You have to create a new one from scratch.
That's not the particle system shutting off, that's a script replacing the particle system with a new (possibly empty) one.
That's how a lot of things in SL work, and it's why SL works as well as it does. As much of the "heavy lifting" as possible is done entirely in the client.
Sure it does. If it's client-side you can prevent it from happening. If it's server side you can't.

It may be Linden Labs fault in both cases, but there's nothing that knowing whose fault it is can do for you.
It doesn't seem to happen to me with anything like that frequency. But then I know that my gas tank can only hold 5 gallons so I don't try and travel that extra mile to the next station when it's getting low.