I realise that these figures may or may not represent a norm with others here,

Exactly. For my Athlon64 system, I currently get about double what I get at Einstein. Should this mean that credits are cut in half? Personally, I don't care about comparing "Alberts" to "MilkyWays", so my vote is "no". It would not matter one iota to me if suddenly a project like CPDN or SIMAP decided to pay out 20 times more than any other project, I still would not be participating there because it's not my interest...

Anyway, so long as projects produce optimized apps and baseline them with SETI's stock app, the disparity in favor of SETI's 3rd party optimized apps will continue.

Exactly. For my Athlon64 system, I currently get about double what I get at Einstein. Should this mean that credits are cut in half? Personally, I don't care about comparing "Alberts" to "MilkyWays", so my vote is "no". It would not matter one iota to me if suddenly a project like CPDN or SIMAP decided to pay out 20 times more than any other project, I still would not be participating there because it's not my interest...

Anyway, so long as projects produce optimized apps and baseline them with SETI's stock app, the disparity in favor of SETI's 3rd party optimized apps will continue.

Well everyone was going into these math calculations of what they were getting per minute, second, hour etc. <smile> I just wanted to see if I could do it. I have 3 other systems besides this one and I had no desire to do a daily comparison on every computer. Just picked the one I use all the time since everything was right there.

I'm not advocating raising or lowering credits as I think it is pointless. I came here before Milksap's app and was happy with what I was getting for my time, I of course didn't complain when I started getting even more when I went to Milksap's. Now MW has cut the credits in half. I'm still here. If they lowered them to what seti is giving I'll probably still be here. As long as usefull science is being produced and we are able to see the results. I have NEVER picked a project for the credits I get. I have specific interests in certain science projects and those are the ones I share my resources with. The real shame is that I started with seti and would like to have continued but with all the "problems", of which I don't want to spend hours discussing, I found other projects that interest me.

In the end I think it is up to Travis and Dave to decide what they want to award in credits. Be it in line with seti or not. I'd hazard a guess that they want to give a little more than average since this is an alpha project and they want to make it worthwhile to keep enough peopel here to make the project operate in an efficient manner. While at the same time not awarding an outragous amount that has other projects or DA breathing down their necks all the time.They have kind of asked us for feedback on this and I came up with a figure of 50 credits per hour. Others have suggested similar as well as different figures. Whatever the final outcome, those who are unhappy for one reason or another will find something else to do and those that are satisfied will stay.

PS. I realise there are people that pick projects for what credit is being paid. While I am not in that group of crunchers, whatever motivates someone to join a project and volunteer their time and resources is fine. Hopefully the final results here will also make it worth their while to stick around too.

Might want to take this to the code discussion, but we've been using the following for linux:
i686: -O2 -ftree-vectorize -funroll-loops
x86_64: -O2 -msse2 -ftree-vectorize -funroll-loops

and the following for osx:

ppc: -O2 -maltivec -mabi=altivec -mcpu=7400 -funroll-loops
i686: -O2 -msse2 -mfpmath=sse -mtune=prescott -ftree-vectorize -funroll-loops
x86_64: -O2 -mfpmath=sse -mtune=nocona -msse2 -ftree-vectorize -funroll-loops

Does that mean that the 32bit machines running linux do not use SSE2, but the 64bit machines do?

And does the same apply for Win systems?

---

Never surrender and never give up. In the darkest hour there is always hope.

Might want to take this to the code discussion, but we've been using the following for linux:
i686: -O2 -ftree-vectorize -funroll-loops
x86_64: -O2 -msse2 -ftree-vectorize -funroll-loops

and the following for osx:

ppc: -O2 -maltivec -mabi=altivec -mcpu=7400 -funroll-loops
i686: -O2 -msse2 -mfpmath=sse -mtune=prescott -ftree-vectorize -funroll-loops
x86_64: -O2 -mfpmath=sse -mtune=nocona -msse2 -ftree-vectorize -funroll-loops

Does that mean that the 32bit machines running linux do not use SSE2, but the 64bit machines do?

And does the same apply for Win systems?

Yes, I would think so.
That was actually the reason I only published 32bit versions. They did not use SSE/2 on any system. Distributing 64 Bit binaries (automatically using SSE2) are only fair, if the project also creates 32bit binaries using SSE2. In case of MW the speedup comes just from the SSE2, not from the 64bits.

Might want to take this to the code discussion, but we've been using the following for linux:
i686: -O2 -ftree-vectorize -funroll-loops
x86_64: -O2 -msse2 -ftree-vectorize -funroll-loops

and the following for osx:

