AHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH


Just stop already............You don't like the credits given here...

Go somewhere else!

Since this is a problem affecting the entirety of BOINC, NO.

Easy fix... go do folding@home only 1 project, no cross project problems there!

Leave the rest of us in peace.

PS: Take the sauger with you..

Since you don't seem to like the way the BOINC is supposed to work, I can say the same to you. Go someplace where there is not the problem and leave those of who LIKE the way that BOINC is SUPPOSED TO WORK alone.

Supposed to work according to you and your handful of credit police.
I think its fine the way it is. And seeing as its still the same 10 people complaining, I don't see the point in arguing with the very vocal minority.
So that is my last response you you.

Just go away...

Supposed to work according to the designer of BOINC.

---

BOINC WIKI

OK By Gosh I think I got it. Give 1 credit per CPU second for all projects.

So my 200 MHz is worth the same a a Core 2 3GHZ? This does not seem very bright.

---

BOINC WIKI

Also, I think there is something funny with the RS project's server code. If RS was the oldest project, it still won't sinc up properly sometimes. Add to that, RS being currently down...

Hmmm...

Well, that might be due to RS having the secondary objective of porting BOINC to php.

OTOH, I haven't had any trouble with my CPID sync'ing up because of RS (or any other project for that matter). Although it did seem to take longer than usual after joining. IIRC, it took about a week or ten days to sync to my 'permanent' CPID instead of the usual couple of days after the first task completed and went through a stat xml cycle.

I hadn't thought about what the effect would be if RS was the oldest project or what would happen if the oldest project wasn't available though.

Of course, I don't have that many hosts or run anywhere near the number of projects available today. The one thing which is true is SAH is my oldest project and all my hosts are attached to it. The other thing which is true is there are still some basic operational areas in BOINC which are kind of shaky and can definitely rear their ugly head given the right set of conditions (like the primary topic in this thread, for example). ;-)

@ KAMCOBILL: Based on your last post (about the CPID problem anyway), this would seem to indicate a BAM problem rather than BOINC per se. I never ran any of the 'retired' projects. However, I used to run Predictor but it remains linked to my CPID even though I haven't crunched a task for them in ages, and have gone months without even doing an update on any of the hosts which are still attached to it.

Alinator

I'm not sure what happen in Nov 2006 besides one of my hosts crashed and then the problem bagan. All my old projects had there CPIDs stolen away in this transition. :D What I can't figure is how can a host have different CPIDs (4 in most of them) and control/change the Project CPIDs when they connect. I thought the Projects Servers controled the hosts. The one good thing is I got down from 10 CPIDs to 4. I even detached from BAM to see if CPID Problem would clear up but it didn't

When BAM retires a project they detach all the hosts from the project and it keeps detaching them for an eternity. An example is ABC@Home Beta. It only has work as needed (Nov 2007 was last WU I finished) & it wasn't reachable for a while so I guess that is why they retired it. I attach to it ever once in a while to see if it up and as soon as my host syncs BAM it detached. If It does give out any work, I'll have to Detach from BAM to run it.

Are you absolutely certain about the email addresses. If the email addresses do not match the host is not going to try to synchronize the CPIDS.

Have you tried attaching everything to one host and contacting the project servers in rotation a few times?

---

BOINC WIKI

No, it is just reversing the side on a stupid argument that I am tired of getting. BOINC is SUPPOSED to work such that a particular host gets the same credit per hour no matter which project it is working on. People that say stop complaining about something that is not correct are in the wrong.

No John. Jeff and the many others are right.

You keep repeating and repeating that there is "the problem". Yet you have not proved it. You haven’t even tried to refute many of the explanations that have been presented here. You just repeat your mantra, or you invoke the “authority” of the founders. That’s not an argument. That’s sophistry.

Ever hear the phrase: “If it ain’t broke, don’t fix it.”? Words for an engineer to live by.

