did you read the blog recently...

This is one of those "GuessIknows"

You'll get people who say they barely use resources,

You'll get people who say they definitely do..

I have yet to hear anyone come down and say the Lindens conclusively said they barely use resources.

They must use some, Second Life needs to keep track of their online status and their location consistently -- at a very minimum.

Regardless; how many fractional load bots equal one real person? Thats the real question.

Even if a bot used 1/100th of the resources of a human resident then 100 should get logged off to allow that one real human resident to log on.


Again assuming a limited log in que as the contingency.

Not sure I understand that.


I didn't say that..


Or that..


LL _has_ said that the sim sends objects to the viewer but the viewer has to ask for textures.


That's true but I think it's more a sim function than an asset server one.

Meaning you will get people on both sides of the issue who act like they know, but provide no conclusive information.

Really they are just going by what they "Think happens"




Didn't say you did. Said other people do. You were just asking.

Groups - I was looking up a group tonight, and discovered that putting a group name in search leads to getting a whole LIST of names, that goes on and on for pages and I didn't see the group in the first few pages.

(Except Azure Islands, when I put in "Azure Islands," I got pages and pages, but Azure Islands was at least at the top of the list.)

Is this related to what they did, above?

coco

It's "easy" for anyone to test.

Run a bot and look at the bandwidth usage on the Net connection.
(Turn off anything else that generates Net traffic).
Run a range of bots from different sources.

If the bot code has been crafted very well, then no textures are downloaded.
The draw distance should be minimal, as near 0 as possible.

On the other hand, bot code that is based on standard viewer code with extra bits added on for some purpose could be a greater resource drain than would be a normal avatar controlled by a human.

The above is a measure of a bot's load on LL's bandwidth.
It can't measure the load on a sim or the rendering load for people in the same sim as the bot.

A bot in a closed box way up high isn't going to be a drain on everyone else's rendering.
A dancing bot rigged out in prims is going to suck part of the rending capacity of everyone nearby. It won't help anyone else's downloading and rendering lag that the bot is superbly coded to use minimal bandwidth for its own connection back to its controller.


A bot, whether mixing with 'live' avatars or up in a box, is also going to suck part the sim's collision calculations.
Even if it is not moving about, it has to cause as much calculation load as would a physical object.

Tegg, I am not sure why you quoted me in this reply, but your example doesn't even come near my original question. Where I was talking about 2 avatars that just sit, using the sitting animation of the chair they are in, you are talking about heavy loaded avatars that use scripts and all. Of course they use much more resources.

A light-weight client like Sleek however, that controls an avatar with basic clothes, skin, and an almost empty inventory, doesn't. At least, I think it doesn't. There is virtually no network traffic as far as I can determinate. Of course the system keeps some data like where the avatar is located, and the fact it is online, but I think that is hardly an issue. For 1 of your mentioned campers I think one can run quite a few bots Thats why I think the strain on the system is caused by real avatars and not the inactive bots (landbots are a different issue).

Furthermore, as soon as the amount of botsgets too high, they do cause a problem, because there is a maximum amount of avatars that can get into a sim. Running 30 bots leaves room for 30 less avatars I would think?

Yep, that doesn't stop store owners win 100 AV limit islands running 90 odd AV's so they can make the top 3 in traffic, because the other 2 are doing the same.
My point is you're 2 bots aren't a problem by themselves, but when everyone runs a couple it adds up, and with all the people not running bots starting to consider bots, because they have to finacially, to keep up with the opposition, perhaps we really should just hammer & botlock the grid till it breaks continually, all the real residents leave, and LL realise this was meant to be a world for people not farmbots.
SL has the potential to be a great case study in the economic collapse of a virtual world. Hopefully the opposition learn from it.

True, it would be better to leave out traffic at all, but that is a conclusion already made many times before. Would save many bots for sure. Though I would still run my two bots as demo models though, I see the traffic just as one of the benefits of those bots. It owuld be quite easy to run 20 more and get in the top 3, as for now I choose not to though.
Still, my original question is not wether the bots are a good thing, but wether they actually do put a load on the system. In my sim there are seldom more then 10 AVs present at the same time (including Mr and Ms Demo). The bots themselves don't seem to generate any load. The real traffic bots high in the sky even generate less, as visitors dont have to rezz them. That makes me wonder wether the latest trouble is really bot related, or related to more users doing more things. I really believe it's the last option.

