Leiden Classical another of the great Boinc Projects that have not allowed mew members in months and whose files get corrupted while its manager is enoying the sun at Curacao.

its called been a Alpha project, hence why people are not allowed to flood in, the server is not upto the task there of letting loads of people in at the moment

But many teams have used thee fact that the project is closed to new teams to prop their standing in the DC Vault: an endeavor that is supposed to include only projects that are open for recruitment. You see nothing when the bending of the rules favors your team.

I had no idea that was being done (I hadn't even heard of the DC Vault). If the rules there are that a project needs to be open to recruitment, then those are the rules there, and they should be enforced there. However, those rules do not apply to other places that track BOINC statistics such as BOINC Stats, Munday Web and others.

---

BOINC WIKI

Leiden Classical another of the great Boinc Projects that have not allowed mew members in months and whose files get corrupted while its manager is enoying the sun at Curacao.

its called been a Alpha project, hence why people are not allowed to flood in, the server is not upto the task there of letting loads of people in at the moment

But many teams have used thee fact that the project is closed to new teams to prop their standing in the DC Vault: an endeavor that is supposed to include only projects that are open for recruitment. You see nothing when the bending of the rules favors your team.

I had no idea that was being done (I hadn't even heard of the DC Vault). If the rules there are that a project needs to be open to recruitment, then those are the rules there, and they should be enforced there. However, those rules do not apply to other places that track BOINC statistics such as BOINC Stats, Munday Web and others.

Leiden Classic BOINC Synergy 5 9,781.420765
Be consistent man: that is a serious rules violation that is proping your teams 5th place in that endeavor . I thought you were against all rule violations. Ah , that rule breaking favors your team thus is not cheating.

Working under the rules allowed by the developers of a project (in the case of Rosetta using optimized clients) is cheating because your team and you do not like it.

Nice double standard you have there John.

The thing is, even if we isolate Rosetta from BOINC and don't worry about parity with other projects, the credit system still doesn't work even for just this project. The reason for that is that Athlon 64s on Windows (general statement, mostly true) are getting 3 times the points of any other system for the same amount of actual work. I already explained elsewhere that clock for clock a Barton core Athlon XP will do approximately the same amount of work as a Newcastle/Winchester/Venice core Athlon 64, but that it gets far less points.

And that is killing healthy competition. It removes a lot of incentive for many people to crunch for this project if they can't get stats that measure up to the work they are actually doing. There's a helluva lot of P4s out there, and even with optimised clients they get far less credit than an Athlon 64 would, despite doing more work than the stats would indicate. That'll drive people away. The project needs to sort out the credit issue before people leave en mass.

I don't think this will be an issue with the new system.

Work credit takes the boinc-derived credit claims from many computers and determines an average. This average is then applied to each computer that ran that WU.

Since it's a set work for credit constant, the cpu type is irrelevant. If one computes faster than the other, it gets more credits since it's able to process more work in the same time.

Let me know if I read your post wrong.

---

I don't think this will be an issue with the new system.

Work credit takes the boinc-derived credit claims from many computers and determines an average. This average is then applied to each computer that ran that WU.

Since it's a set work for credit constant, the cpu type is irrelevant. If one computes faster than the other, it gets more credits since it's able to process more work in the same time.

Let me know if I read your post wrong.

It not an average of many computers - it's an average of a few computers on RALPH that is not representative of the total CPU mix.
What happens if a large team throws a pile of 5.5.0 clients at RALPH?
since that will still be dependent on benchmarks, they can be skewed forever - an endless chase.

---

Proudly Banned from Predictator@Home and now Cosmology@home as well. Added SETI to the list today. Temporary ban only - so need to work harder :)



"You can't fix stupid" (Ron White)

Maybe this thread should be closed once the cross-project discussion has been moved, since David Baker has stated emphatically on the XS forum that there will be no backdating.

---

Proudly Banned from Predictator@Home and now Cosmology@home as well. Added SETI to the list today. Temporary ban only - so need to work harder :)



"You can't fix stupid" (Ron White)

Maybe this thread should be closed once the cross-project discussion has been moved, since David Baker has stated emphatically on the XS forum that there will be no backdating.

Another ability that would be nice to have. . the only otions are to delete or make sticky. It can't be locked.

---

I don't think this will be an issue with the new system.

Work credit takes the boinc-derived credit claims from many computers and determines an average. This average is then applied to each computer that ran that WU.