ppc: -O2 -maltivec -mabi=altivec -mcpu=7400 -funroll-loops
i686: -O2 -msse2 -mfpmath=sse -mtune=prescott -ftree-vectorize -funroll-loops
x86_64: -O2 -mfpmath=sse -mtune=nocona -msse2 -ftree-vectorize -funroll-loops

Does that mean that the 32bit machines running linux do not use SSE2, but the 64bit machines do?

And does the same apply for Win systems?

I'm not sure about the windows systems because dave compiled those. The reason that the 32 bit machines aren't compiled with SSE2 is because it was said in the forums that not all 32 bit architectures support that.

---

In the end I think it is up to Travis and Dave to decide what they want to award in credits. Be it in line with seti or not. I'd hazard a guess that they want to give a little more than average since this is an alpha project and they want to make it worthwhile to keep enough peopel here to make the project operate in an efficient manner. While at the same time not awarding an outragous amount that has other projects or DA breathing down their necks all the time.They have kind of asked us for feedback on this and I came up with a figure of 50 credits per hour. Others have suggested similar as well as different figures. Whatever the final outcome, those who are unhappy for one reason or another will find something else to do and those that are satisfied will stay.

The real issue from our end is that we want to have our credits in line with other projects out of courtesy towards them.

We want to avoid awarding too many credits and drawing users away from other projects because of it. Likewise, we want to avoid awarding too little credits so we don't just have a few die hards who love our project :P It's a fine line to walk but I think it's the most appropriate given the BOINC community.

---

I'm not sure about the windows systems because dave compiled those. The reason that the 32 bit machines aren't compiled with SSE2 is because it was said in the forums that not all 32 bit architectures support that.

I'm not sure about pre AMD Barton chips but my 32 bit XP 3000+ only goes up to SSE. It wasn't until I went to the AMD 64 chips that I started seeing SSE2. FWIW, at einstein I have to use the switching app. in order to run their work units due to the fact that SSE2 is not supported on the 3000+ chip. I am not familiar with Intel chips.

The real issue from our end is that we want to have our credits in line with other projects out of courtesy towards them.

A noble goal, to be sure, but don't let the claims of an impending "credit war" and "credit inflation" weigh too heavily on your decision-making process. These same claims have been floated for years now and none of it has happened. Some of that is but a smokescreen for people being upset that their personal BOINC-wide standing has dropped and not so much about "fairness to other projects".

Additionally, keep in mind that the charts that track these kinds of things have flaws and that because of that they can paint an inaccurate picture.

Lastly, like I said, compare true optimized apps against other optimized apps, not the stock apps.

I'm not sure about the windows systems because dave compiled those. The reason that the 32 bit machines aren't compiled with SSE2 is because it was said in the forums that not all 32 bit architectures support that.

I'm not sure about pre AMD Barton chips but my 32 bit XP 3000+ only goes up to SSE. It wasn't until I went to the AMD 64 chips that I started seeing SSE2. FWIW, at einstein I have to use the switching app. in order to run their work units due to the fact that SSE2 is not supported on the 3000+ chip. I am not familiar with Intel chips.

Everyone will eventually be using a "switching" app there. What they have done is developed a feature-detecting app that runs first to see what capabilities the host processor has and that calls the "_0", "_1", or "_2" apps (x87, SSE, SSE2 respectively). The "power users" apps do not have the feature detection and are primarily for testing the SSE level improvements before they go into the "beta" and "stock" apps that have the feature detection capability.

As for the processors, A64 has SSE2 across the entire product line. SSE3 became available with the Venice and San Diego revisions. I have a San Diego revision 3700+. For Intel, SSE2 is available on all Pentium 4 and Pentium M systems and higher.

The real issue from our end is that we want to have our credits in line with other projects out of courtesy towards them.

A noble goal, to be sure, but don't let the claims of an impending "credit war" and "credit inflation" weigh too heavily on your decision-making process. These same claims have been floated for years now and none of it has happened.

None of it has happened?

I keep seeing people who ask "what's the project with the most credits/hour" to crunch for that one.

---

Please use "Reply" or "Quote" buttons on posts, instead of "reply to this thread". Keep the posts linked together ("X is a reply to Y").

The real issue from our end is that we want to have our credits in line with other projects out of courtesy towards them.

A noble goal, to be sure, but don't let the claims of an impending "credit war" and "credit inflation" weigh too heavily on your decision-making process. These same claims have been floated for years now and none of it has happened.

None of it has happened?

I keep seeing people who ask "what's the project with the most credits/hour" to crunch for that one.

Those people are an extreme minority. The tatic I am referring to that is employed by CPP proponents is one of exaggeration. You will always have a few people who do that, and even with the maneuvering of credits up and down, as I've shown in other posts in this thread, you can still note differences between projects because the charts are at way too high of a level. When you drill down to the fine detail about your specific system(s), you can still "credit shop", with or without CPP...

