In this moument I have > 1800 "pending credits" ( any from "long" time ).
Test to analize situation and to be of the opinion, problem is mising of limit to get WU
New user with Q6600 for test project get > 500 WU and thats all. After 2 week, deadline limit give task to another ... Hero
"Hero comp" No 49855 - get 750+ WU - return 0
"Hero comp" No 49706 - get 570+ WU - abortet 10
____________
/ 
[AF>XTC] Palito - 541 from 22 Jun - Return 0!
____________
/ I don't think I understand your message. Can you try to explain the problem in other words?
-Willem Jan
/ 
If I understood it right PlaNed means that some users "hoard" too many WUs without returning many successful results. (In fact they return almost nothing or aborted WUs).
So his question seems to go into the direction that the WU quota should be lowered for users who take more WUs that they can crunch in time.
(Correct me if I'm wrong. ;-))
____________
Lovely greetings from Cori 
/ (Correct me if I'm wrong. ;-))
It's true!
/ 
I have eight wu failure in a row using abc finder 103. Is their a problem with these wu's or is it Linux Fedora 8 ? See below:
Mon 28 Jul 2008 06:44:38 PM BST|ABC@home|Starting abc_wu_10374785249000_3948000_3
Mon 28 Jul 2008 06:44:38 PM BST|ABC@home|Starting task abc_wu_10374785249000_3948000_3 using abc-finder version 103
Mon 28 Jul 2008 08:15:31 PM BST|ABC@home|Computation for task abc_wu_10374785249000_3948000_3 finished
Mon 28 Jul 2008 08:15:34 PM BST|ABC@home|Started upload of abc_wu_10374785249000_3948000_3_0
Mon 28 Jul 2008 08:15:36 PM BST|ABC@home|Finished upload of abc_wu_10374785249000_3948000_3_0
Mon 28 Jul 2008 08:36:02 PM BST|ABC@home|Sending scheduler request: Requested by user. Requesting 0 seconds of work, reporting 1 completed tasks
Mon 28 Jul 2008 08:36:08 PM BST|ABC@home|Scheduler request succeeded: got 0 new tasks
Tue 29 Jul 2008 03:28:36 AM BST|ABC@home|Starting abc_wu_10478925593000_3948000_2
Tue 29 Jul 2008 03:28:36 AM BST|ABC@home|Starting task abc_wu_10478925593000_3948000_2 using abc-finder version 103
Tue 29 Jul 2008 04:58:54 AM BST|ABC@home|Computation for task abc_wu_10478925593000_3948000_2 finished
Tue 29 Jul 2008 04:58:56 AM BST|ABC@home|Started upload of abc_wu_10478925593000_3948000_2_0
Tue 29 Jul 2008 04:58:58 AM BST|ABC@home|Finished upload of abc_wu_10478925593000_3948000_2_0
Tue 29 Jul 2008 10:37:33 AM BST|ABC@home|Starting abc_wu_10478929541000_3948000_2
Tue 29 Jul 2008 10:37:33 AM BST|ABC@home|Starting task abc_wu_10478929541000_3948000_2 using abc-finder version 103
Tue 29 Jul 2008 12:10:55 PM BST|ABC@home|Sending scheduler request: Requested by user. Requesting 0 seconds of work, reporting 1 completed tasks
Tue 29 Jul 2008 12:11:00 PM BST|ABC@home|Scheduler request succeeded: got 0 new tasks
____________
/ 
I have eight wu failure in a row using abc finder 103. Is their a problem with these wu's or is it Linux Fedora 8 ? See below:
Have you tried leaving apps in memory if you don't already?
____________
Kathryn :o)
The BOINC FAQ Service
The Unofficial BOINC Wiki
The Trac System
More BOINC information than you can shake a stick of RAM at.
/ I have eight wu failure in a row using abc finder 103. Is their a problem with these wu's or is it Linux Fedora 8 ? See below:
Have you tried leaving apps in memory if you don't already?
Leave apps in memory seems to cure a lot of problems for a lot of people. Another thing to try is starting the client with the "--start_delay X" option, for example "boinc --start_delay 5". That causes BOINC to wait 5 seconds after a task finishes/suspends before it starts the next task. It might help if your computer is having some trouble cleaning up after tasks that are ending.
/ If I understood it right PlaNed means that some users "hoard" too many WUs without returning many successful results. (In fact they return almost nothing or aborted WUs).
So his question seems to go into the direction that the WU quota should be lowered for users who take more WUs that they can crunch in time.
(Correct me if I'm wrong. ;-))
You might be wrong, they probably don't hoard them on purpose ... the fpops_est is way off when you attach a new box, the DCF can be between 5 and 25 (*) after the first few crunched results. I have a small cache of half a day so it didn't matter so much, but even with a (not unusually large) 3 days cache you might end up with 2 months of work on the first connect (worst case).
Especially if ABC isn't their only project, they will not have much of a chance against that WU flood, so they'll have to abort a bunch of them.
And you're right, lowering the quota (especially for fresh hosts) should help.
(*) with a Win CC 5.10.28 I have seen DCF=25, the wide spread CC 5.10.45 has a higher benchmark so the worst case might even be worstcasisher there - not to talk about optimized core clients
/ 
If I understood it right PlaNed means that some users "hoard" too many WUs without returning many successful results. (In fact they return almost nothing or aborted WUs).
So his question seems to go into the direction that the WU quota should be lowered for users who take more WUs that they can crunch in time.
(Correct me if I'm wrong. ;-))
You might be wrong, they probably don't hoard them on purpose ... the fpops_est is way off when you attach a new box, the DCF can be between 5 and 25 (*) after the first few crunched results. I have a small cache of half a day so it didn't matter so much, but even with a (not unusually large) 3 days cache you might end up with 2 months of work on the first connect (worst case).
Especially if ABC isn't their only project, they will not have much of a chance against that WU flood, so they'll have to abort a bunch of them.
And you're right, lowering the quota (especially for fresh hosts) should help.
(*) with a Win CC 5.10.28 I have seen DCF=25, the wide spread CC 5.10.45 has a higher benchmark so the worst case might even be worstcasisher there - not to talk about optimized core clients
I believe Boinc has a formula for hosts that return bad units and then want new ones, this goes for hosts returning units past the deadline too. For every bad one your number of new ones available to you goes down, but for it to go back up you need to return 2 good ones. This eventually weeds out hosts that are nothing but problem childs.
____________
/ Not exactly, a (well, in my opinion) misconcept in BOINC makes the project server happy with 2% good results.
Each bad result subtracts one from the daily quota, a single good result doubles the quota. So on a project with a quota of 150, you will always stay above 75 as long as you return one good result for every 74 bad ones.
That's not really a strong penalty for unreliable hosts.
The problem I see here is the too low estimated fpops needed for the WUs. The hosts do adjust to that after a very short time, but on their very first work request they might get flooded with way more results than they can handle. That leads to missed deadlines or aborted results on fresh hosts.
p.s.: Imo. the adjustment of fpops_est should not be done in a single run, so existing hosts that have their correction factor already (roughly) adjusted don't get too confused. 3 or 4 steps towards 5 times the current fpops_est should do the job without creating a major chaos.
/ The problem I see here is the too low estimated fpops needed for the WUs. The hosts do adjust to that after a very short time, but on their very first work request they might get flooded with way more results than they can handle. That leads to missed deadlines or aborted results on fresh hosts.
p.s.: Imo. the adjustment of fpops_est should not be done in a single run, so existing hosts that have their correction factor already (roughly) adjusted don't get too confused. 3 or 4 steps towards 5 times the current fpops_est should do the job without creating a major chaos.
I agree 100%.
Willem-Jan are you reading this? The fpops estimate has been far too low for a very long time. It's causing grief and confusion for a lot of people. The evidence is in the BOINC dev forums where there is a steady stream of questions from people who are downloading too many work units and running into deadline problems. Almost invariably, those people are crunching ABC.
Please consider implementing Ananas's suggestion to increase the fpops estimate gradually, in 3 or 4 steps, to about 5 times the current value.
(If Willem_Jan doesn't respond in a few days I'll send him email on this important issue.)
/ I have increased the fpops from 5 to 7 e12 and will increase it as far as necessary.
____________
"Life is short and meaningless, unless you make the best of it."
/ I have increased the fpops from 5 to 7 e12 and will increase it as far as necessary.
How will you know when you have it right? When our DCF is about 1? Will it help if we report our DCFs here in a few days, after they've had some to adjust?
/ I have increased the fpops from 5 to 7 e12 and will increase it as far as necessary.
How will you know when you have it right? When our DCF is about 1? Will it help if we report our DCFs here in a few days, after they've had some to adjust?
q6600 (stock), xp/sp3, DCF 5.2
q9300 (stock), linux64, DCF 3.0
q9300 (stock), linux64, DCF 2.5
q6600@3.0, linux64, DCF 3.1
phenom 9750 (stock), linux64, DCF 3.2
Still low by a factor of 3 it seems.
/ Watching the 6 hosts I have attached to ABC and crunching ABC almost exclusively, the DCFs are averaging about 3 to 5 for me though they do swing as low as 1.5 and as high as 10.5 when one of the monster tasks comes along.
I agree, the fpops needs to be stepped up again. It probably needs several small steps over the coming months.
/ I agree, the fpops needs to be stepped up again. It probably needs several small steps over the coming months.
fpops_est got another nudge from 1e13 to 1.2e13
____________
"Life is short and meaningless, unless you make the best of it."
/