If there are no untoward consequences of something, there is no problem, no matter how many times you keep saying there is. Saying it over and over again doesn’t make it so.

We have shown you that the only thing you've described as a possible consequence - credits inflation - isn't happening. Numerous posters here have given various good reasons why it’s not happening, which you have failed to rebut.

No untoward consequences equals no problem. So face it. Since there are no untoward consequences, THERE IS NO PROBLEM! It’s not rational to go around obsessing about an imaginary “problem” that has no untoward consequences.

Nothing needs to be fixed. No harm of any consequence is being done. You haven't proved otherwise.

There is no credits problem.

So stop saying there is. And leave people alone. Go find something to fix that’s actually causing harm.

---

--Bill

No, it is just reversing the side on a stupid argument that I am tired of getting. BOINC is SUPPOSED to work such that a particular host gets the same credit per hour no matter which project it is working on. People that say stop complaining about something that is not correct are in the wrong.

No John. Jeff and the many others are right.

You keep repeating and repeating that there is "the problem". Yet you have not proved it. You haven’t even tried to refute many of the explanations that have been presented here. You just repeat your mantra, or you invoke the “authority” of the founders. That’s not an argument. That’s sophistry.

Ever hear the phrase: “If it ain’t broke, don’t fix it.”? Words for an engineer to live by.

If there are no untoward consequences of something, there is no problem, no matter how many times you keep saying there is. Saying it over and over again doesn’t make it so.

We have shown you that the only thing you've described as a possible consequence - credits inflation - isn't happening. Numerous posters here have given various good reasons why it’s not happening, which you have failed to rebut.

No untoward consequences equals no problem. So face it. Since there are no untoward consequences, THERE IS NO PROBLEM! It’s not rational to go around obsessing about an imaginary “problem” that has no untoward consequences.

Nothing needs to be fixed. No harm of any consequence is being done. You haven't proved otherwise.

There is no credits problem.

So stop saying there is. And leave people alone. Go find something to fix that’s actually causing harm.

Sorry, we disagree completely on whether it is broke or not. It is broke, it needs fixing.

The consequence is that the stats sites show this project with more credit granted than it should have, and the hosts and users here with more credit than they should have. The harm is to the perceived fairness of the system as a whole.

Conversely, I can say the same. You have yet to present any argument that it is fair as is across projects. You have also not refuted any or my arguments. You merely repeat the same mantra "it aint broke".

---

BOINC WIKI

[/quote]
No John. Jeff and the many others are right.

You keep repeating and repeating that there is "the problem". Yet you have not proved it. You haven’t even tried to refute many of the explanations that have been presented here. You just repeat your mantra, or you invoke the “authority” of the founders. That’s not an argument. That’s sophistry.

Ever hear the phrase: “If it ain’t broke, don’t fix it.”? Words for an engineer to live by.

If there are no untoward consequences of something, there is no problem, no matter how many times you keep saying there is. Saying it over and over again doesn’t make it so.

We have shown you that the only thing you've described as a possible consequence - credits inflation - isn't happening. Numerous posters here have given various good reasons why it’s not happening, which you have failed to rebut.

No untoward consequences equals no problem. So face it. Since there are no untoward consequences, THERE IS NO PROBLEM! It’s not rational to go around obsessing about an imaginary “problem” that has no untoward consequences.

Nothing needs to be fixed. No harm of any consequence is being done. You haven't proved otherwise.

There is no credits problem.

So stop saying there is. And leave people alone. Go find something to fix that’s actually causing harm.[/quote]

This is what happens when you "take the bait". Drop this loser and find a better way to waste our time.

Voltron

No John. Jeff and the many others are right.

You keep repeating and repeating that there is "the problem". Yet you have not proved it. You haven’t even tried to refute many of the explanations that have been presented here. You just repeat your mantra, or you invoke the “authority” of the founders. That’s not an argument. That’s sophistry.

Ever hear the phrase: “If it ain’t broke, don’t fix it.”? Words for an engineer to live by.

