I noticed this on my account and the few others I checked both here and on the testing site. My account has completed tasks recently enough that RAC should not be zero either on my native linux client or on my windows client running under WINE. . Recent average credit both here and on the testing site look correct for me as a user so not a big deal. I have passed it on to Andy for when he gets a round tuit.

Confirmed here, too. For example, Computer 1523288 (Windows) completed four tasks from the recent WaH2 run, issued on 11 July 2023 and completed between 23 July and 3 August. Credit for that run was exported to BOINCstats on 05 September, but the individual host record here shows zero RAC, as you say.

I'll try and have another proof-read of the new credit script over the weekend.

I was in Oxford with the CPDN team yesterday and brought this up in the meeting. I suggest Dave/Richard you both contact Andy directly to resolve this. Thx.

---

---
CPDN Visiting Scientist

I have already emailed Andy with my thoughts on the area of code that needs review (12:30 Saturday - you have a copy, Glenn).

It's in the routine that starts at

cpdn_credit.cpp#L299

. But because it's C++, and I gather David A's C++, I'm nervous about going further than I've said in the email - I've recommended, on that basis, that Andy asks David to review his own code.

There is a clear and obvious difference between the section that handles 'host' data, and the sections that handle 'user' and 'team' data, which would account for Dave's original observation.

Since the recent “adjustment” to the credit scores my RAC has been 261384 which is definitely not right.

I have processed no tasks since the adjustment so that might be why the RAC is not being recalculated.

ETA Hosts 1537273 and 1537133.

In looking up my host ids I note that my RAC within CPDN is zero so the erroneous figure is only showing in Boinc Manager and BoincStats and this post probably needs to be ignored.

That may be the result of a generic weakness in BOINC generally, not limited to CPDN alone.

A BOINC server will only update a user's RAC when a "credit event" occurs - basically, when a completed task has been reported by that user, and new credit awarded. Because you haven't reported any completed tasks in that period, you won't have had a qualifying event.

I've still got a RAC of 874.09 at SETI@Home, which has been effectively shut down for over two years. (edit - over three years. Doesn't time fly)

I have already emailed Andy with my thoughts on the area of code that needs review (12:30 Saturday - you have a copy, Glenn).

It's in the routine that starts at

cpdn_credit.cpp#L299

. But because it's C++, and I gather David A's C++, I'm nervous about going further than I've said in the email - I've recommended, on that basis, that Andy asks David to review his own code.

There is a clear and obvious difference between the section that handles 'host' data, and the sections that handle 'user' and 'team' data, which would account for Dave's original observation.

Richard, yes I have a copy of the email, but as you know I have zero interest in credit.

Is this likely to affect other projects it it's code? If so I am sure someone else has brought this up. Perhaps it's an implementation issue at CPDN? Anyway, I'm sure Andy will get to the bottom of it.

I suspect an implementation issue at CPDN. I have a host average that has changed with reported tasks at all the other projects I have been with. It is possible I have just not spotted this before but I suspect it may have crept in with the new credit script.

My Host 1523288 srill has a RAC of 0, despite reporting two trickles so far from Task 22336100 (batch 996).

But my overall RAC has returned to sanity, following the 'credit events' triggered by the new batch.

hi Richard, Andy hasn't looked into this yet, which is why nothing has changed. It's start of the academic year and the CPDN staff are busy with the new intake of Masters students. The issue is on the list of actions.

Just noted another curiosity with the recent WaH2 eas run on Windows. I've run, finished and reported two tasks (one on each of two separate machines). Each task has been awarded 19,901.44 credits, and both ran cleanly and continuously without any any of the upload problems others have experienced.

But my user total hasn't kept pace while they've been running - it's only gone up by 20,601 credits. And the daily rate has been erratic, to say the least:

Date            Total credit    Credit per day
2023-10-14      33,375,098      2,216
2023-10-13      33,372,882      3,544
2023-10-12      33,369,338      2,866
2023-10-11      33,366,472      1,524
2023-10-10      33,364,949        518
2023-10-09      33,364,431      1,154
2023-10-08      33,363,277      2,495
2023-10-07      33,360,782      3,085
2023-10-06      33,357,697      3,200
2023-10-05      33,354,497          0