Since it's a set work for credit constant, the cpu type is irrelevant. If one computes faster than the other, it gets more credits since it's able to process more work in the same time.

Let me know if I read your post wrong.

No, you read it right. However, as of yet, you can only see those granted work credit scores in the results page for a computer. Will it be extended so that we can compare entire teams using the granted work credit scores?

Angus also makes the point that it won't be completely representative. The only way I can think of to make it completely representative is to use the Ralph scores to set an approximate value for a work unit and have that pending until all work units from a series are complete then take the average from them all.

Upside to that would be the perfect accuracy in getting an average. Downside would be the length of time credit would be pending and the increased server load in actually working out the average.

---

OK, so BOINC originally had the pipe dream that credits would be project independant. It is obvious that did not happen.
Look at projects where a quorum system is used. You cannot tell me that when 3 WUs are returned and the median WU credit score is the one that all 3 computers get awarded. Let's look at QMC, if say a Conroe clocked to 4GHz returns said WU and claims 150 credits, but the other 2 WUs are returned by a p4 clocked at 1.6GHz claiming 50 credits and another by a AXP clocked at 2.0GHz claiming 75 credits... guess what all three get 75 credits. That Conroe just got the shaft and the credits awarded cannot possibly be compared to a WU from TANPAKU (3 WUs sent out, the first one back is the score for all three) Nor can the credits/hr be compared between the two projects because one uses a quuorum of 1 and the other a quorum of 3. Your argument that BOINC was originally designed to be cross-project equal shows that BOINC is a failure just for this instance.

Let's make this clear, BOINC may have been devised to provide a common platform for multiple DC projects capable of producing scores that were comparable to one another; however, BOINC is merely the front-end that can be used by DC developers to deploy their DC project to a large installed base which can easily migrate to the newest DC project as easily as typing in a URL... that is all that BOINC is now, my friend, nothing more, nothing less.
It is now up to the developers of the DC projects to get BOINC to work as the developers wish, and I think Baker Labs did a heck of good job.

---

OK, so BOINC originally had the pipe dream that credits would be project independant. It is obvious that did not happen.
Look at projects where a quorum system is used. You cannot tell me that when 3 WUs are returned and the median WU credit score is the one that all 3 computers get awarded. Let's look at QMC, if say a Conroe clocked to 4GHz returns said WU and claims 150 credits, but the other 2 WUs are returned by a p4 clocked at 1.6GHz claiming 50 credits and another by a AXP clocked at 2.0GHz claiming 75 credits... guess what all three get 75 credits. That Conroe just got the shaft and the credits awarded cannot possibly be compared to a WU from TANPAKU (3 WUs sent out, the first one back is the score for all three) Nor can the credits/hr be compared between the two projects because one uses a quuorum of 1 and the other a quorum of 3. Your argument that BOINC was originally designed to be cross-project equal shows that BOINC is a failure just for this instance.

Let's make this clear, BOINC may have been devised to provide a common platform for multiple DC projects capable of producing scores that were comparable to one another; however, BOINC is merely the front-end that can be used by DC developers to deploy their DC project to a large installed base which can easily migrate to the newest DC project as easily as typing in a URL... that is all that BOINC is now, my friend, nothing more, nothing less.
It is now up to the developers of the DC projects to get BOINC to work as the developers wish, and I think Baker Labs did a heck of good job.

QMC uses a quorum of one with a cap of 2,000 credits (maximum) - previously it was 1000. They are already making plans to move to serverside credits.

---

I don't think this will be an issue with the new system.

Work credit takes the boinc-derived credit claims from many computers and determines an average. This average is then applied to each computer that ran that WU.

Since it's a set work for credit constant, the cpu type is irrelevant. If one computes faster than the other, it gets more credits since it's able to process more work in the same time.

Let me know if I read your post wrong.

No, you read it right. However, as of yet, you can only see those granted work credit scores in the results page for a computer. Will it be extended so that we can compare entire teams using the granted work credit scores?

Angus also makes the point that it won't be completely representative. The only way I can think of to make it completely representative is to use the Ralph scores to set an approximate value for a work unit and have that pending until all work units from a series are complete then take the average from them all.

Upside to that would be the perfect accuracy in getting an average. Downside would be the length of time credit would be pending and the increased server load in actually working out the average.

The work load working out the average would be minimal SQL has an operator specifically for calculating the mean of a column in a query. I have had to use this on a moderate database (400K records) and it did not take much time at all. The time consuming part would probably be actually updating all of the rows to reflect the new credit.

