traffic and what my ticket result was

OFFS. I was right the first time. So here's how this works: Assume we start at A at time=0, we'll be on the parcels for the portions of a minute as follows:

A :00 - :45
B :45 - :30 <-- Note
C :30 - :15
B :15 - :00 <-- Note
A :00 - :45 (repeats)

So the B interval processes by 45 seconds as I originally said (the time spent on another parcel), so the portion of a minute that overlaps between those intervals is only 15 seconds (between :15 and :30 in our hypothetical clock above). So that's a 25% probability, making the total probability of all the alignments about 14% (as I'd originally posted).

From which we learn that insomnia + caffeine != normal brain function.

[EDIT AGAIN DAMMIT: The careful reader will note that the B interval is indeed moving by 30 seconds--the 90 seconds of the stay on B + the stay on the other parcel. But because the dwell is 45 seconds long, they overlap by 15 seconds from one visit to the next, despite starting 30 seconds out-of-phase. So the 14% probability is correct, but that's because the interval shifts by 30 seconds, not 45. Crap.]

I'd say that it's very unlikely that the instant in the C sim would be the same as the instant in the AB sim. For the sims to do anything other than act independently for the sampling would be insane.

The non-alignment between the sims of the sampling would be the reason that a 'sample-at-an-instant-every minute' approach could deliver a traffic bonus.
On the other hand, counting any presence during the sample minute as a full minute of traffic would deliver the same results-ish.

hmmmmmmm...
At the place where I'm doing the tests, I actually have the corners of three sims beside each other. The 4th sim is a Linden one.
I could move the alt around in such a pattern that over three sims, the 'instant' v. 'partial minute' approaches could be checked.

If it works on 'any part of the minute = a traffic minute', then there would be a huge advantage for traffic injectors to flit bots around a set of sims. It would be far easier to manage that would be a 'sample at an instant' situation.

No matter which method is used by the sims to measure traffic, it remains that there is a potential for gaining a traffic bonus by flitting bots.
I have this depressing feeling that it a server load alone that is moving LL to pay attention to traffic gaming.

Well, they could have well synchronised clocks and just take the snapshot on the minute every minute. I'd say that was very likely indeed.

Just to add:

I wouldn't get hung up on exact minutes for these test results.
The test actually ran for 14 hours and 4 minutes - at which point the crossing from sim C to sim AB borked.
I won't know for sure if any traffic is omitted from the first results until the next pair of sim updates. There seems to be a lag between the 24-hour sampling and the traffic update time.

It's a bit moot. I got what I was looking for.
-- Yeah! I know that's sub-optimal science My excuse is time constraints.

In that case, my test results could only be explained by the snapshots counting the number of agents that had been on the parcel even for an instant during the minute. This would motivate traffic-injectors to flit bots between sims as rapidly as possible.

At first thought that would a reasonable way of doing it, but it doesn't fit Sling's results without the system going to great lengths to count an avatar on a parcel even for an instant, which must be highly unlikely since there is no point in going to those lengths when an unsynchronised local timer method will do very well and be much simpler to implement. I.e. it's much simpler to snapshot who is on the parcels at a particular time than to keep a record of who was on which parcels during the 1 minute period. So I think that synchronised timers are highly unlikely.

Right now, I'm thinking that the most likely explanation for the data is a mechanism that once a minute creates a list of agents on the parcel and that adds to that list each time a new agent comes into the parcel. At the next minute, it adds the length of that list to the parcel's Traffic count, and updates the list to include just the agents currently on the parcel.

An even simpler mechanism would just keep counts instead of a list. If it works that way, there would be no way to tell if a newly arrived agent weren't already on the parcel at some point earlier during that minute, and so a single agent could count more than once each minute if it comes and goes multiple times.

I doubt it. If that were so the the bots-in-a-box would have a 16m parcel into which they go every second and come back into the main parcel - giving 30 traffic points per minute per bot.
I'll run my test just for cells A and B in the one sim, jumping every 10 seconds.

I eventually got around to that 10-second AB jump, A and B being in the same sim.
I captured 2 hours, in which A got 120 traffic points and B got 0.
The alt would be in parcel A at the same segments of a sim minute, and in parcel B in the remaining sections of a sim minute.

Thanks, Sling. That's very interesting. That B gets 0 traffic totally screws my parcel-entry trigger theory, whether done by simple counts or by unique agent list.

In order to accommodate both this result and the ABC 45-second results, it seems there must be multiple samplings per minute at an interval longer than 10 seconds, and unique-agent-only counting. (That is, unless the ABC 45-second data arose from phenomenally good alignment with parcel-specific sampling times on one-minute intervals.)

Another possible way to think about it: Agents have their own record of how long they spent in each parcel, and once a minute they have to "vote" on whichever parcel they think they were on for the longest part of that minute. If this were perfectly precise, it again would be difficult to explain why no traffic accrued to parcel B. This seems equivalent to universally synchronized parcel sampling, and I get drawn back to a sampling interval greater than 10 seconds yet substantially less than 60.

For B not to get any traffic, such an interval couldn't be 15 or 30 seconds. It could be 20 seconds, or conceivably 12.5 (5/minute). At the moment, I'm not really up for reassessing the probability of the ABC results with any of these intervals, because this whole sub-minute sampling thing seems like more computation than one would expect; there must be a simpler explanation that I'm missing.

1 traffic point per avatar minute on parcel. 1440 points per avatar times sim avatar allowed count equals maximum traffic for the sim.

The only deviation is from an avatar popping off and back on fudging in a tad more which is why some bot runners refer to "pop bots". Using pop bots will fetch you over the top limit for a sim. The impact on the sim from the bots breaking connection and logging back in is huge. every time an avatar enters a sim it creates a huge drop in time dilation.

Thing is with all the bots nobody can get in so what is the point?
Some "rush" from "winning" the "relevance game"?

/me rolls eyes.

Lose the incentive. The abuse follows incentive. If you don't disconnect traffic from relevance then be prepared to explain exactly why you allow some people to abuse the system and not others.

I tried to create a new account today and got a message that I've reached my limit. I think I've got four, unless I've forgotten about one. I guess I could have tried a different email address but that would seem to be cheating as the message talked about limited accounts per household.

I'm not sure if that's a change or not. I believe there was always a limit on the number of accounts per email address (but I'm not sure it was enforced). If they're suddenly trying to somehow enforce a limit on the number of accounts "per household," that would be a very big deal.

That limit has been in place for a long time. They track a lot of things to try to stop people from creating lots of accounts. In particular there's an IP limit that when exceeded blocks you from creating any new alts on that IP ever, even if you delete older alts.

Huh? What was the question? What was the ticket about?

Rha, your first post makes no sense to me since I missed the earlier thread. Were you intending to close the audience to those who missed it?

So why does the wiki still contain that description that says that one avatar provides one point of traffic per day... not per minute?

Lear. Rha asked LL about how traffic ic calculated.

Argent. Because either they can't be bothered keeping the wiki up to date, or they prefer people to think that the old formula is still applied - or it wasn't LL who wrote it.

according to the ticket (which you can see quoted on the first post)

So, basically LL doesn't do anything with the wiki, and anyone can go in and update the existing info with the official info from the KB. I chose not to, because I do not need to have people coming to me and bitching about changing what they have determined is true and factual. *shrug*

I really do not care how it is calculated, it doesn't really mean anything to me.

Yep what Phil said, it was about how traffic is calculated.

The 1st post contains the response to the ticket, which doesn't make much sense unless you know what the ticket was about in the first place. Never mind for my sake, though.

It's no news to me that LL doesn't maintain the contents of the wiki. I believe that they do maintain the knowledgebase (perhaps haphazardly).

Rha, if you see something incorrect in the wiki, you'd be doing everyone a favor to at least post that you believe the info has changed and point to the KB (either on the page or in the discussion tab). If everyone refrained from updating the wiki for fear of reprisals, the Wiki would be useless.

OK, I removed the bogus section from the Wiki page and moved it to discussion.

I will update the first post to include that pertinent info

as for the reprisals, some of us would rather avoid the confrontations that would be sure to ensue as well as the consequences.

Trusty mustelids, fearless of reprisals!