Marcel

More common sense. Keep it up people.

Be careful what you say Phil, I might fire up 20-30 more bots and get into serious competition with you Though my landlord might not like that very much now I think of it...

This is the part that confuses me: Every botbox I've seen has the little darlings lined up, standing all proud in their null-textured, Ruthy magnificence. But why standing? Why not sit them on a prim? Wouldn't that make them effectively non-physical? (I suppose they *might* be seated, but wearing the "stand" animation. From "Advanced / Character / Animation Info" one sees they're running "stand" without the normal cycling of the stand animations; not entirely sure how they do that, now that I think about it.)

Maybe if they can't see (because they are using a streemlined client) its hard to sit down.

Please do SL lost its passtime value for me some time ago. I only continue because it makes money, and I don't even need it. It would take very little for me to pack up and leave altogether, so you might be doing me a favour by competing like that

That part I can answer for you. When I log in my demo avatars, I have to manually sit them on the pieces of furniture I want them on.

The login process I could script, so that they automatically logon after they loose connection (sim restart, or provider hickup). For me that is of no use since I want them to sit. Putting them in a box 600 meters in the sky is much simpler, and I dont see a botfarmer manually choose 20 sit targets as soon as their bots login.

I have been looking into automating the whole process including the sit on target, but seems not to be that simple. Still it is possible, since the camping bots do the same thing. One must have more knowlegde of the programming language those things are created in as I have though

Can I have your stuff then?

I thought they had stickied that blog post

About bot bandwidth / performance issues -

I have a single bot which I run more or less 24/7. I have set her up with no prims / attachments / scripts, just system texture clothes and system hair etc. Upon login she automatically sits(!) on a chair I provided, in a windowless box, staring at a picture on a wall. I've done as much as I can to my bot program and the libSL configuration, to make her as non-impact as possible: She does not poll for or get updates from anything, i.e. when any object around her 'changes', updates are not sent to her. She has a 'draw distance' set at 32, although she doesn't download textures anyways. She is ignorant of pretty much everything, except chat and IMs. Her purpose is to issue group invites; so she receives IMs from objects, then sends group-invites. For now she handles an average of 1 invite per day, although I'd like to see that increase

Since she's running on my computer, I can measure and monitor certain things - like what amount of network bandwidth she consumes. Believe it or not, that number is almost zero (except during the actual receipt or transmission of an IM.) When I have nothing else running on that computer except the bot, the computer's network bandwidth meters show between 0 and 10 bytes per second going out, and between 200 and 400 bytes per second coming in. That's bytes, not KB. These values are the same figures my computer shows, when the bot isn't running at all -- that's just the normal 'background' level on my network.

Granted there is some activity when she logs in, and some activity when there is an invite request. And should someone TP to her and start talking, she'd be 'hearing' all the chat. But that's rare. Logins are rare of course, she only logs out if the sim crashes. She then waits 5 minutes then attempts a login. Worst case scenario is if the sim is down for a prolonged period, she'll be trying to log in every 5 minutes. (If she gets in but finds she's not in the right region, she'll log out and wait 5 more minutes.)

Having said all that, I don't approve of 'bot abuse' like those zombie armies for gaming traffic, or land bots hammering the search engine, or spybots roaming the grid compiling data on all our land and objects etc... to my mind, those are examples of people misusing tools, or taking more than their fair share of resources. My bot does one thing and only one thing, and only does it because LL haven't seen fit to give us the simple script functionality that would let us do it faster and better.

Basically I just wanted to say, it's possible (for the bot's operator at least) to know how much bandwidth a bot uses, and it's possible to make a bot that uses little to no bandwidth at all. All it takes is for the programmer to be concerned about performance and be willing to put a little effort into the process. And, I guess, to build a bot that's not designed to do things that hammer the databases and the simulaters.

-Atashi

If I go, possibly

Which is the whole point .

When we're all arguing about concurrency it doesn't matter if a bot or 20 bots lags down a sim or not, it matters whether they're taking up any amount of resources on the back-end.

One laggy sim doesn't affect anything but that sim, a laggy/croaking back-end (whether it's the asset server, presence server, database, whatever) is what breaks SL for everyone.