That leaves the problem of pending credit. There are three solutions I can see, and we don't need RALPH for any of them.

1) Leave the credit pending until the end of the series.

2) Have provisional credit granted. Provisional credit would be modified when the actual mean was calculated at the end of the series. If the database used is efficient for the calculation of the mean, and not too bad about updating the data, the credit scores for active series could be adjusted once every day or so until the series was complete. Any credit requested between updates of the provisional credit average could either be granted immediately, or granted at the time of the update. The credit requests before the first update of the provisional credit would either be granted the request, or remain pending until the first update of the provisional credit.

3) Leave all credit pending until some set time (Friday at noon or noon once per day or some such). At that time, average the pending credits for the entire series and grant them at that time. This is a compromise position between 1 and 2.

---

BOINC WIKI

OK, so BOINC originally had the pipe dream that credits would be project independant. It is obvious that did not happen.
Look at projects where a quorum system is used. You cannot tell me that when 3 WUs are returned and the median WU credit score is the one that all 3 computers get awarded. Let's look at QMC, if say a Conroe clocked to 4GHz returns said WU and claims 150 credits, but the other 2 WUs are returned by a p4 clocked at 1.6GHz claiming 50 credits and another by a AXP clocked at 2.0GHz claiming 75 credits... guess what all three get 75 credits. That Conroe just got the shaft and the credits awarded cannot possibly be compared to a WU from TANPAKU (3 WUs sent out, the first one back is the score for all three) Nor can the credits/hr be compared between the two projects because one uses a quuorum of 1 and the other a quorum of 3. Your argument that BOINC was originally designed to be cross-project equal shows that BOINC is a failure just for this instance.

The 4 GHz Conroe should be claiming the same amount of credit. In its simplest form Credit is benchmark score * CPU time. The Conroe should have a higher benchmark, but lower time. This means it would claim the same credit for that work unit, but of course being the faster processor it would be able to do more work units per hour. Being a faster processor does not entitle it to get more credit for the same work - which is basically what you proposed. A standard benchmark, found in something like... the standard BOINC client, should mean that all computers claim nearly the same for the same work unit, irrespective of time taken, or platform or CPU type.

Let's make this clear, BOINC may have been devised to provide a common platform for multiple DC projects capable of producing scores that were comparable to one another; however, BOINC is merely the front-end that can be used by DC developers to deploy their DC project to a large installed base which can easily migrate to the newest DC project as easily as typing in a URL... that is all that BOINC is now, my friend, nothing more, nothing less.
It is now up to the developers of the DC projects to get BOINC to work as the developers wish, and I think Baker Labs did a heck of good job.

The reason BOINC is failing in regard to that original idea is because optimised clients are screwing up the amount of credit different systems claim.

---

OK, so BOINC originally had the pipe dream that credits would be project independant. It is obvious that did not happen.
Look at projects where a quorum system is used. You cannot tell me that when 3 WUs are returned and the median WU credit score is the one that all 3 computers get awarded. Let's look at QMC, if say a Conroe clocked to 4GHz returns said WU and claims 150 credits, but the other 2 WUs are returned by a p4 clocked at 1.6GHz claiming 50 credits and another by a AXP clocked at 2.0GHz claiming 75 credits... guess what all three get 75 credits. That Conroe just got the shaft and the credits awarded cannot possibly be compared to a WU from TANPAKU (3 WUs sent out, the first one back is the score for all three) Nor can the credits/hr be compared between the two projects because one uses a quuorum of 1 and the other a quorum of 3. Your argument that BOINC was originally designed to be cross-project equal shows that BOINC is a failure just for this instance.

Let's make this clear, BOINC may have been devised to provide a common platform for multiple DC projects capable of producing scores that were comparable to one another; however, BOINC is merely the front-end that can be used by DC developers to deploy their DC project to a large installed base which can easily migrate to the newest DC project as easily as typing in a URL... that is all that BOINC is now, my friend, nothing more, nothing less.
It is now up to the developers of the DC projects to get BOINC to work as the developers wish, and I think Baker Labs did a heck of good job.

QMC uses a quorum of one with a cap of 2,000 credits (maximum) - previously it was 1000. They are already making plans to move to serverside credits.

And in the meantime, if a P2 reports first, the Conroe gets shafted, and if the Conroe reports first (a higher probablility) the P2 gets a whole lot more credit than it earned.