If there are no untoward consequences of something, there is no problem, no matter how many times you keep saying there is. Saying it over and over again doesn’t make it so.

We have shown you that the only thing you've described as a possible consequence - credits inflation - isn't happening. Numerous posters here have given various good reasons why it’s not happening, which you have failed to rebut.

No untoward consequences equals no problem. So face it. Since there are no untoward consequences, THERE IS NO PROBLEM! It’s not rational to go around obsessing about an imaginary “problem” that has no untoward consequences.

Nothing needs to be fixed. No harm of any consequence is being done. You haven't proved otherwise.

There is no credits problem.

So stop saying there is. And leave people alone. Go find something to fix that’s actually causing harm.[/quote]

This is what happens when you "take the bait". Drop this loser and find a better way to waste our time.

Voltron[/quote]
Like you said, you keep repeating the same mantra. You keep claiming there is a credits problem. You have presented no proof, you have not refuted any of what I said.

The fact that projects grant credit at seriously different rates is a problem in the perceived fairness of the system.

---

BOINC WIKI

John,

Since this subject has been so hotly debated for so long, I doubt you would have recieved a reasonable response here no matter how you phrased your inital post, but it doesn't help that you made a completely outlandish claim concerning appropriate credit for MW tasks.

You stated, "The long tasks really should be granting about 50 CS per task."

If you really believe that, then you understand that you're stating that MilkyWay should grant approximately 30% the amount of credit per unit of time vs SETI. (I'm assuming that MW is currently granting at a rate of 1.64 v SETI which seems to be a good average of the cross project comparisons that I could find) A 260 cs (long) task here would therefore grant around 159 on your hallowed SETI. (But should only grant "about 50" here)

Seems either quite spiteful or quite ignorant to tell the system administrators here that they're being "anti-social" if they don't value their project at 1/3rd the value of SETI.

I wanted to make sure that this comparison made some sense, so I looked at the computer I'm working from now and discovered that an Einstein task that takes me around 9 hours grants me ~240 cs. A MilkyWay task that takes 8 hours grants me 260. So that 260 cs task here would grant me 213 at Einstein.

Just so I'm clear, let me confirm. In your way of thinking it's 3 times more valuable to look for signals from extraterrestrials than it is to map the structure of our galaxy and over 4 times more important to look for gravity waves than to map the structure of our galaxy, yes?

---

John,

Since this subject has been so hotly debated for so long, I doubt you would have recieved a reasonable response here no matter how you phrased your inital post, but it doesn't help that you made a completely outlandish claim concerning appropriate credit for MW tasks.

You stated, "The long tasks really should be granting about 50 CS per task."

If you really believe that, then you understand that you're stating that MilkyWay should grant approximately 30% the amount of credit per unit of time vs SETI. (I'm assuming that MW is currently granting at a rate of 1.64 v SETI which seems to be a good average of the cross project comparisons that I could find) A 260 cs (long) task here would therefore grant around 159 on your hallowed SETI. (But should only grant "about 50" here)

Seems either quite spiteful or quite ignorant to tell the system administrators here that they're being "anti-social" if they don't value their project at 1/3rd the value of SETI.

I wanted to make sure that this comparison made some sense, so I looked at the computer I'm working from now and discovered that an Einstein task that takes me around 9 hours grants me ~240 cs. A MilkyWay task that takes 8 hours grants me 260. So that 260 cs task here would grant me 213 at Einstein.

Just so I'm clear, let me confirm. In your way of thinking it's 3 times more valuable to look for signals from extraterrestrials than it is to map the structure of our galaxy and over 4 times more important to look for gravity waves than to map the structure of our galaxy, yes?

OK. I will assume that you have done your math, and my apologies for getting the number wrong.

At this point, I don't remember what number I was trying to type. It is possible I either got this project mixed up with another, or it is possible I meant to type 150 and missed the first digit.

