[sly]

I just joined Seti@home and MacNN this week. I noticed that the(my) team just(May21/22) lost 250,000 credits. Was is something I said?

[tony.escobar]

Originally Posted by Billy

I just joined Seti@home and MacNN this week. I noticed that the(my) team just(May21/22) lost 250,000 credits. Was is something I said?

What are you looking at that shows Team MacNN lost 250,000? The following chart, available at BoincSynergy.com, doesn't show a loss of any credits.




QS

[mac1896]

Originally Posted by Billy

I just joined Seti@home and MacNN this week. I noticed that the(my) team just(May21/22) lost 250,000 credits. Was is something I said?

Ummm, I think it's your breath, it's not minty-fresh anymore.........

[Todd Madson]

Probably not credits, RAC = recent average credit.

The enforced switch to enhanced made everyones RAC drop.

Don't worry about it.

[sly]

Originally Posted by QSilver

What are you looking at that shows Team MacNN lost 250,000? The following chart, available at BoincSynergy.com, doesn't show a loss of any credits.




QS

I was looking at this graph here.

http://teamstats.macnn.com/seti2/stats.php

[sly]

Originally Posted by Todd Madson

Probably not credits, RAC = recent average credit.

The enforced switch to enhanced made everyones RAC drop.

Don't worry about it.

If people leave the team do the credits go with them?

Like this; http://teamstats.macnn.com/seti2/sta...=p1&UID=16

[lepetitmartien]

Sure, you crunch for yourself and aggregate to a team at will, so the credits belongs to you and you make you whole credits benefit the team while you're in it. Once gone, the credits follow you.

[tony.escobar]

Originally Posted by lepetitmartien

Sure, you crunch for yourself and aggregate to a team at will, so the credits belongs to you and you make you whole credits benefit the team while you're in it. Once gone, the credits follow you.

Not true. Credits earned while a member of a team stay with that team if you move (the points are still part of your total; they just don't get added to your new team's total).

From the Unofficial BOINC Wiki, What about earning Credit while a member of a Team?

The accumulation of Credit in your own account will never change regardless of membership on a Team. You will always accumulate the appropriate Granted Credit if you are on a team, you will accumulate the same Credit if you are not on a Team.

When you join a Team, you join it with a zero balance. After you have joined a team, the Granted Credit is added to your Total Credit balance and to the Team's Total Credit balance.

When you leave the Team, the Credit you earned while a member of that Team will stay with that Team. You do not take it with you to add to another Team's Total Credit balance.

Climateprediction.net is an exception to this. Due to various complications, all of a user's Credit is allocated to their current Team. So Climateprediction.net Team Credit moves with you.

QS

[tony.escobar]

Originally Posted by Billy

I was looking at this graph here.

http://teamstats.macnn.com/seti2/stats.php

When I look at Team MaNN's total credit at either BOINCsynergy.com or the stats prepared by The Knights who Say Ni!, they show the team's total at 19,569,602 (at 9AM US CT). The graph in your link shows over 22 million credits.

The team member movements table for Team MacNN at BOINCsynergy.com does show the departure of ST251-1 with 242,743 credits on May 23, which could account for the change. That table also shows the departure of Paul Bridger with 218,442 credits on May 9, whcih does not appear on the chart that you linked to.

Based on my previous response re: credits not moving from a team when a member leaves, I think this is a data charting problem. Guess we'll have to wait for whoever runs MacNN's stats to check in with this thread.

QS

[Todd Madson]

So, you just have to have better incentives to keep people from leaving your team.

[reader50]

SETI Classic allowed all credit to follow the user wherever they go. I wrote our stats backend during that time, along with associated assumptions on the data handling. At the time, most other DC projects also allowed all stats to follow the user.

My feelings were that this was appropriate, the user crunched the stats, it was up to the user where to park them. You provide the hardware/time/electricity, in exchange you own your stats. Projects that hijack your stats to a particular team were the exception then.

