I've got Linux machines as well - and a USB stick to transfer the results! (they're on the same network - but I haven't graduated to that yet.)

Let me give it another try when I get back - the initial mega-drop of extra credits that prompted this thread was so out of proportion with previous credit values that it must be something fairly blatant - when you look at the right line of code.

I see you have a total credit of 15,539,788 - how does that compare with the figure before the server move?

Total credit was about 8,000,000 on 25th May. RAC was about 68,000 on 23rd, yesterday dropped to just under 5,000 then a slight increase today. On second thoughts, maybe that is just the script for RAC running again.

Dave

My account is showing total credit and average credit both increasing reflecting the Trickles that a couple of tasks are generating. But externally we are still not seeing any Export data. Is that what Richard is working on now ?

Last update user XML 2023-05-01 19:00:17 UTC (63 days 02:40:38 old)
Last update host XML 2023-04-30 18:50:17 UTC (64 days 02:50:38 old)
Last update team XML 2023-05-01 19:00:17 UTC (63 days 02:40:38 old)

Thanks
Bill F

Is that what Richard is working on now ?

Richard is working on some of the anomalies, largely to do with the OIFS tasks I believe. I may be wrong but suspect the export to external sites is a relatively trivial matter and Andy is waiting till they are sorted to either restart the script that generates the page the external sites look at or tell them where it has moved to if its having a different location following the upgrade of the BOINC server software has changed it. But I have seen no specific message from Andy on this.

I spent yesterday getting all my relevant tools up-to-date and working again, so I can try out some of the suggestions that Glenn made. But the main stumbling block remains my unfamiliarity with the C++ language and the habits of its users: the code is very sparsely commented and very tightly coded, and yet it still feels incomplete.

Glenn wrote:

If the calculation for the credit resides in one function and only one function ...

I think that's probably true for any single task: but it feels more as if the problem lies with the integration of that single task with the totality of the user's work so far in the database, and that's the opaque bit. Any offers of help with C++ would be gratefully received.

Andy has said that he would like to turn exports back on, but is awaiting the outcome of this work - so there is time pressure.

... it feels more as if the problem lies with the integration of that single task with the totality of the user's work so far in the database ...

I've been letting that thought spin round in my mind while my brain slowly wakes up to working speed. There must be something in the database to distinguish 'new work' from 'old work' - to stop old tasks being re-added every time the script is run. I think I've seen that in the code somewhere: what if it's relying on data in the database that's specific to this new script - which wasn't there before, and wasn't properly initialised? That might account for the observed anomalies.

Heading downstairs with a fresh cup of coffee ...

I spent yesterday getting all my relevant tools up-to-date and working again, so I can try out some of the suggestions that Glenn made. But the main stumbling block remains my unfamiliarity with the C++ language and the habits of its users: the code is very sparsely commented and very tightly coded, and yet it still feels incomplete.

Glenn wrote:

If the calculation for the credit resides in one function and only one function ...

I think that's probably true for any single task: but it feels more as if the problem lies with the integration of that single task with the totality of the user's work so far in the database, and that's the opaque bit. Any offers of help with C++ would be gratefully received.

Andy has said that he would like to turn exports back on, but is awaiting the outcome of this work - so there is time pressure.

Richard, sorry, have been working with Sarah on the batch problems.

Yes, I can help with the C++. I have the linux compilers installed.

---

---
CPDN Visiting Scientist

I'll PM you.

I'll PM you.

Richard have you and Glenn made any progress ?

Last update user XML 2023-05-01 19:00:17 UTC (74 days 03:25:19 old)
Last update host XML 2023-04-30 18:50:17 UTC (75 days 03:35:19 old)
Last update team XML 2023-05-01 19:00:17 UTC (74 days 03:25:19 old)

Thanks
Bill F

Yes. I think I've identified all the pieces in the jigsaw, and the steps by which they fell apart: I've reported all those to the project, and they have a plan for moving forward.

I'm going to to a public report back, but I'd like to make that a single complete narrative, not dribs and drabs. And the rest of my life keeps getting in the way. If a meeting later today goes well, I may be able to relax and get back to this, but that's not certain: it may take a few more days.