Still 260 / task instead of 160 / task is still over granting.

---

BOINC WIKI

Trust me on this.

I THINK NOT!

---

OK By Gosh I think I got it. Give 1 credit per CPU second for all projects.

So my 200 MHz is worth the same a a Core 2 3GHZ? This does not seem very bright.

Sure it is. Some people are only running 200Mhz because they can't afford to buy one with all the beeps and whistles. If there is going to be Parity why not threat them equal. Actually they should get more credit since they are working so much harder.

I'm not sure what happen in Nov 2006 besides one of my hosts crashed and then the problem bagan. All my old projects had there CPIDs stolen away in this transition. :D What I can't figure is how can a host have different CPIDs (4 in most of them) and control/change the Project CPIDs when they connect. I thought the Projects Servers controled the hosts. The one good thing is I got down from 10 CPIDs to 4. I even detached from BAM to see if CPID Problem would clear up but it didn't

When BAM retires a project they detach all the hosts from the project and it keeps detaching them for an eternity. An example is ABC@Home Beta. It only has work as needed (Nov 2007 was last WU I finished) & it wasn't reachable for a while so I guess that is why they retired it. I attach to it ever once in a while to see if it up and as soon as my host syncs BAM it detached. If It does give out any work, I'll have to Detach from BAM to run it.

Hmmm...

Now that is interesting. I seem to remember loosing a couple of host CPID's on BOINCStats around then, but everything resync'ed on the same Account CPID.

The only side effect was a couple of hosts lost their graphical data for everything from before the event.

Let me check my logs and get back to you on this.

Alinator

I tried everything to solve the problem. Including begging the Dev (which is a low priorty issue). I would like to see if they could straighten out the problem, but I think I going to detach 15 hosts from all the projects, delete/clear out all BOINC. Then go into one node and change all the CPID to my main one (or suspose to be my main one) then run it until I get all the projects to Sync with my host. Then put the others back online again.

No John. Jeff and the many others are right.

You keep repeating and repeating that there is "the problem". Yet you have not proved it. You haven’t even tried to refute many of the explanations that have been presented here. You just repeat your mantra, or you invoke the “authority” of the founders. That’s not an argument. That’s sophistry.

<snip>

So stop saying there is. And leave people alone. Go find something to fix that’s actually causing harm.

There is no need to prove his position about CPP, it is self-evident. Also, all the arguments forwarded against it so far all fail to take into account one simple premise, and the natural conclusion which follows from that in BOINC.

The Premise:

The intrinsic value of the science done by all projects under BOINC is the same. IOW's, the 'worth' of any one project is exactly the same as any other project for scoring purposes.

The Conclusion:

Therefore on any given host, the pay rate in Credits per Hour (or any other metric you choose to define) should be exactly the same for any and all projects you choose to run.

There is no way to refute that without resorting to circular or other faulty logic, or comparing to other analogies which are only tangentially applicable.

As Paul alluded to, the problem with the original BM-T method of scoring is that as basic CPU technology advances, it tends to deflate the intrinsic value of all the projects' science. Likewise, utilizing advanced CPU features tends to inflate the value of their contribution compared to hosts/projects which don't have that capability.

The other thing that Paul didn't bring up again is that the beauty of BM-T if it worked as intended is that it removes having to screw around with setting the pay rate as something project scientists and admins have to worry about. It's in the CC and automatic.

The problem with FLOP counting as it stands is that the 'The Premise' is now the responsibility of each individual project to determine and is relying on the honor system for compliance.

All the suggestions made over at SAH and the BOINC fora way back when, were ideas, suggestions, and methodologies which would address these two issues and return scoring to something which was builtin and automatic.

So where does that leave the current situation at MW? Well, when all there was to do was the short work, I was wondering just what we were really accomplishing. At those kind of runtimes if this was all that was needed for this project, why bother with BOINC at all? Obviously, it should be clear now that was just preliminary test work to see if the project was even viable for a loosely coupled DC environment. Figure on the the 'mediums' as the shortest you will most likely ever see again.

