Short WU ?
Message boards : Unix/Linux : Short WU ?
Author | Message | |
---|---|---|
Is it normal that a WU is ready crunched in approx. 7:30 minutes under Linux?
<core_client_version>5.6.3</core_client_version> |
||
ID: 23 | Rating: 0 | rate: / | ||
We're checking this out.
Is it normal that a WU is ready crunched in approx. 7:30 minutes under Linux? |
||
ID: 71 | Rating: 0 | rate: / | ||
JUst finished my first Wu after 15 min of computation on my Pentium 4 2Ghz (Mandriva):
|
||
ID: 84 | Rating: 0 | rate: / | ||
mee too! couple of returned units here
|
||
ID: 108 | Rating: 0 | rate: / | ||
the same for me... |
||
ID: 110 | Rating: 0 | rate: / | ||
the same for me... mine also. http://docking.utep.edu/result.php?resultid= Result ID 3453 3456 3458 3461 3464 3468 3471 3480 3482 3485 3488 |
||
ID: 153 | Rating: 0 | rate: / | ||
Same thing with the new WUs after about 3 minutes:
|
||
ID: 208 | Rating: 0 | rate: / | ||
We're a little at a loss with this one.We've run the same workunit on a couple of our own test boxes (different hardware) and all run fine. Will keep on searching for a solution.
Same thing with the new WUs after about 3 minutes: |
||
ID: 265 | Rating: 0 | rate: / | ||
We're a little at a loss with this one.We've run the same workunit on a couple of our own test boxes (different hardware) and all run fine. Will keep on searching for a solution. Thanks for looking into that! I sent you the charm.out files of two WUs. I hope they can help you! Stefan |
||
ID: 272 | Rating: 0 | rate: / | ||
It seems to take the same WU totally different times sometimes.
My Linux machine
(Suse 9.2) never had the short ones. But
the one WU
of the new batch that I did up to now had another Linux in another result with an incompatible runtime.
9245 103 15 Sep 2006 8:41:06 UTC 16 Sep 2006 11:32:44 UTC Over Success Done
7,359.17
10.40 pending
9930 173 15 Sep 2006 21:13:49 UTC 16 Sep 2006 4:15:12 UTC Over Success Done 244.50 1.91 pending |
||
ID: 282 | Rating: 0 | rate: / | ||
Me Too,
|
||
ID: 305 | Rating: 0 | rate: / | ||
This is a sucesful w/u,with credit, yet it says "error"
|
||
ID: 312 | Rating: 0 | rate: / | ||
We have finally found the cause of the problem that some users were experiencing on their Linux systems. It has to do with the stacksize setting on your machine which is for some distros (SuSE 9.3 and 10 for example) set to unlimited and for others (FCx, Ubuntu, etc) set to a limited value like 10240. Your setting can be seen by typing 'ulimit -s' in a terminal. To make the Charmm 'exit 1' errors go away, please set the stacksize to unlimited using the command 'ulimit -s unlimited'. This is not saying that Charmm will use all of your memory (it won't), but it gives us a little bit more space to do our simulations correctly and without errors. Please let us know if this does not work for you. If it does work, please add this command to your shell initialization file (.bashrc, .tcshrc, .kshrc, etc) in your home directory. Of course don't forget to resume the D@H project on your boincmgr in case you suspended it before.
This is a sucesful w/u,with credit, yet it says "error" ____________ D@H the greatest project in the world... a while from now! |
||
ID: 466 | Rating: 0 | rate: / | ||
[quote]We have finally found the cause of the problem that some users were experiencing on their Linux systems. It has to do with the stacksize setting on your machine which is for some distros (SuSE 9.3 and 10 for example) set to unlimited and for others (FCx, Ubuntu, etc) set to a limited value like 10240. Your setting can be seen by typing 'ulimit -s' in a terminal. To make the Charmm 'exit 1' errors go away, please set the stacksize to unlimited using the command 'ulimit -s unlimited'. This is not saying that Charmm will use all of your memory (it won't), but it gives us a little bit more space to do our simulations correctly and without errors. Please let us know if this does not work for you. If it does work, please add this command to your shell initialization file (.bashrc, .tcshrc, .kshrc, etc) in your home directory. Of course don't forget to resume the D@H project on your boincmgr in case you suspended it before.
|
||
ID: 486 | Rating: 0 | rate: / | ||
|
||
ID: 488 | Rating: 0 | rate: / | ||
We have finally found the cause of the problem that some users were experiencing on their Linux systems. It has to do with the stacksize setting on your machine which is for some distros (SuSE 9.3 and 10 for example) set to unlimited and for others (FCx, Ubuntu, etc) set to a limited value like 10240. Your setting can be seen by typing 'ulimit -s' in a terminal. To make the Charmm 'exit 1' errors go away, please set the stacksize to unlimited using the command 'ulimit -s unlimited'. This is not saying that Charmm will use all of your memory (it won't), but it gives us a little bit more space to do our simulations correctly and without errors. Please let us know if this does not work for you. If it does work, please add this command to your shell initialization file (.bashrc, .tcshrc, .kshrc, etc) in your home directory. Of course don't forget to resume the D@H project on your boincmgr in case you suspended it before. Will try that when I´m at home. I hope it works, but I think that can´t be a permanent fix for that issue. How can you inform new Docking@home users about it? |
||
ID: 493 | Rating: 0 | rate: / | ||
Message boards : Unix/Linux : Short WU ?
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)#21 (2) { ["db_conn"]=> resource(96) of type (mysql link persistent) ["db_name"]=> string(7) "docking" } ["type"]=> string(2) "->" ["args"]=> array(1) { [0]=> &string(50) "update DBNAME.thread set views=views+1 where id=11" } } [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)#21 (2) { ["db_conn"]=> resource(96) of type (mysql link persistent) ["db_name"]=> string(7) "docking" } ["type"]=> string(2) "->" ["args"]=> array(3) { [0]=> object(BoincThread)#3 (16) { ["id"]=> string(2) "11" ["forum"]=> string(1) "6" ["owner"]=> string(2) "33" ["status"]=> string(1) "0" ["title"]=> string(10) "Short WU ?" ["timestamp"]=> string(10) "1158700228" ["views"]=> string(4) "1704" ["replies"]=> string(2) "15" ["activity"]=> string(23) "2.6793473466248998e-130" ["sufferers"]=> string(1) "0" ["score"]=> string(1) "0" ["votes"]=> string(1) "0" ["create_time"]=> string(10) "1158134560" ["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(2) "11" ["forum"]=> string(1) "6" ["owner"]=> string(2) "33" ["status"]=> string(1) "0" ["title"]=> string(10) "Short WU ?" ["timestamp"]=> string(10) "1158700228" ["views"]=> string(4) "1704" ["replies"]=> string(2) "15" ["activity"]=> string(23) "2.6793473466248998e-130" ["sufferers"]=> string(1) "0" ["score"]=> string(1) "0" ["votes"]=> string(1) "0" ["create_time"]=> string(10) "1158134560" ["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=11