Public Land Scanner

Here is another statistic. 16sqm of land used for these scanners is 0.02% of the total area in a single simulator(2 hundreths of 1 percent). Yet, they use 10% of the sim's CPU resources. Mmmm.

Are you suggesting a formula tying amount of land owned to use of the sim's computing resources, like prims are? That seems reasonable to me, although personally I'd prefer if I could pay for computing resources seperately rather than use up land I don't want. An added bonus would be if I could actually pay for more memory than 16K per script. Of course, this would effect everyone, not just people making a quick profit on land. And the people profiting from land would be the people who could afford to buy the resources. Still, equal to everyone.

Um, not that you actually suggested all this, didn't mean to put words in your mouth, just thinking along.

No, no problem with making the suggestion. I've thought about this as have many others. I hate imposing limitations, but when people abuse the system because it's left open with some freedom (and rub it in your face that they can get away with it), then you have to impose limitations sometimes.

Should CPU cycles be "metered out"? Probably not exactly that way. Maybe a priority system should be put in place. The more land you own in a sim, the higher priority your scripts get after they run repetitive and CPU intensive tasks. LL probably needs to implement a system where they intelligently throttle scripts that maybe don't interact with Avatars and are laggy by automatically lowering their priority compared to other non-laggy scripts. How this would be done exactly would need to be figured out.

A timeslice multiplier prehaps?
Low priority = multiply timeslice lengths by 1.5
Medium = multiply by 1.0
High = multiuply by 0.5

?

-Adam

Whenever Chance Small's land scanner in Davenport fired, sim FPS would drop by 35%. Physics FPS would drop by 20%, with time dilation going up proportionately. Packet loss would rise slightly, but the rise was statistically insignificant. In more practical terms, editing objects would go from being smooth to having changes undo themselves, and saving scripts would get delayed while the scan was taking place.

Can we all just get together and file a class action abuse report on land scanners based on some of these numbers?

This is a server design/coding issue.

Fair resource allocation is an area with an extremely long pedigree in CompSci. There is nothing in SL that treads new ground in respect of that, so if it's not currently working well, the complaints are better placed in Technical Issues, or any solutions in Feature Suggestions. Getting one particular script banned here may be very expedient for those suffering the bad symptoms, but it is not the most helpful solution for SL as a whole.

Sim cycles are a finite resource which needs to be allocated fairly across all possible areas of demand. "Fair" in this context means that all real-time events are handled at their appropriate times within a specific scheduling window (anything else constitutes an RT miss, which is a fault), and that once RT requirements are satisfied, that everything else gets allocated an equal slice of the remaining pie per unit of time.

That's not hard. There are shelfloads of books and papers written on the subject, not to mention plenty of examples in open-source operating kernels, but even a pretty noddy off-the-cuff resource scheduler can provide quite good fair allocation.

Note that it is perfectly acceptable for just one single object to use almost the entirety of a server's resources if nothing else needs them. Fairness is about allocating shares across all points of demand, and 100% of resource is still fair in a population of one, 50% is fair in a population of two, and so on.

If many other parties or objects are present though, and the scanner is still being allowed to hog a very large slice of sim resource, then there's simply a bug present.

I recommend Help->Report Bug. It's a server design/coding issue, that's all.

Don't let the usual reply emails straight out of "Replies for Dummies" put you off though. Point them to this thread and we can hammer it out further if required.

Yeah, it's a very interesting problem.

One solution that LL was considering what using how much land you owned in a SIM to decide how many cycles you got.

Another solution might be to give everyone a budget of cycles and they have to work from that. If they want, they could 'buy' more cycles from other people.

Another solution, and this I have seen work well in other places, is to automatically identify offenders and significantly throttle their scripts if they start to repeat. This will encourage scripters to think harder about the performance of their scripts.

The most important thing we need though, are better tools which let us track down offenders. We may find that 90% of the people who are causing problems just don't know it and would be happy to change their scripts if they were made aware.

Simply accusing people of misusing the system is always a mistake. A lot of these lag problems are caused by people who just don't know better.

Yes, that's a common approach in schedulers, although the word "offender" is somewhat off-base ... it's not an "offense" to have an ambitious requirement. It's the job of a fair scheduler to ensure that ambitious requirements don't imbalance normal behaviour, that's all. Criminals don't arise, because the crimes are prevented before they occur.

As you mention, throttling back overuse is common. Typically a number of heuristics are maintained for each scheduled task, both positive and negative ones, and these are used by the scheduler to move tasks forward or backwards in the various scheduling queues, or to change their slice times, or to widen their RT hit window, or to assign them to faster or slower hardware in a dynamically allocated system.

For example, a poorly programmed script with a long-lived LSL loop that consumed 100% CPU and needed to be timesliced out of its allocation slot would be marked down very heavily as a CPU hog, whereas one that merely set up an event handler and immediately yielded would be marked up as event-switch friendly. The scheduler doesn't need to see inside the scripts to maintain such heuristics, such properties are determined from the runtime behaviour.

It's a fun subject, with some obscure corners, but not hard to get 99% right.

Riiki has 2 16sq plots with scanners on them =\

that's 0.04% of the land using TWENTY PERCENT

if that's not absurd I dont know what is

not all land scanners have that kind of severe impact.

Chance's were especially 'unfriendly' in their design.. most use far far less.

but the question does arise... should they be using any? i mean seriously.. at this point... are those people running scanners actually *GETTING* public land? i haven't seen really any instances of that since LL came down hard on people for abusing the public system several months ago and simply gutted it.

As things stand (and I'm not saying that it's good or bad), anyone can do anything as long as they comply with the terms and conditions and adhere to the community standards. They can certainly script anything they like, including any number of 100% CPU infinite loops and arbitrary other resource usage.

It's up to the scheduler to keep that wonderful scripting freedom from being disruptive.

The scheduling technology is slightly faulty. That's where the gunsights should be aimed.