My guess is John looked at that and thought the same thing, and felt why make an issue over developmental 'busy work'. Now that we seem to be gearing up to go production, it's a different story.

In any event, none that changes the fact that all of my hosts running MW score significantly higher than any on other project they run except for RS (and of course when running optimized apps on SAH or EAH).

@ Jeff: I agree that allowing third party optimized apps on the main project at SAH is not fair in the strictest sense. This doesn't help Dr. Anderson's credibility on scoring matters, since he is a project principle for both BOINC and SAH. However, as John pointed out, third party optimized apps was not the main reason the anonymous platform was incorporated (or even considered as a reason to include it for that matter).

However the current opti's don't claim or get more credit on a task by task basis, thereby inflating the worth of their time spent on that task compared to any other host which runs it. So they don't put their wingman at a disadvantage in that respect. Now if you want to talk about rate linearity over Angle Range, that's a different story and effects everybody, optimized or not. ;-)

You could even argue the 'limited' exposure Beta apps at EAH have the same problem. However in their case when they do it, you can be reasonably assured all the improvements make it back into the stock apps and get credit corrected fairly quickly.

In any event, the real difference is it isn't the constant oneupmanship 'battle' between the third party optimizers and the stock app on EAH. It's pretty much in house development work there.

@ KAMCOBILL:

Hmmm...

I looked over my logs and the event I had was about the time your problem started.

However, I don't use BAM or any other account manager, and my logbook noted that the most likely cause for mine was that Willy was experiencing some growth problems at the time and having some DB difficulties as a result.

So since I have no experience trying to get a CPID to sync up in your situation, I can't really say whether your next attempt strategy is good, bad, or futile! :-(

All I can say is it sounds like a plan, good luck, and I hope it works for you this time! ;-)

Alinator

This is getting seriously funny John

The fact that projects grant credit at seriously different rates is a problem in the perceived fairness of the system.

Seti grants 30% more credit to the same machine only based on whether it has an optimized app or not that the project refuses to deliver to all its users as 20 other projects do!...unfair! Solaris and osx my foot, these are mainstream hosts that get optimized.

By your own ommision,although you felt the need to edit your little factoid out but I quoted you! ;)

The stock applications at S@H are currently much better optimized than they were, and even the best optimized applications do not grant at 2 to one, but if I recall, only around 1.3 to one at the moment. Trust me on this. S@H and BOINC are being re-worked to make it much easier for projects to have optimized applicatons delivered to clients

30% more credit and you have the gall to intimidate other projects and participants.

Trust me on this.

I THINK NOT!

If Seti wants the rest of BOINC to change then it needs to change its own culture 1st to start leveling the playing field.

---

I'm not sure what happen in Nov 2006 besides one of my hosts crashed and then the problem bagan. All my old projects had there CPIDs stolen away in this transition. :D What I can't figure is how can a host have different CPIDs (4 in most of them) and control/change the Project CPIDs when they connect. I thought the Projects Servers controled the hosts. The one good thing is I got down from 10 CPIDs to 4. I even detached from BAM to see if CPID Problem would clear up but it didn't

When BAM retires a project they detach all the hosts from the project and it keeps detaching them for an eternity. An example is ABC@Home Beta. It only has work as needed (Nov 2007 was last WU I finished) & it wasn't reachable for a while so I guess that is why they retired it. I attach to it ever once in a while to see if it up and as soon as my host syncs BAM it detached. If It does give out any work, I'll have to Detach from BAM to run it.

I had the same Problem for about 2 Years myself, my Stats would jump up & down at the Stat's Sites



Hmmm...

Now that is interesting. I seem to remember loosing a couple of host CPID's on BOINCStats around then, but everything resync'ed on the same Account CPID.

The only side effect was a couple of hosts lost their graphical data for everything from before the event.

Let me check my logs and get back to you on this.