When stats are tied to a team, the primary benefit is to failing teams that are unable to keep their users. The main losers are unhappy former team members, and teams that are successful in attracting team switchers. Unhappy former members really lose out. You get fired off your job, and really dislike your former company team afterwards. However, there is nothing you can do to remove your stats from that team afterwards. Your stats will always appear in their totals.

Anyway, our stats data comes primarily from the projects' member listings pages, which are always the most up-to-date source. Those listings consistently show a member with full credit. Our team total comes from adding up the member totals. There are several possible ways to resolve this mismatch problem:

a) Accept infrequent updates. Extract all data from the XML dump files. Unfortunately, the XML dump files are huge, and projects sometimes only regenerate them 1-2 times per day. Smaller projects have been known to update the files more frequently, but as a project grows, this becomes a prohibitive load on their servers. So they end up backing off and becoming another slow-update project.

b) Allow erratic data integrity. Show the full member totals as the member pages show them, but draw the team totals from the XML files. But since the totals won't match, this defeats part of our automatic data integrity checks, which delete updates where the totals don't match (this check is designed to automatically recover from minor database corruption). Also, the team total will have the odd behavior of not updating consistently when member totals update throughout the day. I could anticipate changes in the team total by updating it as member totals update, then reset it as new "official" team totals arrive, but this would potentially allow team totals to go down as forecasted stats get replaced with official stats. It could also show teams passing each other based on projected totals, which subsequently prove incorrect. Result: erratic team graphs over time.

c) Use the XML data to adjust the member totals within a team listing. The team total will then add up properly, but you still have cases (where a member jumps to another team for a few minutes/hours, then jumps back again between stats updates) where you end up having to make a data correction later on. Also, you break a cardinal rule of stats tracking - our member listing pages would not match those provided by the official project member pages.

In the end, I ended up choosing option d) and trying to get the best of both worlds. Our member listings work the old way, showing the full member-based team total. Our interteam ranks listing uses the official totals, but updates slowly as new XML data becomes available. This approach is possible because our member and team listings mostly come from different data sources.

Depending on how the projects built their databases, it is possible that a database crash and recovery will reset things, erasing the history on past teams. If that turns out to be the case, member totals will become team totals again, followed by diverging totals as member moves accumulate afterwards. To my knowledge, no BOINC project has experienced such a crash to date. Perhaps they all use good backup strategies, like everyone is supposed to.

The Distributed Folding project didn't, they had at least one crash which randomized all the internal user IDs. This made things particularly interesting for most stats sources at the time, which hardcoded to the user IDs. Most of them ended up wiping their stats history and starting over after the incident. Our more robust error options allowed me to turn off ID matching across the crash and reprocess the data using fallback user matching options. It took less than an hour to make the manual correction. We ended up ignoring the project DB crash, all stats and history continued as though nothing had happened.

I'm still hoping the problem will eventually just go away. For example, enough unhappy users with stats attached to teams they now hate, may someday persue legal action against the project policies. People have been known to sue over far more minor things. The Climate project has already broken ranks and gives the user full control. We'll see. In the meantime, good stats can require compromises here and there. I opted to have our stats update much more frequently than the competition, while showing a team total that adds up the old way. The separate interteams page uses the official method, so the teams appear in official order. It still feels like a good compromise.

Hope this answers the question.

[Knightrider]

Originally Posted by QSilver

Not true. Credits earned while a member of a team stay with that team if you move (the points are still part of your total; they just don't get added to your new team's total).

I remember this debate. It was a hot issue. A lot of the big teams were screaming about there totals reducing and how people could use there credits tactically by moving out of one group, dropping their totals and into another group increasing theirs. They thought that the credits earned with that team should stay with that team. In truth I think most people could not be bothered about that, more like they get fed up with a team and just move on and take their credits with them. Another argument was that it would deter aimless Team hopping.

I was against Teams retaining credits. 'ilike Team MacNN'. Nice people, interesting things going on. Hey - a new slogan for the Team!

K.

[Shaktai]

good, though long explanation reader 50