Thats kind of the thing.

LL has said concurrency is a potential problem and they have a contingency plan in place they haven't used yet.

But they haven't said only non-bot concurrency is a problem.

People are just speculating that happens to be the case.

@Atachi:
Do you have any documentation about how to set up the system for auto logon, and more important auto sit? That would be great for my posing alts, but I could not find documentation on how to make that happen. So now I just manually login 2 Sleek clients and manually sit them on their targets.

The impact on your system, and network traffic, I had seen as well. That, together with the basic understanding of what the in-world process does, gives me a pretty good reason to think the bots are not the main cause of the current overload.

@Phil:
Well I am certainly not hoping you will leave SL If you ever do, I will come to you and quote this thread, even though you use the word "possibly"

@Kitty (&Colette):
No one knows anything for sure, seeing how long it takes to solve things, probably not even at Linden Labs anyone does know for sure.

What we can do though, is try and think about the problems. If it really is simply concurrent logins only, the solution can't be that difficult. However, I do not believe that if I would login 65.000 bots one by one (instead of the regular users), the system would crash. Simply because those bots do not put much of a load on the asset servers, and those are the ones that seem to collapse. That is why I don't believe it is just the concurrent logins as a number.

Avatars that interact with the SL world do put a load on the asset servers though. And when concurent users rise from 40k to 60k, a certain percentage of those extra 20k are real users. Or do you think its just bots that come into SL? In that case walk around in the average newbie area

So we can conclude the number of real users is getting up, as well as the number of bots. And in my opinion, it is the amount of concurrent real users that crash the asset servers. That is no knowledge, but a deduction from the facts we do have.

True, but based on what seems to flake-out first, and what LL hints is their plan for fixing things, it seems like the Asset Server cluster represents the current bottleneck, and if that's true, then we have a pretty good idea what adds stress to the grid and what doesn't.

And, assuming that's correct, it would seem the very worst thing one could do is sort Inventory during peak usage. Of course, there's no way to tell a bunch of campers to keep their paws off their Inventory, but bots generally don't have much in Inventory nor much call for doing anything with it.

*** ON THE OTHER HAND ***, does anybody understand wtf was the reason for the particular constellation of functionality that was disabled during the load test? It seemed to be everything even peripherally related to Groups--and we've heard that any increase to the 25-group limit would have unacceptable performance impact. It's always seemed pretty difficult to imagine a design that could have such a problem, at least not without hypothesizing a truly brain-damaged schema. So... anybody know what was really being tested?

My dream would be for Search to be (once again) the bottleneck, so LL might bestir themselves to pull at least the Land search functionality into either LSL or (better, in this case) a service accessed through the web. There'd still be landbots, but at least they'd mostly just be TPing around when there's something worth buying. That uses grid resources, of course, but I don't think there are all that many of them.

Mostly, I'd just like LL to pay more attention to the overall system architecture, and quit making us use alt account bots as if they were WSDL. There's just no reason all these transactions need to have agent overhead--nor even share the same network as the grid. It's just a profoundly and embarrassingly inept design. Unfortunately, it's probably not the particular design flaw causing the crisis du jour.

/me predicts that part of TheGrid(tm)(r)(cc)(rsvp) will eventually have services that help people run non-camp/traffic bots but at less of an impact to the grid. Take, for example, landbots - maybe LL could make it so that the normal queries that viewers do can only access data that gets updated, say, once every 10-15 minutes. People who want to run landbots could sign up, for a fee, to a different back-end isolated land database that updates closer to real time. This type of thing wouldn't be good for those that deal land the 'old fashioned' way but they're sorta already screwed and have been for a year+.

As information becomes a more valuable commodity, TheGrid(tgif) may have to start changing the way it's accessed so LL can more appropriately charge for it and reduce how people slamming for frequent updates impact the rest of us...

Well many of those things on the "shut off" list also happen to be things that break when SL starts to get flakey.

So .. it maybe makes sense from that perspective ..

Shut down all the things that are likely to break but you don't really "need".

Then Also Shut down things that are non-essential. (like the traffic number one)



Kind of like throwing everything you don't need out of the airplane so it will make it over the mountain.

Why bother with all that? ... If they want to facilitate the gaming of traffic ..

They could just sell high traffic numbers directly and cut out the whole need for avatars.