Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
![]() |
World Community Grid Forums
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
No member browsing this thread |
Thread Status: Active Total posts in this thread: 98
|
![]() |
Author |
|
NixChix
Veteran Cruncher United States Joined: Apr 29, 2007 Post Count: 1187 Status: Offline Project Badges: ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
I finally took my single laptop off this project. My daughter takes it onto battery mode way too often and the jobs are always aborting when it wakes up and wasting all the processing since the last trickle. Its still crunching for a cure, its just gonna be Ebola for that one. OET has short WUs and normal deadlines. Perfect fit.
----------------------------------------![]() Cheers ![]() ![]() |
||
|
KLiK
Master Cruncher Croatia Joined: Nov 13, 2006 Post Count: 3108 Status: Offline Project Badges: ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Ever since FAHB project started, all my WUs in all projects on all computer have been running in "high priority" on BOINC...
----------------------------------------Does anyone else have a similar condition?! ![]() |
||
|
cjslman
Master Cruncher Mexico Joined: Nov 23, 2004 Post Count: 2082 Status: Offline Project Badges: ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
I finally took my single laptop off this project. That's OK, you gave it a try ![]() CJSL Crunching for a better world... |
||
|
Bearcat
Master Cruncher USA Joined: Jan 6, 2007 Post Count: 2803 Status: Offline Project Badges: ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
I have my crunchers set for 3 days. Had them set at 5 but kept getting message on some wu's won't finish on time. Why the short deadlines? Other projects went out to 10 days.
----------------------------------------
Crunching for humanity since 2007!
![]() |
||
|
SekeRob
Master Cruncher Joined: Jan 7, 2013 Post Count: 2741 Status: Offline |
Bountiful discussed [search forums or read project description], but in the simplest description, in participating you get to run in a relay team. 30 or 40 stretches of 100,000 steps each. If you drop the baton before your 100,000 are done, timely, someone else will step in, post haste, the objective to do the 3 or 4 million steps in under 120 to 160 days 30x4, resp. 40x4 days max..
|
||
|
JohnMD
Cruncher Joined: Nov 27, 2012 Post Count: 3 Status: Offline Project Badges: ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Is it possible for you to prevent sending FAH2 tasks when the estimated completion time for the host is greater then 96 hours ?
I just hate waste ![]() |
||
|
SekeRob
Master Cruncher Joined: Jan 7, 2013 Post Count: 2741 Status: Offline |
Normally if the estimated completion time and fraction of uptime + fraction of computing results in greater than 96 hours return time estimate, the server would not send a FAHB task [The host is supposed to get a "would not finish in time" type of message upon the work fetch request, which includes the device's current throughput estimate].
If a computer needs 96 hours to actually compute the result, then an opt-out is advisable. |
||
|
JohnMD
Cruncher Joined: Nov 27, 2012 Post Count: 3 Status: Offline Project Badges: ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
It seems that the server's algorithm doesn't work for my Atom cpu - mine are going to take around 102 hours uninterrupted from the moment they downloaded
![]() |
||
|
Speedy51
Veteran Cruncher New Zealand Joined: Nov 4, 2005 Post Count: 1297 Status: Offline Project Badges: ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Normally if the estimated completion time and fraction of uptime + fraction of computing results in greater than 96 hours return time estimate, the server would not send a FAHB task [The host is supposed to get a "would not finish in time" type of message upon the work fetch request, which includes the device's current throughput estimate]. If a computer needs 96 hours to actually compute the result, then an opt-out is advisable. Tasks like FAH2_ avx17557-ls_ 000091_ 0006_ 017_ 0 return date of 12/1/15 issued same date as this post are also required to be returned within 4 days (96 hours) so does the same thing apply? ![]() |
||
|
SekeRob
Master Cruncher Joined: Jan 7, 2013 Post Count: 2741 Status: Offline |
Not sure what the question is, but if the BOINC scheduler calculates that a projected return date is *after* the due date, it is supposed not to receive them with said message which more exacting is
"Tasks won't finish in time: BOINC runs n% of the time; computation is enabled n% of that" If still receiving with a 102 hour calculation time, then something is not right... pure [censored] in fact, since performance info is exchanged with each fetch request. DCF 1.000000 lock is a suspect in these matters, factually handicapping a client from computing real throughput capacity on a specific WCG science. Go back to a pre 7 client and the client ignores this server forced setting, but catch 22 is, then probably the SHA256 certificate problem kicks in. Form Seti, where this started [the Berkeley testing ground]: "Jun 13, 2012 - as of the maintenance on Tuesday 12th June 2012 <dont_use_dcf/> is active on ... That means BOINC 7 clients are instructed to ignore DCF." Personally, I'd not bother with FAHB if it irked when clients can't finish the full 10 trickles. The design is though to take it one trickle at the time... scientist/WCG problem if the end result is useless because of not completing a minimum number of trickles. It is truly not our problem, in the technical sense. |
||
|
|
![]() |