---

Proudly Banned from Predictator@Home and now Cosmology@home as well. Added SETI to the list today. Temporary ban only - so need to work harder :)



"You can't fix stupid" (Ron White)

QMC uses a quorum of one with a cap of 2,000 credits (maximum) - previously it was 1000. They are already making plans to move to serverside credits.

And in the meantime, if a P2 reports first, the Conroe gets shafted, and if the Conroe reports first (a higher probablility) the P2 gets a whole lot more credit than it earned.

It uses a quorum of one, it doesn't matter who reports first. The p2 will get what it claims subject to a maximum claim of 2,000. The conroe will get what it claims subject to a maximum of 2,000.

---

QMC uses a quorum of one with a cap of 2,000 credits (maximum) - previously it was 1000. They are already making plans to move to serverside credits.

Maybe I was thinking of SIMAP or LHC, it was one of those that had a quorum of 3. Nonetheless, quorums blow.

The reason BOINC is failing in regard to that original idea is because optimised clients are screwing up the amount of credit different systems claim.

The real real reason BOINC is failing is because it is not being updated with new security measures built in. Do not try to tell me that BOINC is failing because of optimized clients that actually utilize all the capabilites of current processors, that is a load of pooh.

---

OK, so BOINC originally had the pipe dream that credits would be project independant. It is obvious that did not happen.
Look at projects where a quorum system is used. You cannot tell me that when 3 WUs are returned and the median WU credit score is the one that all 3 computers get awarded. Let's look at QMC, if say a Conroe clocked to 4GHz returns said WU and claims 150 credits, but the other 2 WUs are returned by a p4 clocked at 1.6GHz claiming 50 credits and another by a AXP clocked at 2.0GHz claiming 75 credits... guess what all three get 75 credits. That Conroe just got the shaft and the credits awarded cannot possibly be compared to a WU from TANPAKU (3 WUs sent out, the first one back is the score for all three) Nor can the credits/hr be compared between the two projects because one uses a quuorum of 1 and the other a quorum of 3. Your argument that BOINC was originally designed to be cross-project equal shows that BOINC is a failure just for this instance.

Let's make this clear, BOINC may have been devised to provide a common platform for multiple DC projects capable of producing scores that were comparable to one another; however, BOINC is merely the front-end that can be used by DC developers to deploy their DC project to a large installed base which can easily migrate to the newest DC project as easily as typing in a URL... that is all that BOINC is now, my friend, nothing more, nothing less.
It is now up to the developers of the DC projects to get BOINC to work as the developers wish, and I think Baker Labs did a heck of good job.

QMC uses a quorum of one with a cap of 2,000 credits (maximum) - previously it was 1000. They are already making plans to move to serverside credits.

And in the meantime, if a P2 reports first, the Conroe gets shafted, and if the Conroe reports first (a higher probablility) the P2 gets a whole lot more credit than it earned.

It is completely unclear which credit request is correct. The Conroe could be over requesting credit. The P2 could be under requesting. They should be requesting the same amount of credit since they did the same amount of work. The Conroe put forth more effort over a shorter time, and the P2 put forth less effort over a greater time, but the end work was the same.

---

BOINC WIKI

don't envy your position today Ethan! ;)

Jose - you seem to have taken this as a personal battle to stand up for team XS on all fronts. I don't think I've seen any attacks on any team specifically - if there are they don't need pointing out. I'm sure XS are big enough to handle it! I'm really not trying to add fuel to the fire - I think quite a few people needs to take a few days off from posting about anything to do with credits, teams etc as it's not getting anyone anywhere.

I saw plenty of attacks on people from the Teddies team, who had been very patient in trying to explain their postion. No action was taken against the people doing the attacking which went on for ages. As soon as the Teddies started responding to these attacks, the same thread was suddenly deleted.It really does seem that some people are more equal than others here. If I was wavering before about staying with the project, this has really put the tin hat on it and I am definitely gone now.

I will say it again. If we were purely upset about credits alone, we would not be moving to a project that operates a quorum system, where we will all get less credits not only for that project, but for all of the BOINC combined credits as well. There is much more to our decision than that.