Yes. I think I've identified all the pieces in the jigsaw, and the steps by which they fell apart: I've reported all those to the project, and they have a plan for moving forward.

I'm going to to a public report back, but I'd like to make that a single complete narrative, not dribs and drabs. And the rest of my life keeps getting in the way. If a meeting later today goes well, I may be able to relax and get back to this, but that's not certain: it may take a few more days.

Richard, could we give a 'short answer' (couple of lines), before the complete findings of your excellent detective work?

Well, my meeting went relatively well, and I have a bit of a breathing space before I have to transfer my practical working knowledge to the new team. So let's try this.

I've looked back over six full months, from 1st November 2022 to early June. During that time, CPDN has had three distinct credit schemes:
1) the one which has been in use for nearly 20 years, starting with the Hadley models and the BBC project.
2) an interim scheme covering the IFS run from November to February.
3) a new integrated replacement covering all model types, which ran for the first time overnight on 9/10 May, and triggered these questions.

(1) was a two-stage process, and becoming increasingly cumbersome as volunteer speeds increased and models became more complicated. It needed replacement.
(1) and (3) were driven by the interim trickles reported by users as their tasks ran, but (1) failed to process IFS trickles.
So (2) covered IFS models 'on completion' - the way most BOINC projects work.

The problems I found:
The interim scheme (2) granted credit to every (as far as I can tell) IFS result, but failed to add many of those credits to the host, user, and team totals. So they didn't get exported to the external sites either. The external figures at the beginning of May were significantly low.
As some users commented, IFS trickles weren't visible on task results during the IFS runs. But as nobody commented, they appeared from 15:00 on 9 May, with the first run of trickle scheme (3).
And because they appeared as new trickles, credit scheme (3) processed them all over again.
The new trickles gave exactly the same credit for IFS tasks as scheme (2), so no change was visible in the result table.
But the project had made an independent decision to award a slightly higher rate of credit overall, for comparison reasons. [I still don't know exactly what they're comparing the project to]. So the {host, user, team} group got even more than "the same again" - that's what drew our attention to the issue on 10 May.
There was a small programming bug which caused the difference between 'result' and 'aggregate' credit. That has now been corrected, and is being tested on the development site - another slight delay.

The project has considered all that, and taken it on board. The main reason this all lasted so long was the major hardware problems the project had to overcome with the much bigger and resource intensive IFS models. We all suffered that too, and nobody wants to relive the experience all over again.

The project's decision is that the 'double credit' surge will be allowed to stand, as a once-off blip. We can treat it as a thank-you to the volunteers for putting up with all the hardware difficulties of the last few months, and getting the IFS results back to the researchers in good time in spite of those problems. It will appear on the external sites in due course, when the final test of the new permanent credit scheme (3) has been completed.

And now I'm going to treat myself to a nice sit-down lunch!

P.S. There was also a notable blip to our reported RAC on 10 May. It turns out just to be the effect of six month's work (probably over a million trickles) being treated as all completed on 9 May. I'm seeing credit being awarded normally for trickles from the current wah2 nz batch, and my RAC has returned to a normal proportionate figure.

Richard thank you for your diligence in researching the history and issues involved in our credit scheme. I can only imagine as each piece unfolded you were wondering "and what else will we find". You and Glenn make a pretty darn good team and now have the Creds as a can do pair.

Once they turn export on there may be questions but your thought pattern is solid.

Thank you again
Bill F

---

In October 1969 I took an oath to support and defend the Constitution of the United States against all enemies, foreign and domestic;
There was no expiration date.

Richard thank you for your diligence in researching the history and issues involved in our credit scheme. I can only imagine as each piece unfolded you were wondering "and what else will we find". You and Glenn make a pretty darn good team and now have the Creds as a can do pair.

Bill, I must correct you. It was all Richard's time-consuming analysis with next to no input from me. If I had my way, I'd get rid of credit in boinc completely (or make it ALOT simpler) - it's currently a dreadful technical debt that small teams like CPDN have to find resources to manage, but it has no benefit for the scientists using the system. I'd like to see more reward for volunteers via a better connect between the science and the community running it -- but that's a separate thread and I don't wish to pollute this one.

---