Alinator

I tried everything to solve the problem. Including begging the Dev (which is a low priorty issue). I would like to see if they could straighten out the problem, but I think I going to detach 15 hosts from all the projects, delete/clear out all BOINC. Then go into one node and change all the CPID to my main one (or suspose to be my main one) then run it until I get all the projects to Sync with my host. Then put the others back online again.

I had the same problem for about 2 Years myself, my Stats would jump up & down at the Stat's Sites because the Projects I ran would fail to keep the same CPID across them. I tried everything from editing the .xml files to trying some suggestions JMV gave me which didn't work either.

What I finally discovered was that 1 Project was the key to keeping the same CPID at all the other Projects, that Project for me was Pirates@Home. As soon as I attached Pirates@Home to all my Computers the CPID straightened itself out across the Projects and to this day I don't need to have Pirates Attached anymore but do keep it attached to 1 Box just for old times sake ... :)

So maybe thats what you need to do, find the Key Project, it's more than likely 1 of the first Projects you ever ran as Pirates was for me, it's something to think about and look for anyway ... Good Luck

@ KAMCOBILL:

Hmmm...

I looked over my logs and the event I had was about the time your problem started.

However, I don't use BAM or any other account manager, and my logbook noted that the most likely cause for mine was that Willy was experiencing some growth problems at the time and having some DB difficulties as a result.

So since I have no experience trying to get a CPID to sync up in your situation, I can't really say whether your next attempt strategy is good, bad, or futile! :-(

All I can say is it sounds like a plan, good luck, and I hope it works for you this time! ;-)

Alinator

Willy says he can't do anything about or with CPIDs (just the projects) so that can't be it. Only thing I know is my hosts changes the Project CPIDs at will.

It should work in a day or so after I change all the CPIDs to 1. Maybe less if I update all of them. It'll take some time to detach and change CPIDS though.

No John. Jeff and the many others are right.

You keep repeating and repeating that there is "the problem". Yet you have not proved it. You haven’t even tried to refute many of the explanations that have been presented here. You just repeat your mantra, or you invoke the “authority” of the founders. That’s not an argument. That’s sophistry.

Ever hear the phrase: “If it ain’t broke, don’t fix it.”? Words for an engineer to live by.

If there are no untoward consequences of something, there is no problem, no matter how many times you keep saying there is. Saying it over and over again doesn’t make it so.

We have shown you that the only thing you've described as a possible consequence - credits inflation - isn't happening. Numerous posters here have given various good reasons why it’s not happening, which you have failed to rebut.

No untoward consequences equals no problem. So face it. Since there are no untoward consequences, THERE IS NO PROBLEM! It’s not rational to go around obsessing about an imaginary “problem” that has no untoward consequences.

Nothing needs to be fixed. No harm of any consequence is being done. You haven't proved otherwise.

There is no credits problem.

So stop saying there is. And leave people alone. Go find something to fix that’s actually causing harm.

This is what happens when you "take the bait". Drop this loser and find a better way to waste our time.

Voltron

Thanks, Voltron. You're right. I did take the bait. I shouldn't have given him a target. Obviously he hasn't considered our posts; certainly not mine, and certainly not the one you quoted above. Why anybody would feel so threatened because of a few differences in worthless credits, that clearly isn't impacting BOINC in any significant way, is a mystery.

So yes, he's either out just to stir up a fight, or he's in denial and cannot be reasoned with.

Thanks for the good advice.

---

--Bill

Thanks, Voltron. You're right. I did take the bait. I shouldn't have given him a target. Obviously he hasn't considered our posts; certainly not mine, and certainly not the one you quoted above. Why anybody would feel so threatened because of a few differences in worthless credits, that clearly isn't impacting BOINC in any significant way, is a mystery.

So yes, he's either out just to stir up a fight, or he's in denial and cannot be reasoned with.

Thanks for the good advice.

