I have noticed that recently some tasks in the project award an unusually large amount of credits compared to other similar tasks, both in this project and in other BOINC projects. I am concerned that such inequalities may discourage some users from continuing to participate in the project and negatively affect fair competition. This may be the result of some bug in the credit awarding system or an unintended configuration. Is there a possibility that the project team could look into this issue and consider adjusting the credit awarding algorithm? I think that fair credit awarding is crucial to engaging the community and encouraging new participants to join. Thank you for your attention and I am open to further discussion on this matter."

This approach shows concern for the project and the community, while avoiding confrontation and indicating a desire to solve the problem.

Please provide specific examples of the tasks by putting links in this thread. Otherwise, it is hard to know how to respond. Are you referring to some buggy tasks that incorrectly ran very fast and still gave the credit? That was discussed in other threads.

Certain projects here require long run times (12-18 hrs, such as ATM, ATMML) or large amounts of GPU memory (12-16 GB) and high FP64 performance, such as QChem. Awarded points also may have a bonus for faster completion. I think they are awarded fair credit for the hardware and volunteer attention required.

As for Bitcoin Utopia, I was a top producer on that project and nothing here comes within an order of magnitude of the rate I earned on that project. BU required specialized hardware to get the highest production and could not serve any other projects.

I think He connects it to other projects, like Einstein@home, where similar GPU can do ~ 6-7 times less credits a day.
I personally started similar topic on Minecraft, where 1 thread of 4600h CPU can produce ~ 800k daily - far from fair to other projects.
We all know that different projects have different approach to credits, but still - there should be borders.
BU was ok as GPU produced fair amount of credits - only ASICs where many times faster. It just exploded statistics :)

Each project and subproject are so different in terms of computing needs, so I think there is no good way to compare credits. Projects can set higher credits to draw in the volunteer resources they need. Anyway, it's all for fun regarding credits as there is no cash value.

Each project and subproject are so different in terms of computing needs, so I think there is no good way to compare credits. Projects can set higher credits to draw in the volunteer resources they need. Anyway, it's all for fun regarding credits as there is no cash value.

That might have been true when only cpu applications and work were available in the beginning of BOINC.

But as soon as gpu apps made the scene, the old Cobblestone credit awarding mechanism became terminally broken.

And without some BOINC overseer that had absolute control over project scientists and administrators to stick to the Cobblestone credit algorithm on penalty of death or whatever, the Boinc infrastructure became as lawless as the Wild West.

So administrators now arbitrarily decide the work unit credit value per app of each project.

Some try and more or less to reward credit based on how hard the host had to work to complete the calculation, but some do not or award pathetically low credit for the work or in comparison to similarly sized GFLOPS needed for the work unit compared to other projects.

So we old-timers just accept the current system as it is. No point in grumbling about it. We are not going to force any changes as a volunteer.

I'm old timer and I don't accept millions of credits for nothing.
Long run bonus - ok;
special hardware bonus - ok;
High error rate bonus - ok;
Linux vs Windows bonus - ok;
Short term bonus - ok;
We made mistake and credits are high this batch - ok;

But hundrets/thousand time more credits for nothing - not ok.

I'm old timer and I don't accept millions of credits for nothing.
Long run bonus - ok;
special hardware bonus - ok;
High error rate bonus - ok;
Linux vs Windows bonus - ok;
Short term bonus - ok;
We made mistake and credits are high this batch - ok;

But hundrets/thousand time more credits for nothing - not ok.

Each project and subproject are so different in terms of computing needs, so I think there is no good way to compare credits. Projects can set higher credits to draw in the volunteer resources they need. Anyway, it's all for fun regarding credits as there is no cash value.

As @Mikey mentioned, this project requires fast turnaround for tasks and set a short 5-day deadline. If the admins/developers/scientists had their druthers, and be damned any complaints from the volunteers, they would set a one day deadline.

One of the reasons they award a 50% credit bonus for returning work within 24 hours and the 25% credit bonus for returning work in less than 2 days.

You might not realize that the work unit result you return is actually, sent right back out immediately after validation as the science input to the next task sent out to someone. Each new task is an iteration of the tasks that came before.

This is how they produce their science results.