(thanks to BOINCstats for the analysis)
It's all recent enough that I should still have the full logs, so I'll look through them and try and work out what's going on - add it to Andy's ToDo list with the RAC problem.

(one of the machines has picked up a resend, so the user total shown to the left of this post will keep changing - but it's correct this morning)

Edit - except it isn't. That's another one for my own ToDo list! Recording it for posterity: 33,375,985, up another 887.

But my user total hasn't kept pace while they've been running - it's only gone up by 20,601 credits. And the daily rate has been erratic, to say the least:

Too subtle for me to notice I am afraid. Not like the zero RAC figure for computers!

Here's what one of my hosts has accumulated. This is a bit easier to see as it is running only one CPDN task: https://www.cpdn.org/result.php?resultid=22339724
It has sent 20 trickles (2 every day) and has accumulated 16,588.11 credits which gives 829.4055 credits/trickle. So Boinstats should see as credit/day a multiple of that value. But the value in Boincstats is all over the place. So either credit/trickle is not constant or it is calculated incorrectly or reported incorrectly.

From Boincstats:

Date		Total Credit	Credit/day
2023-10-15	4,346,979		955 
2023-10-14	4,346,024		657 
2023-10-13	4,345,367		359 
2023-10-12	4,345,008		73 
2023-10-11	4,344,935		235 
2023-10-10	4,344,700		534 
2023-10-09	4,344,166		832 
2023-10-08	4,343,334		1,129 
2023-10-07	4,342,205		1,428 
2023-10-06	4,340,777		849
2023-10-05	4,339,928		0	

From this site:

Time Sent (UTC)		HostID	ResultID	Result Name					TimeStep	CPU Time	sec/TS
15 Oct 2023 14:57:02	1286606	22339724	wah2_eas25_a2vc_200312_24_996_012227268_0	230,699		831,693		3.6051
15 Oct 2023 03:25:37	1286606	22339724	wah2_eas25_a2vc_200312_24_996_012227268_0	219,179		790,837		3.6082
14 Oct 2023 15:57:04	1286606	22339724	wah2_eas25_a2vc_200312_24_996_012227268_0	207,659		750,083		3.6121
14 Oct 2023 04:21:22	1286606	22339724	wah2_eas25_a2vc_200312_24_996_012227268_0	196,139		708,991		3.6147
13 Oct 2023 17:01:57	1286606	22339724	wah2_eas25_a2vc_200312_24_996_012227268_0	184,619		668,864		3.6229
13 Oct 2023 05:50:50	1286606	22339724	wah2_eas25_a2vc_200312_24_996_012227268_0	173,099		629,080		3.6342
12 Oct 2023 18:44:10	1286606	22339724	wah2_eas25_a2vc_200312_24_996_012227268_0	161,579		589,611		3.6491
12 Oct 2023 07:23:50	1286606	22339724	wah2_eas25_a2vc_200312_24_996_012227268_0	150,059		549,678		3.6631
11 Oct 2023 20:11:48	1286606	22339724	wah2_eas25_a2vc_200312_24_996_012227268_0	138,539		509,836		3.6801
11 Oct 2023 07:50:01	1286606	22339724	wah2_eas25_a2vc_200312_24_996_012227268_0	127,019		469,245		3.6943
10 Oct 2023 19:56:52	1286606	22339724	wah2_eas25_a2vc_200312_24_996_012227268_0	115,499		426,910		3.6962
10 Oct 2023 07:46:33	1286606	22339724	wah2_eas25_a2vc_200312_24_996_012227268_0	103,979		383,865		3.6918
09 Oct 2023 19:39:39	1286606	22339724	wah2_eas25_a2vc_200312_24_996_012227268_0	92,459		340,791		3.6859
09 Oct 2023 07:29:41	1286606	22339724	wah2_eas25_a2vc_200312_24_996_012227268_0	80,939		297,613		3.6770
08 Oct 2023 19:18:01	1286606	22339724	wah2_eas25_a2vc_200312_24_996_012227268_0	69,419		254,183		3.6616
08 Oct 2023 07:14:23	1286606	22339724	wah2_eas25_a2vc_200312_24_996_012227268_0	57,899		211,254		3.6487
07 Oct 2023 19:12:16	1286606	22339724	wah2_eas25_a2vc_200312_24_996_012227268_0	46,379		168,406		3.6311
07 Oct 2023 05:50:50	1286606	22339724	wah2_eas25_a2vc_200312_24_996_012227268_0	34,859		126,354		3.6247
06 Oct 2023 18:05:17	1286606	22339724	wah2_eas25_a2vc_200312_24_996_012227268_0	23,339		84,502		3.6206
06 Oct 2023 06:09:30	1286606	22339724	wah2_eas25_a2vc_200312_24_996_012227268_0	11,819		42,742		3.6164

---

From my notes in July/August, the trickles for WaH2 should be 849.something for the first trickle in the run, and 827.something for every trickle after that. Other task types use different numbers, but they should follow the same pattern - the first is slightly larger, but all the rest are exactly the same. The exact values may, or may not, be subject to a new 'Correction Factor' of x1.09. I can't (yet) see where your figures are coming from.

I'm going to keep a close eye on, and log, the new task which started today. My earlier discrepancy was because BOINCstats only updates the detailed tables once per day, in the early afternoon, European time. Yesterday's figures were missing the final trickle of the last run, today's caught the first trickle of the new task (and there'll be another along soon).