Before anyone else says it. Yes we know a quorum system is not necessary, but at least when I/we do join WCG/BOINC, we will know what is happening from the start and the Science does look good also. (Not saying Rosetta science Is'nt good BTW).

---

QMC uses a quorum of one with a cap of 2,000 credits (maximum) - previously it was 1000. They are already making plans to move to serverside credits.

Maybe I was thinking of SIMAP or LHC, it was one of those that had a quorum of 3. Nonetheless, quorums blow.

The reason BOINC is failing in regard to that original idea is because optimised clients are screwing up the amount of credit different systems claim.

The real real reason BOINC is failing is because it is not being updated with new security measures built in. Do not try to tell me that BOINC is failing because of optimized clients that actually utilize all the capabilites of current processors, that is a load of pooh.

For some projects, redundancy (quorum greater than 1) is the only method for validating that the science was done correctly. There are cases where the science is not done correctly by a given computer - some people attempt to create an output file that will pass so that they can get credit for no work (happened in S@H classic), some people over clock their computers until the FPU goes crazy (but the logic portion can appear stable - again happened in S@H classic and happens in S@H BOINC), some hosts have unknown heat problems (has happened in S@H BOINC), and occasionally something just goes wrong with an otherwise healthy host (occasional random validation errors).

For other projects where the science can be easily validated (Riesel Sieve comes to mind) a quorum of more than one can be a waste of time.

Rosetta appears to fall in the middle since it is statistics based. If most of the work is done correctly, then the answer they get is close to what they wanted. The more work that is done correctly, the closer the answer is likely to be to the goal of finding the lowest energy. So the redundancy is built in slightly differently.

---

BOINC WIKI

Jose, please edit your message. . you have a good post without calling someone thick skulled for disagreeing with your 'obvious fact'.

Ethan if you want to ban me do so. When I see you telling the same thing at the people that have slandered my teamates as cheats and the one that just attacked me now , I will edit my post.,


It has been the collective silence of the developers and moderators when the cheating accusations started , when the slandering by the Seti people started that has yielded this . Ethan, in your silence and now in your selective moderating , you and the otrher moteratos have taken sides. Willingly or not you have.

Ban if you wish; You allowed me and me teamates to be called cheats. What else can I expect.

I can think of a couple of sayins :
If the shoe fits.....
or
The truth hurts don't it....

This is not directed at you personally

If that is not directed at him personally, why quote him and say what you did then ?

---

QMC uses a quorum of one with a cap of 2,000 credits (maximum) - previously it was 1000. They are already making plans to move to serverside credits.

Maybe I was thinking of SIMAP or LHC, it was one of those that had a quorum of 3. Nonetheless, quorums blow.

The reason BOINC is failing in regard to that original idea is because optimised clients are screwing up the amount of credit different systems claim.

The real real reason BOINC is failing is because it is not being updated with new security measures built in. Do not try to tell me that BOINC is failing because of optimized clients that actually utilize all the capabilites of current processors, that is a load of pooh.

The optimized BOINC clients do NOTHING to increase the work done, they are merely to inflate the credit requests. They don't use the capabilities of the current processors in any meaningful way.

Optimized science applications do increase the work done. Each project needs to decide if optimized applications for that project are allowed or even possible.

---

BOINC WIKI

QMC uses a quorum of one with a cap of 2,000 credits (maximum) - previously it was 1000. They are already making plans to move to serverside credits.

Maybe I was thinking of SIMAP or LHC, it was one of those that had a quorum of 3. Nonetheless, quorums blow.

The reason BOINC is failing in regard to that original idea is because optimised clients are screwing up the amount of credit different systems claim.

The real real reason BOINC is failing is because it is not being updated with new security measures built in. Do not try to tell me that BOINC is failing because of optimized clients that actually utilize all the capabilites of current processors, that is a load of pooh.

The optimized BOINC clients do NOTHING to increase the work done, they are merely to inflate the credit requests. They don't use the capabilities of the current processors in any meaningful way.

Optimized science applications do increase the work done. Each project needs to decide if optimized applications for that project are allowed or even possible.

John I read with interst your statement: "Each project needs to decide if optimized applications for that project are allowed or even possible." :

The developers for THIS project have allowed optimized clients: THE DEVELOPERS OF THIS PROJECT DECIDED. Having decided, they not need to decide.

Yet, the likes of you and Tony and others have continously tag those of us who have played under the RULES SET BY THE DEVELOPERS OF THIS PROJECT AS CHEATS.

The whole saga of the last days has been fought over this. So my question is

Isn't it times that those like you start respecting the decission of the developers to ALLOW optmizided clients here and stop libeling/slandering the users of said clients as cheats?

Man be consitent with your own statements.