The other favorite term is "flock", as in users "flock" to projects that offer more credit. That too is an exaggeration. "Flocking" implies large groups of users. The only real migration of large groups of users are actually caused by many of the teams having a "Project of the Month"...

The other favorite term is "flock", as in users "flock" to projects that offer more credit. That too is an exaggeration. "Flocking" implies large groups of users. The only real migration of large groups of users are actually caused by many of the teams having a "Project of the Month"...

I remember a team website that said "Project of the month is X, but if you have 5.5.0 (which has inflated benchmarks), crunch RCN instead, since it still uses benchmark-based credits"

---

Please use "Reply" or "Quote" buttons on posts, instead of "reply to this thread". Keep the posts linked together ("X is a reply to Y").

Arion, your calculations surprise me, since for me Einstein gives better credit atm...

The other favorite term is "flock", as in users "flock" to projects that offer more credit. That too is an exaggeration. "Flocking" implies large groups of users. The only real migration of large groups of users are actually caused by many of the teams having a "Project of the Month"...

I remember a team website that said "Project of the month is X, but if you have 5.5.0 (which has inflated benchmarks), crunch RCN instead, since it still uses benchmark-based credits"

OK Nicolas... Like I said, those are minority cases. I'm sure we can play tit-for-tat all day, but you seem to be missing the point that the vast majority of the BOINC community does not behave that way and that a lot of the exaggeration being done is an over-reaction to the few "bad apples".

A non-BOINC example is that I'm constantly told it is "freezing" in our room at work. It could be 75F, but for some it is still "freezing". One person said the other day that they hoped someone would "fix the heat", and that was with it 76F. A week or so ago I was out for a day and early in the morning it was down to 64. One other person described the situation as "it must've been 50 degrees in here".

My point was, is, and will continue to be that all the doom and gloom predictions are exaggerations. Sure there are examples of bad behavior, but they are made out to be worse and/or more rampant than what they really are...

hmm...I have seen many people that go to the higher paying projects for that reason. For the brief time that nano was adjusting credits people did flock to the project b/c of the high payout. Isn't that a reason that Seti has so many doing that project? The minority isn't as minor as you make it out to be.

Years back at my high school the so-called "minority" made up 80-85% of the school, the "majority" was only 8-10%. There are times the minority is the majority.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

The only real migration of large groups of users are actually caused by many of the teams having a "Project of the Month"...

I don't know if this is true or not, but I would certainly be influenced by any campaign my team were having, such as an Xmas race in WCG right now. However, if the RACs of the last few weeks were still offered here I would forget any campaigns and resort to crunching where I wanted ;) (even if the inflated credits benefit my team far more than a pre-planned campaign ;)

---

I'm not gonna get all philosophical on this but I WAS getting about 9k here (milsop's app.) and now less than 1.5k per day.( new opp app) I'd just like to see a reasonable adjustment.

---

A clear conscience is usually the sign of a bad memory

Bob in FL
Send message
Joined: Jul 19 08
Posts: 2
ID: 6411
Credit: 228,568
RAC: 10,291

Message 7326 - Posted 3 Dec 2008 13:29:18 UTC


Last modified: 3 Dec 2008 13:33:51 UTC

Thanks to everyone. I am back up and running again. I'll be anxious to see if someone comes up with a new optimized application. With the new credit calculations, I have some systems now that are getting a better credit per CPU second on Seti!

--------------------------------------------------------------------------------

Just a statement made on another thread!

---

A clear conscience is usually the sign of a bad memory

I'm not gonna get all philosophical on this but I WAS getting about 9k here (milsop's app.) and now less than 1.5k per day.( new opp app) I'd just like to see a reasonable adjustment.

again, how does that compare to other projects? also if you were using the optimized application on older machines chances are it's not bumping up to near the credit limit anymore, so you're seeing more of a penalty.

---

hmm...I have seen many people that go to the higher paying projects for that reason. For the brief time that nano was adjusting credits people did flock to the project b/c of the high payout. Isn't that a reason that Seti has so many doing that project? The minority isn't as minor as you make it out to be.

Looking back at historical stats, there were about 900,000 users BOINC-wide at the time (Jan-Mar 2007). The increase in users at Nano-hive during that timeframe was about 2,000 users. As a percentage of total users, that equates to around one-quarter of one percent (0.0025). If I were to project the current trend in the total-to-active user ratio (currently around 4X), that would get me up to a supposed "flocking" of approximately 1% of the active user base at that point in time. I do believe that 1% is a minority... Not only that, not all of the 1% of users would've joined the project for that reason, thus the "flocking" was in reality less than 1% of the active users.