Credit adjustment
6 Aug 2008 16:08:05 UTC
Topic 13691
(moderation:
Hi!
What people are experiencing here wrt credits is a combination of many things.
1 the average credit was reduced by 25% for S5R4 compared to S5R3 as announced.
2 the claimed credit is currently independent of the granted credit, and found to be much lower atm.
3 the workunits generated at first by the S5R4 workunit generator all at the upper end of the runtime variation for a given frequency band. They should average out over time, but at the beginning we got all "bad" ones.
I intend to fix 2 in the next few days, it's an unwanted side-effect of our efforts to fix the "duration correction factor". I hope to be able to fix 3 in a longer term in the workunit generator. For now I bumped up the credit (for newly generated workunits) manually by 15% (>= 13.9%) based on the following database queries (we gave 28% more credit than SETI at the end of S5R3):
mysql> select avg(granted_credit/cpu_time) from result where name like '%S5R3%' and granted_credit>0 and cpu_time>1000; +------------------------------+ | avg(granted_credit/cpu_time) | +------------------------------+ | 0.0095896610820667 | +------------------------------+ 1 row in set (1.36 sec)mysql> select avg(granted_credit/cpu_time) from result where name like '%S5R4%' and granted_credit>0 and cpu_time>1000;
+------------------------------+
| avg(granted_credit/cpu_time) |
+------------------------------+
| 0.0061389230693111 |
+------------------------------+
1 row in set (1.42 sec)mysql> select 0.0061 / 0.0095;
+-----------------+
| 0.0061 / 0.0095 |
+-----------------+
| 0.642105 |
+-----------------+
1 row in set (0.00 sec)mysql> select 1/1.28;
+--------+
| 1/1.28 |
+--------+
| 0.7812 |
+--------+
1 row in set (0.00 sec)mysql> select 0.7812 - 0.642105;
+-------------------+
| 0.7812 - 0.642105 |
+-------------------+
| 0.139095 |
+-------------------+
1 row in set (0.00 sec)
We'll keep watching these numbers and adjust credits as needed.
BM
BM
Credit adjustment
)
I just wanted to let the crunchers here know that I am keeping an eye on this also. My latest check shows:
[pre]
mysql> select avg(cpu_time/granted_credit) from result where granted_credit>0 and name like '%S5R3%' ;
+------------------------------+
| avg(cpu_time/granted_credit) |
+------------------------------+
| 176.22502753646 |
+------------------------------+
1 row in set (1.47 sec)
mysql> select avg(cpu_time/granted_credit) from result where granted_credit>0 and name like '%S5R4%' ;
+------------------------------+
| avg(cpu_time/granted_credit) |
+------------------------------+
| 206.09569102025 |
+------------------------------+
1 row in set (1.62 sec)
[/pre]
So for the S5R4 run we have reduced our credits slightly in comparison with the S5R3 run, as needed to bring ourselves into alignment with SETI@Home. (See the BOINC project credit comparison page to see why this is needed.)
I'll continue to monitor the credit-related issues, and also will make some small scheduler/transitioner modifications so that claimed_credit and granted_credit are always the same as the current granted_credit.
Cheers,
Bruce
RE: I wouldn't do any
)
I've watched this ratio (Einstein@Home credit per CPU hour/SETI@Home credit per CPU hour) for a number of weeks now. It has not fluctuated much, though it is now slowly decreasing due to the Einstein@Home credit adjustments.
So I think that the comparison to SETI@Home is reasonable, even if their stats are a few days old. Do you know if their credit realignment will increase or decrease the average credit per CPU hour?
RE: RE: RE: I wouldn't
)
Thanks -- that link is very helpful. I've seen Eric's recent credit adjustment checkins to the BOINC code. I'll have a look at these and talk with Eric if needed, just to be sure that I understand how it works and what the potential impact will be on Einstein@Home.
Cheers,
Bruce
RE: If SETI is "not able to
)
I would be interested if you could make an ordered list of what, in your opinion, are the most important problems with BOINC, SETI, and distributed computing projects. The BOINC community will be meeting in France in a couple of weeks and this would be an interesting thing for me to bring to that discussion.
Cheers,
Bruce
Hi Brian, RE: *The
)
Hi Brian,
I did not know that resend_lost_results was broken (this code was written by David Anderson and me). It is expensive to make the necessary database query, and this is simply unavoidable, so some projects can't afford that database strain.
The idea of a transaction-based communication is interesting. At least in principle one could wrap the entire scheduler interaction into a transaction and then try and get a positive acknowledgment from the BOINC client before committing it. I'm not sure if the current design/code would permit this.
I would be interested in understanding better how ghost results are generated.
By the way, looking at the current E@H scheduler log I see:
[pre]
[root@einstein log_einstein]# grep 2008-08-15 scheduler.log | grep 'Sending reply' | wc
54927 1006554 8047104
[root@einstein log_einstein]# grep 2008-08-15 scheduler.log | grep 'resent' | wc
3290 37331 295560
[/pre]
which means that less than six percent of results are re-sent. And I imagine that this ratio will become smaller as the effects of our server upgrade two weeks ago fades away.