Exceeded CPU time quota.
Message boards : Number crunching : Exceeded CPU time quota.
Author | Message | |
---|---|---|
Just returned from 3 weeks away and found that
this wu
crashed out with exceeded quota. I saw the news item from 22nd about dodgy wu's but note that this wu was sent today. Is this the same error? Are there more of these dodgy wu's in the queue ready to send?
|
||
ID: 4411 | Rating: 0 | rate: / | ||
If this is the same problem, can you do a server-abort (if that's the right term) to recall these units that may still be queued but not yet started?
|
||
ID: 4416 | Rating: 0 | rate: / | ||
We already did it. The problem is for existing workunits that created an additional replica, which was the case of 1d4h_mod0013sc_69953_284934_1, this last one indicates that it was an additional replica created for 1d4h_mod0013sc_69953_284934_0.
|
||
ID: 4417 | Rating: 0 | rate: / | ||
There was another wu
here
which arrived 29th that crapped out after 12+ hours with exceeded quota.
|
||
ID: 4459 | Rating: 0 | rate: / | ||
I just had a WU that aborted with a "recourse limit exceeded" message. It had been busy for 20 1/2 hours. The next WU is now busy for 2 1/4 hours and is not even at 4.5%, so according to my calculation this one will be exceeding the resource limit again as well. Before these last WU's I never had this problem as far as I can remember.
|
||
ID: 4695 | Rating: 0 | rate: / | ||
Hi Bart,
|
||
ID: 4696 | Rating: 0 | rate: / | ||
Hi Bart, Well, this particular computer of mine is pretty slow as well (1300 Mhz). Can't this be part of the problem? But I just aborted as I think it'll eventually give an error again. I just hope there will not be too much of these "strange" WU's. My latest D@H WU's before the last long ones took from 11 minutes to 9 hours to complete. I'll see what's coming in next... Thanks, Bart |
||
ID: 4697 | Rating: 0 | rate: / | ||
I ran in the "Maximum CPU time exceeded" error as well with
one of my WUs
. It was well before deadline, but somehow 27720.43 seconds (07:42:00.43 hours) were declared as being too much.
|
||
ID: 4717 | Rating: 0 | rate: / | ||
Hi.
|
||
ID: 4722 | Rating: 0 | rate: / | ||
I'm sorry, I found that the problem was specially present in 1pph. I'm trying to find a solution, if the problem cannot be detected on time, at least the credit should be assigned and the results returned, because in those cases the results are still valid and are even more stable than in the case of shorter workunits
|
||
ID: 4731 | Rating: 0 | rate: / | ||
Hate to rain on your parade Trilce, but right now I've got a 1bl7 workunit (1bl7_mod0013scp38alpha_19273_467291_0 is the exact designation) that's been running for over 5.5 hours now and hasn't budged from 0%. When I display the graphics, it says that "no model has been formed yet." It hasn't timed out (yet), but it maybe the same kind of problem that others have been having, or maybe its just a dud WU. (shrugs shoulders)
|
||
ID: 4776 | Rating: 0 | rate: / | ||
Hi.
|
||
ID: 4780 | Rating: 0 | rate: / | ||
Hi. Please abort the rest. We had a problem with the p38 protein that we isolated and fixed. We will distribute new jobs with the p38 protein on Saturday, This time the error should not be present. Thanks, Michela ____________ If you are interested in working on Docking@Home in a great group at UDel, contact me at 'taufer at acm dot org'! |
||
ID: 4782 | Rating: 0 | rate: / | ||
Michela.
|
||
ID: 4783 | Rating: 0 | rate: / | ||
Please abort the rest. We had a problem with the p38 protein that we isolated and fixed. We will distribute new jobs with the p38 protein on Saturday, This time the error should not be present. Meanwhile, what happens to the valuable crunching effort that has been discarded? The results are probably valid, but declared invalid by BOINC. Any chance that the results can be used? Or have we just wasted our time due to a dumb configuration problem? Thanks, Al. |
||
ID: 4787 | Rating: 0 | rate: / | ||
Here's another ran for 10hrs, 38min, different type of task guess i won't see any credit for it.
|
||
ID: 4789 | Rating: 0 | rate: / | ||
Rather disappoint that a WU like
this
is crunched for about 8h only to be aborted because a too pessimistic CPU time limit...
|
||
ID: 4792 | Rating: 0 | rate: / | ||
Rather disappoint that a WU like this is crunched for about 8h only to be aborted because a too pessimistic CPU time limit... Hi All, Please look at this answer . Sorry for the inconvenience. Michela ____________ If you are interested in working on Docking@Home in a great group at UDel, contact me at 'taufer at acm dot org'! |
||
ID: 4799 | Rating: 0 | rate: / | ||
Rather disappoint that a WU like this is crunched for about 8h only to be aborted because a too pessimistic CPU time limit... Hi All, Please look at this answer . Sorry for the inconvenience. Michela ____________ If you are interested in working on Docking@Home in a great group at UDel, contact me at 'taufer at acm dot org'! |
||
ID: 4800 | Rating: 0 | rate: / | ||
Hello Michela and all,
|
||
ID: 4812 | Rating: 0 | rate: / | ||
I have a remote computer that has downloaded a swag of jobs on the 22/1/09 and more than half of them are erroring out with "Maximum cpu time exceeded" error.
|
||
ID: 4824 | Rating: 0 | rate: / | ||
Pretty much every work unit that I have downloaded for Linux in the past 24 hours has gone over the maximum allocated CPU time (well over 8 hours). Is this because of a problem with the new work units? There appears to be no problems with my computers, and resetting has not helped this.
|
||
ID: 4897 | Rating: 0 | rate: / | ||
It is very strange, so far only 4 users have this problem. I can see that it is not a problem with the speed of the computer because you are using a very fast one. We incremented the limit of cpu allowed so that you won't get the error, but we need to find out what is the pattern of this error occurrence.
|
||
ID: 4898 | Rating: 0 | rate: / | ||
Message boards : Number crunching : Exceeded CPU time quota.
Database Error: The MySQL server is running with the --read-only option so it cannot execute this statement
array(3) { [0]=> array(7) { ["file"]=> string(47) "/boinc/projects/docking/html_v2/inc/db_conn.inc" ["line"]=> int(97) ["function"]=> string(8) "do_query" ["class"]=> string(6) "DbConn" ["object"]=> object(DbConn)#28 (2) { ["db_conn"]=> resource(126) of type (mysql link persistent) ["db_name"]=> string(7) "docking" } ["type"]=> string(2) "->" ["args"]=> array(1) { [0]=> &string(51) "update DBNAME.thread set views=views+1 where id=341" } } [1]=> array(7) { ["file"]=> string(48) "/boinc/projects/docking/html_v2/inc/forum_db.inc" ["line"]=> int(60) ["function"]=> string(6) "update" ["class"]=> string(6) "DbConn" ["object"]=> object(DbConn)#28 (2) { ["db_conn"]=> resource(126) of type (mysql link persistent) ["db_name"]=> string(7) "docking" } ["type"]=> string(2) "->" ["args"]=> array(3) { [0]=> object(BoincThread)#3 (16) { ["id"]=> string(3) "341" ["forum"]=> string(1) "2" ["owner"]=> string(3) "343" ["status"]=> string(1) "0" ["title"]=> string(24) "Exceeded CPU time quota." ["timestamp"]=> string(10) "1237849189" ["views"]=> string(3) "800" ["replies"]=> string(2) "22" ["activity"]=> string(22) "1.1227289893251999e-91" ["sufferers"]=> string(1) "0" ["score"]=> string(1) "0" ["votes"]=> string(1) "0" ["create_time"]=> string(10) "1222241046" ["hidden"]=> string(1) "0" ["sticky"]=> string(1) "0" ["locked"]=> string(1) "0" } [1]=> &string(6) "thread" [2]=> &string(13) "views=views+1" } } [2]=> array(7) { ["file"]=> string(63) "/boinc/projects/docking/html_v2/user/community/forum/thread.php" ["line"]=> int(184) ["function"]=> string(6) "update" ["class"]=> string(11) "BoincThread" ["object"]=> object(BoincThread)#3 (16) { ["id"]=> string(3) "341" ["forum"]=> string(1) "2" ["owner"]=> string(3) "343" ["status"]=> string(1) "0" ["title"]=> string(24) "Exceeded CPU time quota." ["timestamp"]=> string(10) "1237849189" ["views"]=> string(3) "800" ["replies"]=> string(2) "22" ["activity"]=> string(22) "1.1227289893251999e-91" ["sufferers"]=> string(1) "0" ["score"]=> string(1) "0" ["votes"]=> string(1) "0" ["create_time"]=> string(10) "1222241046" ["hidden"]=> string(1) "0" ["sticky"]=> string(1) "0" ["locked"]=> string(1) "0" } ["type"]=> string(2) "->" ["args"]=> array(1) { [0]=> &string(13) "views=views+1" } } }query: update docking.thread set views=views+1 where id=341