Yes Bill...Voltron recognizes a robotron when he sees one! After all he is Voltron :D

---

I'm not sure what happen in Nov 2006 besides one of my hosts crashed and then the problem bagan. All my old projects had there CPIDs stolen away in this transition. :D What I can't figure is how can a host have different CPIDs (4 in most of them) and control/change the Project CPIDs when they connect. I thought the Projects Servers controled the hosts. The one good thing is I got down from 10 CPIDs to 4. I even detached from BAM to see if CPID Problem would clear up but it didn't

When BAM retires a project they detach all the hosts from the project and it keeps detaching them for an eternity. An example is ABC@Home Beta. It only has work as needed (Nov 2007 was last WU I finished) & it wasn't reachable for a while so I guess that is why they retired it. I attach to it ever once in a while to see if it up and as soon as my host syncs BAM it detached. If It does give out any work, I'll have to Detach from BAM to run it.

I had the same Problem for about 2 Years myself, my Stats would jump up & down at the Stat's Sites



Hmmm...

Now that is interesting. I seem to remember loosing a couple of host CPID's on BOINCStats around then, but everything resync'ed on the same Account CPID.

The only side effect was a couple of hosts lost their graphical data for everything from before the event.

Let me check my logs and get back to you on this.

Alinator

I tried everything to solve the problem. Including begging the Dev (which is a low priorty issue). I would like to see if they could straighten out the problem, but I think I going to detach 15 hosts from all the projects, delete/clear out all BOINC. Then go into one node and change all the CPID to my main one (or suspose to be my main one) then run it until I get all the projects to Sync with my host. Then put the others back online again.

I had the same problem for about 2 Years myself, my Stats would jump up & down at the Stat's Sites because the Projects I ran would fail to keep the same CPID across them. I tried everything from editing the .xml files to trying some suggestions JMV gave me which didn't work either.

What I finally discovered was that 1 Project was the key to keeping the same CPID at all the other Projects, that Project for me was Pirates@Home. As soon as I attached Pirates@Home to all my Computers the CPID straightened itself out across the Projects and to this day I don't need to have Pirates Attached anymore but do keep it attached to 1 Box just for old times sake ... :)

So maybe thats what you need to do, find the Key Project, it's more than likely 1 of the first Projects you ever ran as Pirates was for me, it's something to think about and look for anyway ... Good Luck

That's what I can't figure out, they are attached on all hosts. The only one that is guestionable is Predictor@Home. It was down for a long time, but has been back for a while.

Then there's projects like Neutral Network Simulation & RenderFarm @ Home (to mention a couple) that I can't attach my new hosts to anymore.

The other thing is 4 CPIDs in 1 host and none of them are the same for each project on each host. So when a different host connects to the server it changes the project CPID, then the next host that connects changes it and so on and so forth, day after day.

I'm just grinning and bearing it.

This is getting seriously funny John

The fact that projects grant credit at seriously different rates is a problem in the perceived fairness of the system.

Seti grants 30% more credit to the same machine only based on whether it has an optimized app or not that the project refuses to deliver to all its users as 20 other projects do!...unfair! Solaris and osx my foot, these are mainstream hosts that get optimized.

By your own ommision,although you felt the need to edit your little factoid out but I quoted you! ;)

The stock applications at S@H are currently much better optimized than they were, and even the best optimized applications do not grant at 2 to one, but if I recall, only around 1.3 to one at the moment. Trust me on this. S@H and BOINC are being re-worked to make it much easier for projects to have optimized applicatons delivered to clients

30% more credit and you have the gall to intimidate other projects and participants.

Trust me on this.

I THINK NOT!

If Seti wants the rest of BOINC to change then it needs to change its own culture 1st to start leveling the playing field.

I am sorry that I really don't understand your insinuation. S@H grants the same credit for a single task to all that crunched that task. Some computers go through tasks more quickly. Some people have better computers. That still has no bearing at all on cross project parity.

---

BOINC WIKI