---
CPDN Visiting Scientist

it's currently a dreadful technical debt that small teams like CPDN have to find resources to manage, but it has no benefit for the scientists using the system.

For most BOINC projects the "technical debt" is to remember to make the stats-dumps available for stats sites, where "everything else" is already automatically handled then results are validated.

As for "no benefit for the scientists", I would expect it's a huge "benefit" for an individual scientist to not have to run all the models on his/her own computer(s), since chances are with no "credit" very few other users would want to waste their time running CPDN.

it's currently a dreadful technical debt that small teams like CPDN have to find resources to manage, but it has no benefit for the scientists using the system.

For most BOINC projects the "technical debt" is to remember to make the stats-dumps available for stats sites, where "everything else" is already automatically handled then results are validated.

That's not been the experience at CPDN, as is probably obvious. The fact that Richard did the work, and it took him considerable time make the point. I'm not arguing against credit for work done, but it should not be in the server code, but in the client. The amount of technical effort required for a boinc project is what puts groups off using it.

As for "no benefit for the scientists", I would expect it's a huge "benefit" for an individual scientist to not have to run all the models on his/her own computer(s), since chances are with no "credit" very few other users would want to waste their time running CPDN.

I said the credit is of no benefit to the scientists, not the ability to use the boinc framework.

Credit is effortless for other projects. I am guessing the issue is self-inflicted, by using modified/custom code. Stop using custom code, and the technical effort goes away.

WRT server vs. client managing credit, I think that is not relevant to this discussion. That should be a discussion with the BOINC development folks. I assume DA is still the gate keeper.

Finally, I think the "benefit to scientists" comment was perhaps misunderstood. Issuing credit reliably brings increased computing resources to the scientists. Perhaps this project could get SOME resources without it. But I am sure it could get MORE with it.

All IMO, of course.

Credit is effortless for other projects. I am guessing the issue is self-inflicted, by using modified/custom code. Stop using custom code, and the technical effort goes away.

If CPDN awarded credit on tasks complete as other projects, you would not get any credit for long running tasks that failed but consumed significant computer time. The trickle code they use was supplied by boinc, they didn't develop it themselves.

Other projects still have to provide user support with user credit questions/issues, assign credit rates, maintain databases; it's not effortless.

Finally, I think the "benefit to scientists" comment was perhaps misunderstood. Issuing credit reliably brings increased computing resources to the scientists. Perhaps this project could get SOME resources without it. But I am sure it could get MORE with it.

The value of credit is overestimated. If your statement was true then why are the number of boinc users continually dropping?

Ease-of-use is more important than credit for take-up. Other projects such as the Vodafone DreamLabs app has science projects running on mobile phones. They don't provide credit, just a count of work done and a thank you. They have ~250,000 users. (ref: https://www.vodafone.com/vodafone-foundation/focus-areas/dreamlab-app & https://www.imperial.ac.uk/news/241231/smartphone-users-help-simulate-cyclones-predict/). p.s. Dreamlab was not developed from the boinc code.

Client side credit calculation would open the possibility for cheating as the program is open source and users can compile their own versions.

---

Credit is not a "free bonus" to either the project scientists, or those running the applications on their computers.
Even using the standard credit system requires configuration and monitoring, plus disk space to record. Also there is the, admittedly small, extra data that has to moved from the client (you and I) and the server.
While the "standard" system works fairly well on the average project, where tasks minutes to hours to complete, it falls over for projects like CPDN which take days or weeks to run. For the majority of projects awarding credit on completion is OK, there's no substantial delay, but for long duration tasks it becomes a real pain - thus CPDN came up the trickle awards system, which isn't perfect, but it does mean that users get credit as work is done.

Does credit work?
Credit has, on its own, zero value apart from bragging rights.
I know there have been schemes to monetise credit in various ways, but they don't appear to pull in many users.
So, why have the number of BOINC users declined in recent years? Many reasons, perhaps the biggest are the lack of headline grabbing projects, and the low stability of some of those big projects.

I see in the task-window that credit is still rewarded, but just not added to the totals and also not exported to the stats sites.
I can live with this 'less-perfect' credit system, but I don't like the project to change the rules while playing...

---