I will check back on some older WAH2 tasks to see if computation time per trickle is similar. Knowing that this one is for a larger area with the same 25km2 grid, it maybe that it should get more credit?

Edit: Older task 25 month task credit:19,018.13

One of current tasks after 23zips credit:19,073.11 Will update final figure in morning.

I will check back on some older WAH2 tasks to see if computation time per trickle is similar. Knowing that this one is for a larger area with the same 25km2 grid, it maybe that it should get more credit?

Well, the official base calculation is

credit_per_timestep * timesteps_per_trickle

For WaH2, those are

Cr/timestep: 0.0659667
Ts/trickle: 11,819 for the first trickle, 11 520 for all the rest

You can see the second in the "sched_request.xml" file sent for each trickle, and they haven't changed with this run. I can't see the first directly, without another table dump from the project, but I very much doubt they're changed it: that table tends to be very stable, year after year.

Those figures lead to raw credit scores of 779.6604273 for the first trickle, and 759.936384 for all the rest. The correction factor (rounded) led to the values I suggested to Harri before.

But this run has given me 849.83 and 828.33 for this task, but my total (user) credit went up by 849 this morning, but only 751 with the second trickle. I'll sleep on that, and see what happens overnight.

I get that is the official calculation. This is on the same machine with pretty much the same number of tasks running.

For the older task
CPU time 6 days 10 hours 29 min
Validate state Valid
Credit 19,018.13
One of current batch
CPU time 10 days 5 hours 32 min 35 sec
Validate state Valid
Credit 19,901.44

So, credit/timestep is higher but not enough to balance the increase in work/timestep.
Time Sent (UTC) Host ID Result ID Result Name Timestep CPU Time (sec) Average (sec/TS)
22 Jul 2023 08:02:46 1514267 22331648 wah2_nz25_202b_209005_25_995_012220481_0 288,299 547,271 1.8983
and
16 Oct 2023 02:24:45 1543433 22340908 wah2_eas25_a3s8_200912_24_996_012228452_0 276,779 883,704 3.1928

I think that would mean the project adding yet another fiddle-factor, "flops per timestep". I don't think they're quite ready to do that ... ;-)

I think that would mean the project adding yet another fiddle-factor, "flops per timestep". I don't think they're quite ready to do that ... ;-)

I am sure you are right. It must be much easier with projects where credit is granted only for completed tasks!

Well, I've set up monitoring - added another page to my spreadsheet. And it's not a pretty sight.

This is what I've got so far:

Task 22347460										

Trickle	Date		Host total	Host increment	User total	User increment	Task total	Task increment

			93,562				33,375,985				
1	15/10/2023					33,376,834	849		  849.83	849.83
2	15/10/2023					33,377,585	751		1,678.16	828.33
3	16/10/2023	95,839		2,277		33,378,262	677		2,506.49	828.33
4	16/10/2023	96,441		  602		33,378,864	602		3,334.82	828.33

The 'Task total' and 'task increment' - I hope the names are obvious - are exactly what I would expect from the theory.

But the Host and User equivalents are getting smaller and smaller - something's taking a salami slicer to them! I'll let it run a couple more days, then I'll bury my head in that bloody C++ script again.