How many scripts listening on one channel is too many?

I'm currently doing a build that may include upwards of 200 scripts listening for commands. I'm wondering if this many scripts listening on one channel will create problems, or should I partition the traffic amongst multiple channels?

I'm looking for some concrete numbers or experiences for future reference.

I would be curious as to why you would need 200 listens on the same channel...is this for one object?

If it's one object you can do one listen and do link messages to the linkset if you need 200 prims doing 200 different things.

If you're changing prim properties (textures, size, position, alpha, etc) then you can do this without the extra scripts and using the link commands like llSetLinkPrimitiveParams and others.

I'm implementing sim-wide environmental configuration, all separate objects.

The real answer to that question has to do with how often commands are going to be said (by anything) on that channel.

First off, I most definitely would not pick a "common" channel--put it somewhere in the obscure numbers. If possible, I'd even make the channel configurable.

Secondly, are you going to have these 200 objects listening to a central "server object"? If so, are you able to restrict the listen to a specific key...ensuring that they are only listening for a command from that object? Such a restricted listen would also help.

It's a fact of life that you will sometimes need a great many listens to accomplish what you're looking to achieve. The concern in such a situation is just that you do everything possible to make said requirement as efficient and "well coded" as possible.

I've taken measures to minimize the chance of cross-traffic from other sources.

What I'm interested in are statistical data on how channel broadcast/listen break down at high volumes.

I'd be pleasantly surprised if that kind of data were already collected.

My hunch would be that if all recipients will need to get every message, it will be more efficient to broadcast on one channel.

In the interest of the sim, though, one would hope the messages are infrequent, and the recipients don't do anything too ambitious by way of environmental configuration. Put another way: with 200 scripts all getting events simultaneously, *how* they got those events is likely to be the least of one's concern.

Gods, this wouldn't be necessary if the language had a callback feature, or if one object to adjust the features of another that didn't happen to be linked.

If it turns out the load IS too high and some objects miss the call, perhaps you could llRegionSay on different channels but sync on a time of day event (if needs be synced).

It's an interesting question. On one hand, chat channels are nothing like channels on, say, a wireless network where there is contention for the resource. You CAN saturate a wireless channel without flooding channels that aren't too nearby on the spectrum. An LSL chat channel is just an index, however, so on its face there shouldn't be any impact.

BUT- I imagine the reason you're concerned is 200 objects listening on the same channel will all activate at the same time, and unless all or most of those objects need every one of those messages, you might be incurring a killer script load on the sim in all the objects receiving superfluous messages that have to check every incoming message to see if it's something they care about.

No, I've never seen numbers on this but it does seem like it would become a potential lag issue after a certain point. But perhaps 200 isn't too much? I mean, think how many objects out there listen to channel 0 all the time. So many attachments, all AOs, a lot of BDSM accessories. There are probably hundreds of objects listening to channel 0 in any moderately populated sim...

OK. Thanks everyone.

Looks like it's time to get permissions to run some tests!

its not really the listens, its what happens when they all fire off

A random backoff is a fairly trivial implementation.

A random backoff should be a fairly trivial implementation.

But be sure to calculate that per listener sleep time *before* the listen fires.